Written and maintained by CASRAI Editorial Board
Last updated
ISO/IEC 42001, the AI management system standard, contains a requirement with no equivalent anywhere in ISO/IEC 27001: clause 6.1.4 tells you to establish a process for assessing the potential consequences of an AI system for individuals, groups and society, and clause 8.4 tells you to actually perform that assessment and retain the documented results. What 42001 never does is tell you what the resulting document looks like. An auditor can ask to see your AI system impact assessments; 42001 gives you almost nothing to build one from.
ISO/IEC 42005:2025 is the companion publication that fills that hole. It is the operational document sitting behind an abstract management-system requirement. It is also, crucially, guidance rather than a requirements standard — which means there is no such thing as ISO 42005 certification, and any vendor claiming to hold one is telling you something that cannot be true.
What ISO/IEC 42005:2025 is, exactly
The identity details below come from the IEC webstore listing, IEC being the co-publisher of the ISO/IEC joint deliverable:
- Designation: ISO/IEC 42005:2025
- Full title: Information technology — Artificial intelligence (AI) — AI system impact assessment
- Edition: 1.0, the first edition
- Published: 28 May 2025
- Length: 39 pages
- Committee: ISO/IEC JTC 1/SC 42, Artificial Intelligence
- ICS classification: 35.020
The published scope is guidance for organisations performing AI system impact assessments for individuals and societies affected by an AI system and its foreseeable applications. It covers how and when to perform such assessments, at which stages of the AI system life cycle to perform them, and what the assessment documentation should contain. It also addresses how the impact assessment process fits into an organisation’s wider AI risk management and into an AI management system. It is written to apply to organisations of any size that develop, provide or use AI systems.
The United Kingdom has adopted it nationally as BS ISO/IEC 42005:2025, published by BSI on 30 June 2025 under ISBN 978 0 539 23618 7. That 30 June date is a national adoption date, not the ISO/IEC publication date, and the two should not be used interchangeably.
The requirement it operationalises
ISO/IEC 42001 splits the impact-assessment duty across two clauses. Clause 6.1.4 sits in the planning chapter and requires the organisation to establish a process for assessing the potential consequences of an AI system for individuals, groups of individuals and society — explicitly not only consequences for the organisation itself. Clause 8.4 sits in the operations chapter and requires you to perform that assessment and keep documented results of it.
The distinction matters at audit. Clause 6.1.4 is about having a defined, repeatable procedure. Clause 8.4 is about evidence that the procedure was run on real systems and that the outputs were retained. An organisation can fail one while passing the other: a beautifully documented process that has never been applied to a live system fails 8.4, and a stack of ad hoc assessments with no defined method behind them fails 6.1.4. If you are working toward certification, our guide to ISO/IEC 42001 certification covers how the clause structure maps onto the audit stages.
ISO/IEC 42005 is the answer to “fine, but what goes in the document?” It operates at the level of an individual AI system, where 42001 operates at the level of the organisation.
You cannot be “ISO 42005 certified”
This is worth stating plainly because the claim is already circulating. ISO/IEC 42005 is a guidance document. It does not contain auditable “shall” requirements against which a certification body could issue a certificate, and no accredited certification scheme exists for it. The certifiable standard in this family is ISO/IEC 42001, the management system standard. Everything 42005 says is advice on how to satisfy 42001’s clause 6.1.4 and 8.4 obligations well.
The same point applies in the other direction, and legal commentary on the standard makes it explicitly: conformity with ISO/IEC 42005 generates no presumption of conformity with the EU AI Act. Harmonised standards under the AI Act carry that presumption; an international guidance document published by JTC 1/SC 42 does not. If a supplier tells you their AI system is “42005 compliant” and offers that as evidence of regulatory compliance, the claim is doing no work. The right follow-up question in procurement is which specific assessment they performed, against which clause of which instrument, and who reviewed it.
What the assessment document contains
A caution on sourcing before this section: the text of ISO/IEC 42005 is paywalled and the publisher previews are not machine-readable, so the description below is drawn from the published scope statement and from BSI’s own overview of the standard it adopted, not from the clause text itself. Treat it as the shape of the document rather than a clause-by-clause reproduction.
What is well supported is that the standard addresses four things. First, the timing question: when in the AI system life cycle an impact assessment should be performed, and what triggers a reassessment — the assessment is not a one-off gate at deployment. Second, the method: how to perform the assessment, including identifying the system and its context, identifying the people and groups who could be affected, and working through potential impacts on them. Third, documentation: what the assessment record should contain so that it is usable as evidence and reusable on the next revision of the system. Fourth, integration: how impact-assessment findings feed back into AI risk management and the management system rather than sitting in a separate file nobody reads.
BSI’s overview of BS ISO/IEC 42005:2025 describes the standard as including a structured taxonomy of the factors to consider, naming transparency, fairness, reliability, safety and privacy among them. That is BSI’s characterisation of the document rather than a quotation of its clause headings, and it is the level of detail we are prepared to assert without the source text in front of us.
Operationally, the important design decision is that the impact assessment and the risk register are different artefacts with different subjects. The risk register asks what could go wrong for the organisation and its objectives; the impact assessment asks what could go wrong for the people on the receiving end of the system, including people who never chose to interact with it. Our AI risk assessment framework and risk register guide covers the organisational side; 42005 is the outward-facing counterpart, and findings should flow between the two.
Three impact assessments that are not the same thing
This is where the practical confusion lives. An organisation deploying an AI system in Europe can plausibly owe three different assessments, and they are routinely conflated in vendor material and internal policy alike.
| Assessment | Source | What it protects | Legally binding? |
|---|---|---|---|
| AI system impact assessment | ISO/IEC 42005:2025, operationalising ISO/IEC 42001 clauses 6.1.4 and 8.4 | Individuals and societies affected by the AI system and its foreseeable applications | No. Guidance. Becomes contractually or audit-relevant only via a 42001 management system |
| Data protection impact assessment (DPIA) | GDPR Article 35 | Rights and freedoms of natural persons in relation to the processing of their personal data | Yes, where the processing is likely to result in a high risk |
| Fundamental rights impact assessment (FRIA) | EU AI Act Article 27 | Fundamental rights of persons affected by a high-risk AI system, in a specific deployment context | Yes, for a defined and narrow set of deployers |
A 42005 impact assessment is not a DPIA and is not a FRIA. Running one does not discharge either legal obligation. The converse is also true: a DPIA scoped tightly to personal-data processing will not cover societal impacts that involve no personal data at all.
Who Article 27 actually binds
The FRIA obligation is much narrower than the general commentary implies. Article 27(1) of the AI Act applies to deployers of high-risk AI systems that are bodies governed by public law, or private entities providing public services, and to deployers of the high-risk systems referred to in points 5(b) and 5(c) of Annex III — that is, creditworthiness evaluation and credit scoring, and risk assessment and pricing in life and health insurance. Systems intended to be used in the area listed in point 2 of Annex III are carved out.
If you are a private company deploying a high-risk AI system that is not a public service and not credit scoring or life-and-health insurance pricing, Article 27 does not apply to you. You may still owe a DPIA, and you may still want a 42005 assessment, but the FRIA duty is not yours.
Where it does apply, Article 27(1) lists what the assessment must contain: a description of the deployer’s processes in which the system will be used in line with its intended purpose; the period of time and frequency of intended use; the categories of natural persons and groups likely to be affected; the specific risks of harm likely to affect those categories, taking into account the information the provider supplied; a description of the human oversight measures implemented per the instructions for use; and the measures to take if those risks materialise, including internal governance arrangements and complaint mechanisms.
Article 27(2) requires the assessment before first use and allows a deployer, in similar cases, to rely on previously conducted fundamental rights impact assessments or on assessments the provider carried out. Article 27(3) requires the deployer to notify the market surveillance authority of the results using a filled-out template. Article 27(5) tasks the AI Office with developing that template questionnaire, including through an automated tool.
Article 27(4) is the provision that connects the regimes: where obligations under Article 27 are already met through a DPIA conducted under GDPR Article 35 or Article 27 of Directive (EU) 2016/680, the fundamental rights impact assessment shall complement that data protection impact assessment, and the deployer may cross-reference or incorporate the relevant parts. The drafting assumes overlap and tells you to build on what you have rather than duplicate it.
On timing: the date usually quoted for high-risk obligations is 2 August 2026, but that is the AI Act’s general application date under Article 113, not the date the Annex III high-risk rules bite. As the consolidated Article 113 now stands, Chapter III as it applies to Article 6(2) — the Annex III high-risk systems, which is where Article 27 lives — applies from 2 December 2027, with Article 6(1) Annex I systems following on 2 August 2028. Check the current consolidated text before you build a compliance calendar on a secondary source; this schedule has moved. Our EU AI Act high-risk compliance checklist tracks the wider obligation set.
Using 42005 as the backbone
The practical proposal in the legal commentary on this standard is to run one assessment process with three documentary outputs: use the ISO/IEC 42005 method as the common backbone, then graft on the mandatory contents that GDPR Article 35 and AI Act Article 27 each require, producing a DPIA, a FRIA and a 42005 record that share their evidence base and do not contradict one another.
That is sound on its own terms and it is how most organisations will avoid doing the same interviews three times. Two constraints are worth writing into your procedure so the shortcut does not become a false claim of compliance:
- The mandatory contents are mandatory. A 42005 assessment that omits, say, the Article 27(1)(f) complaint-mechanism description is not a FRIA, however thorough it is elsewhere. Map each legal element to a named section and check the mapping, do not assume coverage.
- The notification duty is separate from the document. Article 27(3) requires notifying the market surveillance authority on the AI Office template. No amount of internal documentation substitutes for the filing.
Where this lands in research administration
The gap 42005 fills is unusually visible inside universities. An institution deploying an AI tool in admissions, academic advising, or research computing already has two review processes, and neither one covers the question 42005 is asking.
The IRB reviews human-subjects research. An AI tool used to triage applications or flag students for intervention is administrative operations, not research, so it does not go to the IRB at all — and where it arguably does, IRBs have been left to work out the AI questions largely unaided, as we covered in IRBs on their own after the OHRP AI recommendations. The privacy office runs a DPIA or its institutional equivalent, which is scoped to personal data processing and does not ask whether the tool systematically disadvantages a group of applicants in a way that involves no privacy harm at all.
Between those two sits an administrative AI system affecting thousands of people with no review owner. ISO/IEC 42005 is a reasonable structure to fill that gap, and it has the advantage of being free of jurisdiction: it is guidance, so an institution can adopt it without waiting for a regulator. The modest claim is the right one — it gives research administration a defensible template for a review nobody currently owns, not a compliance credential.
A NIKOLAI contrast, not a mapping
CASRAI maintains NIKOLAI, its own independent dictionary of frontier AI safety terminology. NIKOLAI is unendorsed: crosswalk entries are CASRAI’s shadow readings of other organisations’ documents unless that organisation has filed a Mapping Declaration.
NIKOLAI’s risk level element, on track N4, is worth naming here specifically as a contrast rather than a mapping. Risk level describes the overall graded risk assigned to a model, a domain or a company activity as a whole — net risk after mitigations, at the level of a frontier model. A 42005 impact assessment is a different object: it is per-system and per-deployment-context, and it is about consequences for affected people rather than a graded label attached to a model. A frontier lab assigning a risk level and a university assessing the impact of an advising tool are not doing the same exercise, and the terms should not be substituted for one another.
Two dates that get misreported
- April 2025 for ISO/IEC 42005. Several summaries give April. The IEC webstore, as co-publisher, records the publication date as 28 May 2025. Use May 2025.
- 30 June 2025 as the publication date. That is the date BSI published the UK national adoption, BS ISO/IEC 42005:2025. It is an adoption date for a national standard, not the ISO/IEC publication date.
Frequently asked questions
Can an organisation be certified to ISO/IEC 42005?
No. ISO/IEC 42005:2025 is guidance, not a requirements standard, and no accredited certification scheme exists against it. The certifiable standard in this family is ISO/IEC 42001. A vendor advertising ISO 42005 certification is making a claim that cannot be true.
Does an ISO/IEC 42005 assessment satisfy GDPR Article 35?
No. A DPIA is a legal obligation with prescribed contents under GDPR Article 35. A 42005 assessment can be the methodological backbone you build a DPIA on, and doing so avoids duplicated work, but the DPIA-specific contents have to be present and identifiable for the obligation to be met.
Does a 42005 assessment satisfy the EU AI Act fundamental rights impact assessment?
No, for the same reason. Article 27(1) prescribes six categories of content, Article 27(3) adds a notification duty to the market surveillance authority using the AI Office template, and neither is discharged by an internal assessment written to an ISO guidance document. Article 27(4) does allow a FRIA to complement and cross-reference an existing DPIA, which is the only formal linkage between the regimes.
Which ISO/IEC 42001 clauses does 42005 support?
Clause 6.1.4, which requires establishing an AI system impact assessment process, and clause 8.4, which requires performing the assessment and retaining documented results. 42001 states both requirements without specifying the content of the resulting document; 42005 is the guidance that specifies it.
Do we need a FRIA if we are a private company?
Only if you are providing a public service with a high-risk AI system, or deploying one of the Annex III point 5(b) or 5(c) systems — creditworthiness evaluation and credit scoring, or risk assessment and pricing in life and health insurance. Most private deployers of high-risk systems fall outside Article 27 while still owing the other deployer obligations in the Act.
Sources
- IEC webstore listing for ISO/IEC 42005:2025 — designation, full title, edition 1.0, publication date 28 May 2025, 39 pages, ISO/IEC JTC 1/SC 42, ICS 35.020, and the published scope statement.
- BSI Knowledge listing for BS ISO/IEC 42005:2025 — UK national adoption published 30 June 2025, ISBN 978 0 539 23618 7, and BSI’s overview of the standard’s coverage.
- EU AI Act Article 27 and Article 113, consolidated text, for the FRIA deployer scope, the Article 27(1) contents, Article 27(2)-(5), and the application dates.
- Secondary legal commentary on ISO/IEC 42005 as a methodological backbone between the FRIA and the DPIA, and on its non-certifiable status.
- Secondary commentary on ISO/IEC 42001 clause 6.1.4 and clause 8.4.
Search-volume figures are deliberately absent from this page; our keyword data source was unavailable at the time of writing and we do not publish numbers we have not verified.
