ISO/IEC 42005:2025 · JTC 1/SC 42 · Implementation guide
The AI Impact
Assessment, Assembled
Everything ISO/IEC 42005 asks for, turned into a process you can run and a record an auditor will accept.
- Designation
- ISO/IEC 42005:2025
- Title
- AI system impact assessment
- Edition
- First — published 2025
- Committee
- ISO/IEC JTC 1/SC 42
- Document type
- Guidance, not requirements
- Certifiable
- No — supports 42001
Clause titles, the scope statement, the defined terms and the annex structure below are taken from the publicly viewable sections of ISO/IEC 42005:2025 on the ISO Online Browsing Platform. The body text of clauses 5 and 6 and of the annexes is not public, and none of it is reproduced here. Everything under “What it asks” and “What good looks like” is an implementation reading — written to be true to the clause title and the standard’s stated intent, and to be immediately usable. Buy the standard for the authoritative wording before you certify anything against it.
01What it is
ISO/IEC 42005 is the standard that tells an organisation how to work out who its AI system could hurt, who it could help, and what to do about the answer.
It sits in a small family of AI governance documents from ISO/IEC JTC 1/SC 42, and each member has a distinct job. ISO/IEC 38507 speaks to the board: what governing an organisation that uses AI implies for directors. ISO/IEC 23894 speaks to the risk function: how to run AI risk management, in the ISO 31000 idiom, for risk to the organisation. ISO/IEC 42001 is the certifiable management system that binds the whole thing together. ISO/IEC 42005 fills the gap none of the others fill directly — a disciplined method for assessing impact on other people: on individuals, on groups of individuals, and on society.
That distinction is the single most important thing to hold onto. A risk register asks “what could this cost us?” An impact assessment asks “what could this do to them?” The two overlap — a system that harms people usually ends up costing the organisation — but they are not the same exercise, they do not surface the same findings, and running one does not discharge the other. ISO/IEC 42005 exists because the second question kept getting collapsed into the first.
The standard is written as guidance. It uses “should”, not “shall”. You cannot be certified to ISO/IEC 42005 and no auditor will issue a certificate against it. Its practical force comes from elsewhere: ISO/IEC 42001 does require an AI system impact assessment process, and 42005 is the document that tells you what that process should contain. If you are pursuing 42001, treat 42005 as the how-to for clause 6.1.4, clause 8.4, and the whole of Annex A control area A.5.
It is also, increasingly, the bridge to regulation. Where a law demands a fundamental rights impact assessment or an algorithmic impact assessment, 42005 is the closest thing to an internationally agreed method for producing one. It does not make you compliant with any particular statute, but it gives you a defensible, repeatable process and a document trail — which is most of what a regulator is looking for.
02Scope and audience
The scope clause is short and worth reading closely, because it fixes four things.
| The scope fixes | Which means |
|---|---|
| Who is assessed for | Individuals and societies that can be affected by the AI system and its foreseeable applications — not the organisation’s own exposure. |
| When | The standard covers how and when to assess, and at which life cycle stages. Impact assessment is not a pre-launch gate you pass once. |
| What comes out | A documented assessment. The standard gives as much attention to the record as to the analysis. |
| Where it plugs in | Explicitly into AI risk management and into an AI management system — it is designed to be integrated, not run beside them. |
Who it is for. Organisations that develop AI systems, that provide them, or that use them — of any size, type or nature. That third category is the one people miss. If you buy a model or a SaaS product and point it at your customers, tenants, patients or applicants, you are in scope, and the impact on those people is yours to assess. The vendor’s assessment was written about a generic deployment; yours is about the actual one.
The most common scoping error is a deployer treating a supplier’s model card or assessment as their own. The supplier cannot know your affected population, your operational environment, your fallback when the system is unavailable, or what a wrong answer costs the person on the receiving end. Take the supplier’s document as an input to clause 6.5, not as your clause 6 output.
03The vocabulary
Nine terms are defined in clause 3. Four of them do real load-bearing work in the process, and teams that skip them tend to produce assessments that do not converge.
The definitions below are paraphrased. Clause 3 also imports the whole vocabulary of ISO/IEC 22989 (AI concepts and terminology) and ISO/IEC 23053 (ML system framework), which are the standard’s two normative references — so “AI system”, “model”, “training data” and the rest already have agreed meanings you should not redefine locally.
| Ref | Term | In plain terms |
|---|---|---|
| 3.1 | AI system impact assessment | A formal, documented process in which an organisation that develops, provides or uses an AI product or service considers the impacts on individuals, groups of individuals and societies. Note the two words doing the work: formal and documented. A conversation is not an assessment. |
| 3.2 | Intended use | The use the system was designed for. |
| 3.3 | Unintended use | Any use it was not designed for. |
| 3.4 | Intended users | The people or information systems the AI system was designed for. The standard deliberately extends the usual definition to cover machine consumers — an API caller is a user, and a downstream system that consumes your output uncritically is a channel for harm. |
| 3.5 | Interested party / stakeholder | Anyone who can affect, be affected by, or believe themselves affected by a decision or activity. Imported from ISO/IEC 42001. “Perceives itself to be affected” is in there on purpose — perceived impact is in scope. |
| 3.6 | Reasonably foreseeable misuse | Use in a way the developer or provider did not intend, but which follows from readily predictable behaviour by intended users. The notes make clear that predictable behaviour includes older people, children and people with disabilities — you are expected to think about the full range of real users, not an idealised one. |
| 3.7 | Restricted use | A use constrained by law, organisational policy or contract. |
| 3.8 | Sensitive use | A use that can have a significant adverse impact on individuals, groups or societies. |
| 3.9 | Top management | The people who direct and control the organisation at the highest level, with power to delegate authority and allocate resources. Imported from ISO/IEC 42001 — which is how the approval clause gets its teeth. |
Why 3.6, 3.7 and 3.8 matter more than the rest
Reasonably foreseeable misuse is the term that stops an assessment being a description of the happy path. It obliges you to write down what happens when someone uses the system in a predictable-but-unsanctioned way, and it sets the standard for that prediction at “readily predictable” — not “imaginative”, but not “only what we designed for” either.
Sensitive use and restricted use are the two categories that drive escalation. Clause 5.7 asks you to set thresholds for them in advance, so that when an assessment lands in one, the route it takes through your organisation changes automatically rather than by someone’s discretion.
04Document map
The standard has two operative clauses and five annexes. Clause 5 is the process. Clause 6 is the document that process produces. Almost everything practical lives in one of those two, and the annexes tell you how to connect them to what you already run.
| Part | Title | What it gives you |
|---|---|---|
| 1 | Scope | Boundaries and applicability |
| 2 | Normative references | ISO/IEC 22989, ISO/IEC 23053 |
| 3 | Terms and definitions | Nine terms; the rest inherited |
| 4 | Abbreviated terms | Acronyms |
| 5 | Developing and implementing an AI system impact assessment process | Twelve subclauses. The programme you stand up once. |
| 6 | Documenting the AI system impact assessment | Nine subclauses. The record you produce every time. |
| A | Guidance for use with ISO/IEC 42001 | How the assessment satisfies the management system |
| B | Guidance for use with ISO/IEC 23894 | How impact assessment and risk management interlock |
| C | Harms and benefits taxonomy | The categories to reason across |
| D | Aligning AI system impact assessment with other assessments | Coordination, alignment and mapping guides |
| E | Example of an AI system impact assessment template | A worked template to adapt |
Do not read it front to back. Read Annex E first to see what you are aiming at, then clause 6 to understand each field, then clause 5 to design the process that fills them, then Annexes A and B to wire it into your existing governance. Annex C is a working reference you keep open during every assessment, not something you read once.
05Clause 5 — the process
Twelve subclauses describing the programme: how assessments get triggered, scoped, staffed, performed, analysed, recorded, approved and revisited. You build this once and it governs every assessment thereafter.
General
Establish a defined, consistent, repeatable process rather than assessing ad hoc. Consistency is the point: two teams assessing comparable systems should reach comparable conclusions, and the same team assessing the same system twice should not diverge for reasons of method.
Evidence A named process owner and a process document that exists before the first assessment.
Documenting the process
Write the process down: methodology, inputs, outputs, decision points, who decides what, and the criteria they decide against. Version it. An undocumented process cannot be audited, improved, or defended after an incident.
Evidence A controlled procedure document with an owner, a version and a review date.
Integration with other organizational management processes
Hook the assessment into what already exists — the SDLC, change management, procurement, privacy review, security review, model governance. If impact assessment is a separate track people must remember to start, it will be skipped under delivery pressure. It should be impossible to ship without one.
Evidence A gate in the release pipeline or change process that cannot be closed without an assessment reference.
Timing of AI system impact assessment
Define when assessments happen across the life cycle: at conception, before deployment, on material change, on a periodic cadence, and after an incident. Early assessment is the only kind that can still change the design; late assessment can only document what was already built.
Evidence A trigger table (see §10 below) referenced from the SDLC.
Scope of the AI system impact assessment
Decide what a single assessment covers. A model? A product? A deployment of a product in one jurisdiction for one purpose? Get this wrong and you either drown in assessments or write one so broad it says nothing. The workable unit is usually one system in one intended use in one operating context — the same model serving a different purpose or population is a different assessment.
Evidence A scoping rule in the process document and a stated scope at the top of every assessment.
Allocating responsibilities
Name roles, not departments. Impact assessment is multidisciplinary by nature — product, engineering, data science, legal, privacy, security, domain experts, and where possible people who represent the affected population. Say who convenes, who contributes, who reviews and who signs.
Evidence A RACI, and named individuals on each completed assessment.
Establishing thresholds for sensitive uses, restricted uses and impact scales
Set the bar before you need it. Define what counts as a sensitive use, what is restricted or prohibited outright, and the scales you will use to rate severity and likelihood. Thresholds set in advance are governance; thresholds set once a finding is on the table are negotiation.
Evidence A published list of sensitive and restricted use categories, plus severity and likelihood scales with descriptors.
Performing the AI system impact assessment
The assessment itself: identify affected parties, identify potential and actual harms and benefits across the taxonomy, consider failures and reasonably foreseeable misuse, and gather the system, data and model facts that make the analysis meaningful. This is where the structure of clause 6 becomes the agenda for the working session.
Evidence A completed assessment record with the analysis traceable to inputs.
Analysing the results of the AI system impact assessment
Turn findings into decisions. Rate each impact on the scales from 5.7, weigh benefits against harms, identify what must be mitigated before deployment and what is monitored after, and decide whether the system proceeds, proceeds with conditions, or does not proceed. An assessment that never concludes anything is a document, not a control.
Evidence Rated findings with an explicit disposition against each.
Recording and reporting
Retain the record, and report it onward to whoever needs it — governing body, risk committee, customers, regulators, and in some cases the affected public. Decide the retention period and the disclosure posture deliberately; a redacted external summary alongside a full internal record is a common and defensible arrangement.
Evidence A register of assessments, a retention rule, and a defined reporting line.
Approval process
Define who approves, at what authority level, and what happens when approval is refused. Escalation should follow the thresholds from 5.7 — an assessment that touches a sensitive use goes higher than one that does not. Approval authority is where top management (3.9) enters the process.
Evidence A signed approval on each assessment, at an authority level matching its rating.
Monitoring and review
Assessments expire. Models drift, populations shift, the deployment moves into a new jurisdiction, a new failure mode appears in production. Define what triggers a re-assessment and how monitoring in production feeds back into the record. This closes the loop and is the subclause most often left as an aspiration.
Evidence Review dates on every assessment, plus production monitoring signals mapped to re-assessment triggers.
5.3 and 5.12. Integration determines whether assessments actually get done; monitoring and review determines whether they stay true. Organisations reliably invest in 5.8 — the assessment workshop feels like the real work — and reliably under-invest in these two, which is why so many impact assessment programmes produce a burst of documents in year one and nothing in year two.
06Clause 6 — the record
Nine subclauses specifying what the assessment document should contain. Read as a form, this is the most immediately useful part of the standard.
General
Document assessments in a structured, consistent way so they can be compared, reviewed and audited. Use one template across the organisation.
Scope of the AI system impact assessment
State precisely what this assessment covers and what it does not: the system, the intended use, the geography, the population, the life cycle stage, the version. The boundary you record here is what a later reader will rely on — and what makes it obvious when a change has moved the system outside it.
AI system information
Describe the system: purpose, capabilities, how it works at a level a non-specialist reviewer can follow, intended use and intended users, unintended and restricted uses, and the degree of human involvement in the decision it informs. Whether a human can realistically override the output — and whether they ever do — belongs here, because it changes almost every downstream harm rating.
Data information and quality
Where the data came from, what it represents, its provenance and lawful basis, its known quality characteristics and gaps, and how representative it is of the population the system will be applied to. Representativeness is the field that most often predicts a fairness harm, and the one most often filled in with a sentence.
Algorithm and model information
The model or algorithm, its version, how it was developed or acquired, evaluation results and known limitations, explainability characteristics, and — for a third-party or foundation model — what the supplier disclosed and what they did not. Version identifiers matter: an assessment that does not name a version cannot be checked against what is running.
Deployment environment
Where and how it actually runs: jurisdictions, languages, physical or organisational settings, the technical environment, operational constraints, and what happens when it is unavailable or degraded. The gap between the environment a system was evaluated in and the environment it is deployed into is where a surprising share of real harm originates.
Relevant interested parties
Who is affected — directly and indirectly. Users, decision subjects, people who are not users but who live with the outcome, workers whose jobs change, communities, and society at large. Include those with no relationship to you and no way to complain: they are usually the ones who absorb the harm.
Actual and reasonably foreseeable impacts
The heart of the document, and the only subclause with a further breakdown:
6.8.1 General — how to approach the impact analysis.
6.8.2 Benefits and harms — both sides, deliberately. The standard does not ask for a harms register; it asks for both, so that a decision to proceed can be reasoned rather than asserted.
6.8.3 AI system failures and reasonably foreseeable misuse — what happens when the system is wrong, unavailable, gamed, or used in a predictable way it was not designed for.
Measures to address harms and benefits
What you will do: mitigations for each material harm, measures to realise the benefits you claimed, owners, dates, residual impact after mitigation, and what is accepted knowingly. Both directions matter — a benefit asserted in 6.8.2 and never engineered for in 6.9 is not a benefit, it is a justification.
07Annexes A–E
Annex A — Guidance for use with ISO/IEC 42001
The bridge to the certifiable standard. If you are running an AI management system, this annex is how you demonstrate that your impact assessment process satisfies the management system’s requirements without maintaining two parallel bodies of work. Read it alongside 42001 clause 6.1.4, clause 8.4 and Annex A area A.5.
Annex B — Guidance for use with ISO/IEC 23894
The relationship with AI risk management. Its job is to keep the two disciplines distinct while letting them feed each other: impact assessment surfaces harms to people, which become inputs to organisational risk assessment; risk management supplies context, appetite and treatment machinery. The failure mode this annex is written against is a team that runs a risk workshop, ticks the impact assessment box, and never asks the impact question at all.
Annex C — Harms and benefits taxonomy
The reference categories. Its real function is completeness: without a taxonomy, teams reliably identify the harms in their own professional idiom — engineers find security harms, lawyers find compliance harms, and nobody finds the environmental or societal ones. Working through fixed categories forces coverage. Expanded in §8 below.
Annex D — Aligning AI system impact assessment with other assessments
Three sub-guides, and the most operationally valuable annex for a mature organisation:
- D.1 General — the alignment problem.
- D.2 Coordination guide — sequencing and running an AI impact assessment alongside privacy, security, human rights, safety and environmental assessments.
- D.3 Impact assessment alignment guide — where these assessments overlap and where they genuinely differ.
- D.4 Mapping guide — mapping fields between them so a fact captured once can serve several.
If you already run DPIAs under ISO/IEC 29134 or GDPR Article 35, this is where you learn how much of that work is reusable — a great deal of clauses 6.3 to 6.7 — and where it is not. The AI assessment’s reach beyond personal data to societal and environmental impact is the part a DPIA will never cover.
Annex E — Example of an AI system impact assessment template
A worked template. Start here on day one: it converts the abstraction of clause 6 into fields somebody can fill in. The version in §13 below is built to the same shape.
08Harms and benefits
Annex C supplies the categories. What follows is a working taxonomy in the same spirit — the dimensions an assessment should be able to say something about, even if the answer is “not applicable, and here is why”.
Harm dimensions
- Physical safety — injury or death, directly or through a decision the system informs
- Psychological — distress, manipulation, erosion of trust, dependency
- Fairness and discrimination — differential performance or treatment across groups, including proxies for protected characteristics
- Privacy and data protection — surveillance, inference of sensitive attributes, re-identification, secondary use
- Security — harm enabled by compromise, poisoning, extraction or adversarial manipulation
- Legal position and life opportunities — access to credit, housing, employment, education, healthcare, benefits, justice
- Autonomy and agency — decisions made about a person without meaningful recourse, explanation or human review
- Economic — financial loss, market exclusion, labour displacement, degradation of work
- Environmental — energy, water, hardware and carbon footprint of training and inference
- Societal and democratic — information integrity, discourse, institutional trust, concentration of power
- Cultural and linguistic — erasure or misrepresentation of groups, languages and contexts
Benefit dimensions
- Safety improvement — hazards detected earlier or more reliably than without the system
- Access and inclusion — service reaching people previously excluded by cost, distance, language or disability
- Accuracy and consistency — fewer errors, less arbitrary variation between decision-makers
- Timeliness — outcomes delivered fast enough to matter to the person waiting
- Relief from harmful work — removal of dangerous, degrading or repetitive tasks
- Economic — cost reduction, and specifically whether it is passed on to the affected population
- Environmental — efficiency gains that reduce material or energy consumption
- Knowledge — insight that would not otherwise exist and can be acted upon
Name the bearer. A harm without a named group is not assessable. “Bias” is not a finding; “applicants who did not attend a listed institution are ranked lower than their assessed performance justifies” is.
Check who gets which. Write down who receives each benefit and who bears each harm. When the benefit accrues to the organisation and the harm falls on the affected population, that asymmetry is itself the finding — and it is invisible in any format that lists benefits and harms in separate sections without attribution.
09Scales and thresholds
Clause 5.7 asks you to define impact scales in advance. The standard does not prescribe them. Here is a defensible starting set — adapt the descriptors to your domain, then freeze them.
Severity
| Level | Label | Descriptor | Reversibility |
|---|---|---|---|
| S5 | Severe | Death, serious injury, loss of liberty, or destruction of livelihood | Irreversible |
| S4 | Major | Loss of access to an essential service, employment or housing; significant financial loss; serious discrimination | Reversible only with major effort |
| S3 | Moderate | Material disadvantage, meaningful delay, notable distress, recoverable financial loss | Reversible on appeal |
| S2 | Minor | Inconvenience, minor delay, mild frustration | Readily reversible |
| S1 | Negligible | Barely perceptible to the affected person | Self-correcting |
Likelihood
| Level | Label | Descriptor |
|---|---|---|
| L5 | Almost certain | Expected in routine operation; observed in testing |
| L4 | Likely | Expected for some population segment within the first year |
| L3 | Possible | Plausible under conditions that will occur |
| L2 | Unlikely | Requires an unusual combination of circumstances |
| L1 | Rare | Only under conditions we can show are effectively precluded |
Three modifiers worth applying
Severity times likelihood is a starting point, not a verdict. Three factors should raise a rating irrespective of the arithmetic:
- Vulnerability of the bearer. The same error costs more when it lands on a child, a patient, someone with no digital access, or someone with no realistic route to complain.
- Absence of recourse. A harm the affected person can appeal, correct or escape is categorically different from one they cannot detect and cannot contest.
- Scale and concentration. A small error rate over a large population, systematically concentrated on one group, is not a small harm — it is a large one distributed thinly enough to be invisible in aggregate metrics.
Thresholds that trigger something
| Condition | Classification | What it triggers |
|---|---|---|
| Any residual harm at S5, at any likelihood | Restricted | Does not proceed without top management approval and a documented, time-bound justification |
| Residual S4 at L3 or above | Sensitive | Escalated approval; external or independent review; mandatory post-deployment monitoring |
| Affects access to an essential service, or a legally protected group differentially | Sensitive | Legal review; documented recourse mechanism; stakeholder consultation |
| Affected people cannot detect, contest or escape the outcome | Escalate | Recourse must be designed in before deployment |
| Anything on your prohibited-use list | Prohibited | Stop. No approval route exists. |
| Everything else, mitigated to S3 or below | Standard | Normal approval; scheduled review |
10Timing across the life cycle
Clause 5.4 asks when. This is the trigger table to adapt — the artefact that turns a policy into something that fires by itself.
| Stage or event | Assessment depth | Why here |
|---|---|---|
| Conception / business case | Screening — is this sensitive, restricted or prohibited? | The only moment the answer can still be “don’t build it” at no cost |
| Design | Full initial assessment | Mitigations can still be designed in rather than bolted on |
| Data acquisition | Update 6.4 | Representativeness and provenance become knowable |
| Model development / selection | Update 6.5, re-rate fairness and reliability harms | Evaluation results replace assumptions |
| Pre-deployment | Full assessment, approval gate | Last point before real people are exposed |
| Deployment to a new population, jurisdiction or purpose | New assessment | Outside the recorded scope of the existing one |
| Material change — model version, retraining, new data source, changed human oversight | Targeted re-assessment | The system in production is no longer the system assessed |
| Periodic — annually, or more often for sensitive uses | Review and re-rate | Drift, population change, shifting norms and law |
| Incident, complaint or adverse finding | Immediate re-assessment | Reality has produced evidence your model of harm was incomplete |
| Decommissioning | Closing assessment | Withdrawal has its own impacts on people who came to depend on it |
Decommissioning. Turning a system off is an impact event: people who reorganised their work around it, dependents downstream, and the population that loses a service. Where the system was the only channel to something essential, withdrawal can be the largest single impact in its life.
11Who does what
Clause 5.6 asks for allocated responsibilities. A workable default, to be adjusted to your structure.
| Role | Responsibility | Signs off? |
|---|---|---|
| Process owner | Owns the method, the template, the thresholds and the register; reports on programme health | No — owns the process, not the outcome |
| Assessment lead | Convenes and runs the assessment; owns the completed record | Attests to completeness |
| Product owner | Supplies purpose, intended use, users, and the business case for benefits claimed | Owns delivery of 6.9 measures |
| Engineering / data science | Supplies 6.4, 6.5, 6.6 — data, model, evaluation results, limitations, environment | Attests to technical accuracy |
| Domain expert | Knows what actually happens to the person on the receiving end | No, but their absence is a defect |
| Legal / privacy | Regulatory exposure, lawful basis, protected characteristics, recourse obligations | Yes, for sensitive and restricted uses |
| Security | Failure modes, adversarial misuse, compromise-enabled harm | Yes, where security-enabled harm is material |
| Affected-party representative | Speaks for the people assessed about — a user researcher, an advocate, a consultation, or the people themselves | No, but should be recorded as consulted |
| Approver | Accepts residual impact at the authority level the rating demands | Yes — this is the signature that matters |
| Top management | Approves restricted uses; allocates resource; owns the programme | Yes, for restricted uses |
12Fitting it to 42001 and the law
ISO/IEC 42001
This is the mapping that pays for the effort. If you are certifying to 42001, a 42005-shaped process is how you satisfy these:
| 42001 | Requirement | Served by |
|---|---|---|
| 6.1.4 | AI system impact assessment — plan the process as part of addressing risks and opportunities | Clause 5 in full |
| 8.4 | AI system impact assessment — perform it operationally and retain documented information | Clauses 5.8–5.10, and clause 6 |
| A.5.2 | AI system impact assessment process | Clauses 5.1–5.7 |
| A.5.3 | Documentation of AI system impact assessments | Clause 6 and Annex E |
| A.5.4 | Assessing AI system impact on individuals or groups of individuals | Clauses 6.7, 6.8 and Annex C |
| A.5.5 | Assessing societal impacts of AI systems | Clause 6.8 and the societal dimensions of Annex C |
| 6.1.2 / 8.2 | AI risk assessment | Fed by impact findings — see Annex B |
ISO/IEC 23894 — risk management
Run them as one cycle with two lenses. The impact assessment identifies harms to people; those harms, once rated, become risk sources in the organisational register with their own treatment and appetite decisions. The traffic runs the other way too: risk context, appetite and controls constrain what an impact assessment can accept. Keep the artefacts distinct — a merged document invariably drifts toward the organisational lens, because that is the one with a budget attached.
Privacy — ISO/IEC 29134, ISO/IEC 27701, GDPR Article 35
Substantial overlap in clauses 6.3 through 6.7: system description, data provenance, affected parties, deployment context. Capture those facts once and let both assessments read them, which is exactly what Annex D’s mapping guide is for. What does not transfer: a DPIA is bounded by personal data processing, and 42005 reaches past it to fairness, safety, autonomy, environmental and societal impact — including where no personal data is involved at all. A DPIA is never a substitute.
EU AI Act
Article 27 requires certain deployers of high-risk AI systems — public bodies and some private operators — to carry out a fundamental rights impact assessment. The Act does not name ISO/IEC 42005, and conformity with the standard does not confer compliance with the Regulation. But the Article 27 fields map closely onto clause 6: process description, period and frequency of use, categories of affected persons, specific risks of harm, human oversight arrangements, and the measures taken when risks materialise. If you build to 42005, you are producing most of the FRIA content as a by-product, and the residue is a mapping exercise rather than a new programme.
NIST AI RMF
Complementary rather than overlapping. The RMF’s Map function asks many of the same context questions; Measure and Manage correspond loosely to clauses 5.9 and 6.9. Organisations running both typically keep the RMF as the outer operating frame and 42005 as the method for the impact-specific portion.
13The assessment template
Built to the shape of clause 6 and in the spirit of Annex E. Adapt the wording; keep the field set. Every field should be answerable — “not applicable” is a valid answer, an empty field is not.
Identification
- Assessment ID, version, date, next review date
- AI system name and version identifier
- Assessment lead, contributors, consulted parties
- Classification: standard / sensitive / restricted
- Approval: name, role, date, conditions attached
Scope
- What this assessment covers — system, use, version, life cycle stage
- Geographies, jurisdictions, languages
- Population and approximate number of people affected
- Explicitly out of scope, and why
- Trigger: initial / change / periodic / incident
AI system information
- Purpose and the decision or task it supports
- How it works, at a level a non-specialist reviewer can follow
- Intended use and intended users (including machine consumers)
- Unintended uses; restricted uses; prohibited uses
- Degree of autonomy; where a human is in the loop, and whether that override is real in practice
- What the person affected is told, and when
Data information and quality
- Sources, provenance, lawful basis, licensing
- Categories of data, including personal and special-category data
- Known quality characteristics, gaps and defects
- Representativeness relative to the deployed population, stated by segment
- Labelling process and its known biases
- Retention, deletion and update regime
Algorithm and model information
- Model or algorithm, version, build or acquisition route
- Third-party and foundation model dependencies; what the supplier disclosed and what they did not
- Evaluation results, including disaggregated performance by relevant segment
- Known limitations and failure modes
- Explainability: what can be explained, to whom, in what terms
- Update and retraining regime
Deployment environment
- Physical, organisational and technical setting
- Jurisdictions and applicable law; languages supported and not supported
- Operational constraints — connectivity, device, literacy, accessibility
- Integration points and downstream consumers of the output
- Behaviour when unavailable or degraded; the manual fallback and who can run it
Relevant interested parties
- Directly affected: users, decision subjects
- Indirectly affected: dependants, communities, workers, non-users living with the outcome
- Vulnerable groups within each population
- Who was consulted, how, and what they said
- Who could not be consulted, and what stands in for them
Actual and reasonably foreseeable impacts
One row per impact. Both directions, in one register, so the trade-off is visible on a single page.
- Direction: benefit or harm
- Taxonomy category (from §8)
- Who bears or receives it — named group, not “users”
- Description of the mechanism, not just the label
- Inherent severity × likelihood
- Evidence or basis for the rating
- Modifiers applied: vulnerability, absence of recourse, scale
6.8.3 — failures and misuse. A separate block:
- What a false positive costs the person; what a false negative costs them
- Behaviour under distribution shift and on out-of-scope inputs
- Behaviour when unavailable, slow or degraded
- Reasonably foreseeable misuse by intended users — including the predictable workaround
- Adversarial misuse: gaming, evasion, poisoning, extraction
- Automation bias — what happens when the human reviewer stops genuinely reviewing
Measures
- Per harm: mitigation, owner, date, residual severity × likelihood after mitigation
- Per benefit: what is being done to actually realise it, and how it will be measured
- Recourse mechanism — how an affected person contests an outcome, and how they learn it exists
- Monitoring in production: signals, thresholds, who watches them, what they trigger
- Residual impact accepted, by whom, on what basis
- Conditions on approval and the date they are checked
14A worked example
A short, deliberately uncomfortable one — an AI-assisted triage prioritisation aid in a hospital emergency department. Abbreviated to show the shape of the reasoning, not to be copied.
Scope (6.2)
Model v2.3 suggesting a triage acuity level to the triage nurse at one hospital’s ED, adults only, English and Thai, from vital signs and presenting complaint. Nurse assigns final acuity. Paediatric presentations and ambulance pre-alerts are out of scope.
Interested parties (6.7)
Patients presenting to the ED — the decision subjects, who never see the model and cannot contest it. Triage nurses, whose judgement it displaces or supports. Patients elsewhere in the queue, affected by every reprioritisation. Families. The hospital. Directly affected but easy to miss: patients presenting with atypical symptoms, in a language the model handles less well, or with conditions under-represented in the training data.
Benefits (6.8.2)
- Safety Earlier detection of deteriorating patients who present without dramatic vitals — the case triage most reliably misses. To patients.
- Consistency Less variance between nurses and across shifts, particularly at 4am. To patients.
- Timeliness Shorter time-to-decision under surge. To patients and staff.
Harms (6.8.2, 6.8.3)
- S5 / L3 Under-triage of a genuinely critical patient whose presentation is atypical. Irreversible; borne by the patient. Modifier: no recourse — the patient never knows a model was involved.
- S3 / L4 Over-triage displacing another patient down the queue. Distributed, invisible, and systematically borne by whoever the model under-scores.
- S4 / L3 Differential accuracy for presentations under-represented in training data — older patients, women presenting with cardiac symptoms, non-English speakers.
- S4 / L4 Automation bias: within months, nurses concur with the suggestion at a rate that makes “the nurse decides” a formality. The stated safeguard erodes silently.
- S4 / L2 Unavailability during surge — precisely when the department has least capacity to fall back to unaided triage.
What the analysis produces (5.9, 6.9)
The classification is sensitive — an S5 harm at L3, on a population that cannot detect or contest the outcome, in a setting where access to care is at stake. That drives escalated approval, independent clinical review and mandatory post-deployment monitoring.
The most instructive finding is the fourth harm, because it is invisible to conventional evaluation. Automation bias is not a model defect; the model may be performing exactly as validated. It is a defect in the sociotechnical system — the kind of harm clause 6.3’s question about human oversight is designed to surface, and the kind a purely technical review will never find. The mitigation is not a better model. It is measuring the concurrence rate as a monitored signal with a threshold that triggers review, presenting the suggestion in a way that does not anchor the nurse, and periodically running unaided triage to keep the skill and the comparison alive.
The benefits accrue broadly and are measurable in aggregate: shorter waits, better throughput, fewer missed deteriorations across thousands of patients. The severe harm is rare, individual, and lands on someone who will never know it happened. That asymmetry is exactly what an impact assessment exists to make visible — and exactly what a metrics dashboard, optimised on averages, will report as a success.
15Where it goes wrong
Assessing the organisation instead of the people
The commonest failure by a distance. Findings come out phrased as reputational, legal or regulatory exposure. If every entry in your impact register would fit in a corporate risk register unchanged, you ran a risk assessment and labelled it an impact assessment.
Doing it after the design is frozen
An assessment written the week before launch cannot change anything. It documents. Screen at conception and assess at design, or accept that the exercise is compliance theatre.
Never talking to anyone affected
Clause 6.7 asks who is affected. A room of employees guessing is weak evidence. Consultation need not be elaborate — a user researcher, an advocacy group, a handful of structured conversations — but its complete absence is a defect worth recording in the document itself.
Harms without bearers
“Risk of bias.” “Potential privacy concerns.” Unrateable, unmitigable, and unfalsifiable. Every entry needs a named group, a mechanism and a consequence.
Benefits asserted, never engineered
Benefits appear in the assessment because they justify proceeding, then never appear in clause 6.9 with an owner and a measurement. If you claimed the system would widen access, the assessment should say who is accountable for that and how it will be checked.
A template so long nobody completes it honestly
Past a certain length, teams optimise for finishing rather than for truth. Better to have a shorter template completed seriously, with a deeper one reserved for sensitive uses, than a comprehensive one filled with defensive boilerplate.
One assessment for a system that has since changed
Retraining, a new data source, a new market, an oversight step quietly removed for throughput. Without clause 5.12 triggers, the assessment describes a system that no longer exists, which is worse than no assessment at all — it provides false assurance.
Human oversight recorded as present when it is nominal
A human who can override in principle but overrides one time in a thousand, under time pressure, without the information needed to disagree, is not oversight. Assess the oversight you will actually get, and instrument it.
16A 90-day rollout
For an organisation starting from nothing. It gets you a working process and a real portfolio view in one quarter.
-
Days 1–10 · Inventory
List every AI system you develop, provide or use — including the embedded ones nobody calls AI, and the SaaS features switched on last year. You cannot assess a portfolio you have not enumerated, and the enumeration is usually the surprise.
-
Days 10–20 · Screen and triage
Run a one-page screen over the inventory: who is affected, could a wrong answer harm them, is this a sensitive or restricted use. Rank by exposure. Most systems will not need a full assessment; a few will need one urgently.
-
Days 15–30 · Set thresholds
Define sensitive uses, restricted uses, prohibited uses, and the severity and likelihood scales — clause 5.7. Do this before the first real assessment, or the first hard case will set your precedent for you.
-
Days 25–40 · Build the template
Adapt Annex E and §13 above into a template fitting your domain vocabulary. Keep the field set; cut the ceremony. Pilot it on one system and rewrite whatever proved unanswerable.
-
Days 35–60 · Assess the top three
Take the three highest-exposure systems and assess them properly, with the real multidisciplinary group and at least one voice for the affected population. These become your reference examples, so run them as if they will be read by an auditor — because they will.
-
Days 50–70 · Wire it in
Clause 5.3. Put the gate in the SDLC, the change process and procurement. Make an assessment reference a required field on the release record. This is the step that decides whether the programme survives contact with a delivery deadline.
-
Days 60–80 · Approval and register
Stand up the approval routes by classification and the register of assessments with review dates. Agree the reporting line to the governing body and what they will see each quarter.
-
Days 75–90 · Close the loop
Clause 5.12. Define re-assessment triggers, map production monitoring signals onto them, and put the first review dates in the calendar with owners. Then run a retrospective on the three pilot assessments and fix the method.
17What it will not do
Worth stating plainly, so the standard is bought for what it is.
- It is not certifiable. Guidance, not requirements. Certification happens against ISO/IEC 42001; 42005 helps you get there.
- It does not make you compliant with any law. It gives you a defensible method and a document trail. Regulatory mapping is separate work.
- It does not tell you what is acceptable. It gives you a process for surfacing and rating impacts. Where the line sits — which residual harms you will accept, for which benefit, borne by whom — is your organisation’s judgement, and the standard deliberately leaves it there.
- It does not supply the domain expertise. The taxonomy tells you which categories to consider. Knowing what actually happens to a patient, a tenant, an applicant or a claimant is knowledge you bring to the room.
- It will not survive without integration. An impact assessment programme that lives outside the delivery process is a programme with a shelf life of about one year.
18Sources
- ISO/IEC 42005:2025 on the ISO Online Browsing Platform — foreword, introduction, scope, normative references, terms and definitions, and the full table of contents are publicly viewable. The body of clauses 5 and 6 and the annexes are not.
- ISO catalogue entry — ISO/IEC 42005:2025 and the IEC webstore entry.
- Referenced within the standard: ISO/IEC 22989 and ISO/IEC 23053 (normative); ISO/IEC 42001:2023, ISO/IEC 23894:2023, ISO/IEC 38507:2022, ISO/IEC 29134:2023, ISO/IEC 5259 series, ISO/IEC TR 24027:2021, ISO/IEC TS 12791:2024, ISO/IEC TR 20226 and ISO/IEC Guide 51:2014 (bibliography).
- ISO/IEC 42001:2023 clause structure confirmed from the publicly available preview: clause 6.1.4 and clause 8.4 are both titled AI system impact assessment; Annex A area A.5 is Assessing impacts of AI systems.
- Public commentary consulted for clause-level detail: Cyberzoni, CMS Law, Nemko Digital, ISMS.online on 42001 A.5.
- Companion guides in this series: ISO/IEC 42001 — the AI management system and ISO 19011:2026 — auditing management systems.
ISO/IEC 42005:2025 is a copyrighted work of ISO and IEC. Nothing in this guide reproduces its text beyond clause titles and the publicly viewable scope and definitions, which are paraphrased. It is an independent implementation reading, not a substitute for the standard, and not endorsed by ISO or IEC. Purchase the standard before relying on it for conformity work.