ISO/IEC 42005: ISO/IEC 42005 – Tutorial (about 60 minutes)

ISO/IEC 42005 is the international guidance standard on AI system impact assessment: a structured way for an organisation to work out, before and while it uses an artificial intelligence system, how that system could help or hurt the people and communities it touches, and to write those findings down so that someone can act on them. It is used by AI developers, product owners, risk and compliance teams, privacy and ethics officers and auditors in any organisation that builds, provides or uses AI. After this tutorial you will be able to explain what the standard covers and why it exists, walk through its assessment process and documentation structure, run a basic impact assessment for a real system, and connect it to ISO/IEC 42001, ISO/IEC 23894, the NIST AI Risk Management Framework and legal assessments such as data protection and fundamental rights impact assessments.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current and only edition is ISO/IEC 42005:2025, Information technology – Artificial intelligence (AI) – AI system impact assessment, edition 1, published in May 2025 by ISO and IEC through their joint committee on artificial intelligence (ISO/IEC JTC 1/SC 42). It is a guidance document: it gives recommendations, not certifiable requirements. National bodies have adopted it unchanged, for example BS ISO/IEC 42005:2025 in the United Kingdom (June 2025) and AS ISO/IEC 42005:2025 in Australia (September 2025). Both catalogues list it as current, and no amendment or revision had been announced as of the verification date. Verified 2026-10-29 against the ISO catalogue listing (edition 1, 2025-05), the Standards Council of Canada database and the BSI catalogue entry.

Who this is for: engineers, data scientists and architects who build or integrate AI; product managers who decide where AI is used; risk, compliance, privacy, security and quality professionals who are asked to "assess the impact" of an AI system; and managers preparing for an ISO/IEC 42001 certification audit or for AI regulation.

Prerequisites: none. A rough idea of what machine learning does (a model learns patterns from data and then makes predictions, recommendations or content) helps, as does any experience with risk registers or privacy assessments. Every term is defined when it first appears.

By the end of this tutorial:

You will be able to explain why AI system impact assessment exists, what ISO/IEC 42005 covers and how it differs from organisational risk management.
You will be able to define the key vocabulary: impact, interested party, intended and unintended use, reasonably foreseeable misuse, sensitive use, threshold and impact scale.
You will be able to describe the two halves of the standard: the process for running assessments (clause 5) and the content of an assessment record (clause 6), plus what the five annexes add.
You will be able to plan when assessments happen across the AI system lifecycle, who does what and what should trigger a reassessment.
You will be able to carry out a basic impact assessment, from describing the system and its affected people to recording benefits, harms, failures, misuse and the measures taken.
You will be able to explain how the standard supports ISO/IEC 42001 certification and legal assessments, and why it cannot be certified on its own.
You will be able to avoid the most common mistakes that turn an impact assessment into an unread form.

Lesson 1 – Origins, purpose and scope

Why AI needs its own impact assessment

Most organisations already assess risk. Security teams run threat models, privacy teams run data protection impact assessments, finance teams track operational risk. So why did the international standards community write a separate document for AI systems?

The answer lies in who carries the consequences. Classic enterprise risk management asks, "What could go wrong for us?" – lost revenue, fines, reputation, outages. An AI system, however, often makes or shapes decisions about other people: who gets a loan, which job applicant is interviewed, which patient is seen first, which video a teenager is shown next, which neighbourhood receives more police patrols. The people affected by those decisions are rarely in the room when the system is designed. Some of them never chose to interact with the system at all. A harm to them may never appear as a loss on the organisation's books, and a benefit to them may never appear as revenue. AI also brings specific sources of trouble: models learn from historical data that may encode past unfairness, they can fail silently when the world changes, they are hard to explain, and they can be repurposed in ways their designers never imagined.

An AI system impact assessment turns the question outwards: what effects – good and bad – could this system have on individuals, on groups and on society, across its whole life? ISO/IEC 42005 gives organisations a common, internationally agreed way to answer that question systematically, and to keep a record that colleagues, auditors, customers and regulators can understand.

Where it comes from

The standard was developed by ISO/IEC JTC 1/SC 42, the joint subcommittee of ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) that is responsible for artificial intelligence. SC 42 has built a family of related documents:

ISO/IEC 22989 sets out AI concepts and terminology, and ISO/IEC 23053 describes a framework for AI systems that use machine learning. ISO/IEC 42005 builds on the ISO/IEC 22989 vocabulary (it is cited as a normative reference), so its terms are worth knowing before you read the standard.
ISO/IEC 23894 gives guidance on AI risk management, adapting the general risk management guidance of ISO 31000.
ISO/IEC 42001 (2023) specifies requirements for an AI management system. It is the certifiable standard of the family.
ISO/IEC 42005 (2025) explains how to assess and document the impacts of individual AI systems.
ISO/IEC 42006 sets additional requirements for the bodies that audit and certify AI management systems.

The link to ISO/IEC 42001 is the most important one in practice. ISO/IEC 42001 requires an organisation to define a process for assessing the potential consequences of its AI systems for individuals, groups of individuals and societies, to carry out those assessments and to keep the results as documented information. It does not, however, say in any detail how to do that. ISO/IEC 42005 fills that gap. Many organisations meet it for the first time while preparing for a 42001 certification audit.

Scope in plain words

According to its published scope, the standard offers guidance to organisations that perform impact assessments for the individuals and societies that an AI system, and its intended and foreseeable applications, can affect. It covers how and when to assess (including at which lifecycle stages), how to document the assessment, and how to fit the assessment process into the organisation's AI risk management and AI management system. Four points about this scope are worth stressing:

Any organisation, any size. It applies to organisations that develop AI, those that provide AI products or services to others and those that simply use AI bought from someone else.
Any AI system. It is not limited to "high-risk" systems in a legal sense. The organisation itself decides, using thresholds, how deep each assessment should go.
People and society, not the organisation. The focus is on effects outside the organisation's own interests. Organisational risk is handled by risk management; the two meet but are not the same.
Guidance, not requirements. The document recommends; it does not impose. Its wording uses "should" rather than "shall". That makes it flexible but also means nobody can be "certified to ISO/IEC 42005".

Finally, note what the standard does not do. It does not give a list of banned AI uses, a scoring formula that decides whether a system is acceptable, or a legal compliance checklist for any particular country. Those decisions stay with the organisation and with the laws that apply to it.

Lesson 2 – Key concepts and vocabulary

ISO/IEC 42005 builds on the vocabulary of ISO/IEC 22989. The definitions below are explanations in plain words, not the official wording.

AI system – an engineered system that, for a set of objectives defined by people, produces outputs such as content, forecasts, recommendations or decisions. It includes the model, the data pipelines and the surrounding software and human procedures.
AI system impact assessment – a structured, documented process for identifying and evaluating the effects that an AI system and its foreseeable applications may have on individuals, groups and society, and for deciding what to do about them.
Impact – any effect of the system on people or society. Impacts can be positive (benefits) or negative (harms), actual (already happening) or reasonably foreseeable (could plausibly happen).
Benefit – a positive impact, such as faster access to a service, more consistent decisions or earlier detection of illness. The standard expects benefits to be recorded alongside harms, because decisions involve trade-offs.
Harm – a negative impact, such as unfair treatment, loss of privacy, physical injury, financial loss, psychological distress or damage to the environment.
Interested party – a person or organisation that can affect, be affected by or perceive itself to be affected by a decision or activity (the term ISO uses where others say "stakeholder").
Directly affected interested parties – people on whom the system's outputs act directly, such as applicants scored by a model or users shown recommendations. They often have the least power over the system.
Intended use – the use for which the system was designed, with the users, purposes and conditions the organisation planned for.
Unintended use – a use outside that plan. Some unintended uses are innocent (a tool used in a new department), others are misuse.
Reasonably foreseeable misuse – a use the provider did not intend but that could readily be predicted from ordinary human behaviour, such as staff copying sensitive data into a chatbot or users treating a "suggestion" as a final decision.
AI system failure – the system not performing as expected: wrong outputs, degraded accuracy after the world changes (drift), outages or behaviour that breaks its own design limits.
Sensitive use and restricted use – categories the organisation defines for uses that need extra scrutiny (sensitive) or that are only allowed under specific conditions or approvals (restricted). Many organisations also define prohibited uses.
Threshold – a predefined criterion that decides when an assessment is needed, how deep it must go, or who must approve the result.
Impact scale – an agreed way of grading how serious an impact is, typically considering severity, how many people are reached, how likely it is and how reversible it is.
AI system lifecycle – the stages a system passes through, from inception and design through development, verification and validation, deployment, operation and monitoring, re-evaluation and finally retirement.
Measure – an action taken to reduce a harm or strengthen a benefit, for example a design change, human review, user guidance, a usage restriction or monitoring.

Impact assessment versus risk management

Because the words overlap, beginners often confuse impact assessment with risk assessment. ISO/IEC 42005 devotes an annex to the difference. A simple way to remember it: risk management looks at uncertainty from the organisation's point of view and asks how it affects the organisation's objectives; impact assessment looks at effects from the point of view of the people and society outside the organisation. A harm to a customer can be small for the company (a few complaints) yet severe for that customer (a wrongly denied medical claim). Impact assessment makes sure that second perspective is recorded and considered.

The two are connected. Findings from an impact assessment become inputs to risk management – an unfair outcome for applicants is also a legal and reputational risk for the company – and risk treatments often reduce harms to people. But one does not replace the other. An organisation that only runs a risk register will tend to underweight harms that never hit its own balance sheet.

Figure 1 – Impact assessment and risk management look at the same AI system from different viewpoints; impact findings feed risk decisions inside the AI management system.

Lesson 3 – Structure of the standard

ISO/IEC 42005 is short compared with many management system standards, and its structure is easy to learn once you see that it has two halves: how to run an assessment process and what to write down in each assessment. The clause titles below are the published table of contents; the descriptions are summaries.

Clauses 1 to 4 – the front matter

Clause 1 states the scope covered in Lesson 1. Clause 2 lists the normative references, notably ISO/IEC 22989 for AI vocabulary. Clauses 3 and 4 cover terms, definitions and abbreviations. The real content begins in clause 5.

Clause 5 – Developing and implementing an AI system impact assessment process

Clause 5 is about the organisation-level process, the machinery that makes assessments happen consistently rather than as one-off efforts. Its subclauses cover:

5.1 General – why the process is needed and the overall approach.
5.2 Documenting the process – describing the process itself, so it is repeatable.
5.3 Integration with other organizational management processes – connecting the assessment to risk, privacy, security, procurement and other processes.
5.4 Timing of AI system impact assessment – when in the lifecycle to assess and when to reassess.
5.5 Scope of the AI system impact assessment – deciding what each assessment covers.
5.6 Allocating responsibilities – who performs, contributes to, reviews and approves.
5.7 Establishing thresholds for sensitive uses, restricted uses and impact scales – the criteria that calibrate depth and escalation.
5.8 Performing the AI system impact assessment – carrying it out.
5.9 Analysing the results of the AI system impact assessment – interpreting findings and deciding on measures.
5.10 Recording and reporting – keeping the record and sharing results with the right audiences.
5.11 Approval process – who signs off, and on what basis.
5.12 Monitoring and review – keeping the assessment and the process current.

Clause 6 – Documenting the AI system impact assessment

Clause 6 describes the content of an individual assessment record, in effect a guided table of contents for the document you produce for each system:

6.1 General and 6.2 Scope of the assessment.
6.3 AI system information – description, functionalities and capabilities, purpose, intended uses and unintended uses.
6.4 Data information and quality – what data the system uses and how its quality is documented.
6.5 Algorithm and model information – the algorithms and models used and how they were developed, whether in-house or by a supplier.
6.6 Deployment environment – geographical area and languages, plus the complexity and constraints of the setting where the system runs.
6.7 Relevant interested parties – directly affected parties and other relevant parties.
6.8 Actual and reasonably foreseeable impacts – benefits and harms, and the impact of system failures and reasonably foreseeable misuse.
6.9 Measures to address harms and benefits – what the organisation will do about them.

Within 6.8, benefits and harms are considered under headings that will look familiar to anyone who has read about trustworthy AI, such as accountability, transparency, fairness and discrimination, privacy, reliability, safety, explainability and environmental impact. These headings are prompts that help assessors think broadly; they are not a scoring system.

The annexes

Five informative annexes support the main text:

Annex A offers guidance for using the standard together with ISO/IEC 42001.
Annex B relates it to ISO/IEC 23894: it explains the differences between risk management and AI system impact assessment and how risk management principles apply to impact assessment.
Annex C provides a taxonomy of harms and benefits to help assessors identify impacts systematically.
Annex D covers aligning an AI system impact assessment with other assessments, such as privacy, security or human rights assessments, through a coordination guide, an alignment guide and a mapping guide.
Annex E contains an example template for an AI system impact assessment, mirroring the sections of clause 6.

Figure 2 – Read top to bottom (dotted arrows give the order, solid arrows the contents): clause 5 sets up the organisation's assessment process and clause 6 defines what each assessment record contains, with annexes for alignment and a template.

Lesson 4 – How it works in practice

This lesson turns the structure into practical steps. Think of two layers. At the organisational layer you build the process once (clause 5). At the system layer you run that process for each AI system and produce a record (clause 6).

Step 1 – Build and document the process

Before assessing anything, decide how your organisation will assess. Write a short procedure that answers: which systems need an assessment; who starts it; which template is used; how depth is calibrated; who approves; where records live; and how often they are reviewed. Documenting the process is what turns a heroic one-off review into something a new team member can repeat and an auditor can check.

Integration matters as much as documentation. The impact assessment should be wired into processes that already exist: the project intake or design review where new AI ideas appear, procurement where AI products are bought, the change management process where models are retrained, the privacy process where data protection impact assessments are run, and the risk process where enterprise risks are reported. If the assessment is a separate island, teams will skip it or duplicate work. Annex D's coordination, alignment and mapping guidance exists precisely to avoid running five overlapping questionnaires about one system.

Step 2 – Decide the timing

The standard treats impact assessment as something that follows the system through its lifecycle, not a single gate before launch. A useful pattern is:

An initial assessment at inception or early design, when it is still cheap to change the purpose, data or approach, or to decide not to build at all.
An updated assessment before deployment, once real test results exist and the deployment environment is known.
Reassessment during operation when something significant changes – a new model version, new training data, a new country or language, a new group of users, a new purpose, a serious incident, a new law or evidence from monitoring that real-world performance differs from what was tested.
Periodic review at a fixed interval even when nothing obvious has changed, because the world around the system changes.
A final look at retirement, to consider people who depend on the system and what happens to data and records.

Figure 3 – Impact assessment accompanies the AI system lifecycle: an early assessment, an update before deployment, reassessment on significant change and periodic review in operation.

Step 3 – Set the scope and allocate responsibilities

Each assessment needs a clear scope: which system (and version), which uses, which deployment settings and which interested parties are covered. Scope also clarifies the organisation's role. A developer of a general-purpose model can describe intended uses and known limitations, but cannot know every setting where customers will deploy it; a deployer knows its setting well but may have limited information about the model. Each assesses what it can see, and the assessment notes what information came from suppliers and what is still missing.

Responsibilities should be named, not assumed. Typical roles include a system owner who is accountable for the assessment, an assessor or facilitator who runs it, contributors (data scientists, engineers, domain experts, legal, privacy, security, accessibility, customer service), independent reviewers, and an approver with real authority to say no. Larger organisations often use an AI governance committee for high-impact systems. The standard also encourages involving people with relevant perspectives from outside the build team; for systems that affect the public, that can include representatives of affected groups or civil-society experts.

Step 4 – Set thresholds and impact scales

Not every AI system deserves the same effort. A spam filter for internal email and a system that recommends prison sentences are both AI, but they are not equal. Thresholds let the organisation calibrate. Typical choices are:

Screening criteria that decide whether a light or a full assessment is needed: does the system make or materially influence decisions about people; does it touch health, safety, employment, credit, education, housing, policing or access to essential services; does it process sensitive data; does it affect children or other vulnerable groups; does it operate at large scale or without human review?
Use categories: sensitive uses that always need a full assessment, restricted uses that need special approval and conditions, and prohibited uses that the organisation will not pursue (including anything banned by law).
An impact scale that grades harms consistently, usually considering severity, breadth (how many people), likelihood and reversibility. A harm that is rare but irreversible and severe – a wrongful arrest – may outrank a frequent but trivial one.
Escalation rules that say who must approve at each level.

The standard does not prescribe the numbers or labels. It expects the organisation to define them, write them down and apply them consistently, so that two teams assessing similar systems reach similar conclusions.

Step 5 – Perform the assessment

Performing the assessment means filling in the clause 6 content with evidence. Practical techniques include structured workshops with the build team and domain experts; reviewing data sheets, model documentation and test reports; walking through realistic user journeys, including those of people with disabilities or limited language skills; brainstorming failures and misuse; consulting affected people or their representatives; and checking the harm and benefit headings one by one so nothing obvious is missed. Evidence beats opinion: "we tested error rates for each age group and found X" is far stronger than "we believe the model is fair".

Step 6 – Analyse results and decide on measures

Analysis means grading each identified impact against the impact scale, weighing benefits against harms, and deciding on measures. Measures can change the system (better data, constraints on outputs, confidence thresholds), change how it is used (human review, limits on purpose, user training, clear notices) or change the organisation's readiness (monitoring, complaint channels, incident response, contractual terms with suppliers). For each significant harm the record should show the measure, who owns it and when it will be done, and what impact remains afterwards. Sometimes the right conclusion is to narrow the scope, delay launch or not deploy the system at all; a process that can never reach that conclusion is not really assessing.

Step 7 – Record, report, approve, monitor

The assessment record is kept as controlled documented information. Reporting tailors it to audiences: a full version for the governance committee and auditors, a summary for executives, and often a plain-language version for users or the public, especially when transparency is part of the measures. Approval is a deliberate decision by someone with authority, made with the residual impacts in view. Finally, monitoring checks that measures were implemented and still work, watches the triggers for reassessment, and feeds lessons back into the process itself.

Figure 4 – The assessment cycle for one AI system, from screening and evidence gathering through measures and approval to monitoring and review.

Lesson 5 – Assessment, certification and compliance

No certificate for ISO/IEC 42005 itself

Because ISO/IEC 42005 is guidance written with "should" statements, there is nothing to certify against. No accredited certification body can issue an "ISO/IEC 42005 certificate", and any offer of one should be treated with caution. Training providers may offer course certificates about the standard, but these show learning, not organisational conformity.

How it is assessed in practice: through ISO/IEC 42001

Organisations usually meet external scrutiny of their impact assessments through ISO/IEC 42001 certification. In a 42001 audit, a certification body (itself accredited and, increasingly, operating under the additional requirements of ISO/IEC 42006) checks that the organisation has defined an impact assessment process, applies it to its AI systems, keeps the results as documented information and uses them in its risk treatment and controls. Annex A of ISO/IEC 42001 also includes controls on assessing impacts of AI systems.

Auditors are not obliged to see ISO/IEC 42005 by name, but it gives them, and you, a well-understood benchmark. Following it makes evidence easier to show. Typical things an auditor or internal reviewer looks for are:

A documented process with clear criteria for when assessments are required and how deep they go.
A complete inventory of AI systems, each with an assessment or a recorded screening decision.
Assessment records that cover the system, data, models, environment, interested parties, impacts and measures – not just a risk rating.
Evidence behind claims, such as test results broken down by relevant groups.
Named approvers and dated approvals, with residual impacts visible to the approver.
Follow-through: measures actually implemented, monitoring in place, reassessments triggered by changes.
Links from impact findings into the risk register and the statement of applicability of controls.

Internal quality checks

Even without external audit, organisations should check the quality of their own assessments. Practical methods include peer review by an assessor from another team, sampling a few records each quarter against the template, comparing assessments of similar systems for consistency, and reviewing whether incidents that occurred had been foreseen. If real-world harms keep appearing that no assessment anticipated, the process needs work.

Legal assessments: related but not the same

Many laws require their own assessments, and an ISO/IEC 42005 assessment can feed them, but following the standard does not by itself satisfy any law. Two examples:

The EU General Data Protection Regulation (GDPR) requires a data protection impact assessment (DPIA) before processing personal data that is likely to result in a high risk to people's rights and freedoms. A DPIA is limited to personal data processing and has legally defined content. An AI impact assessment can cover harms that involve no personal data at all, such as environmental effects or harms to a community.
The EU Artificial Intelligence Act requires certain deployers of high-risk AI systems – including public bodies, private entities providing public services, and deployers of systems for credit scoring and for life and health insurance pricing – to perform a fundamental rights impact assessment before first use, with content defined in the Act. Where a DPIA already covers some of the same obligations, the Act says the fundamental rights assessment complements it.

A sensible design is one shared process with several outputs: run a single, well-scoped AI system impact assessment, then map its sections to the content each law requires, filling any gaps. Annex D's mapping guidance supports exactly this. Note also that ISO/IEC 42005 is not a harmonised standard under the EU AI Act, so following it does not give a presumption of conformity with that law.

Question	Answer for ISO/IEC 42005
Can an organisation be certified to it?	No. It is guidance; certification is to ISO/IEC 42001.
Who checks it in practice?	Internal reviewers, internal audit and 42001 certification auditors, as evidence for impact assessment requirements.
Does it satisfy GDPR or the EU AI Act?	Not on its own. It can supply much of the content, which must then be mapped to each legal requirement.
Is it mandatory?	No. It is voluntary unless a contract, customer or regulator chooses to require it.

Lesson 6 – Worked example

To tie everything together, follow a fictional but realistic organisation through one assessment.

The organisation and the system

Kestrel Lending is a mid-sized lender serving small businesses in three countries. It already holds ISO/IEC 27001 certification and is preparing for ISO/IEC 42001. Its product team proposes "QuickDecision", an AI system that reviews small-business loan applications up to a set amount, produces a score and a recommendation (approve, refer to an underwriter, or decline), and uses a large language model to draft a plain-language explanation for the applicant. The scoring model is trained in-house on ten years of loan history; the language model is a commercial model accessed through a supplier's interface.

1. Screening and scope

Kestrel's documented process says that any system that materially influences access to credit is a sensitive use and needs a full assessment with approval by the AI governance committee. Fully automated declines are listed as a restricted use that requires extra conditions. QuickDecision triggers both. The assessment scope is QuickDecision version 1, used for small-business applications in all three countries, in English and two other languages, by applicants online and by Kestrel's underwriters.

Responsibilities are assigned: the head of small-business lending owns the assessment; a facilitator from the risk team runs it; contributors include two data scientists, an underwriter, the privacy officer, a lawyer, the customer complaints lead and an accessibility specialist; an internal auditor reviews the draft; the governance committee approves.

2. System, data, model and environment facts

The team fills in the clause 6 sections. The system information describes the purpose (faster, more consistent decisions on small loans), the capabilities (score, recommendation, explanation draft) and the intended users. It also lists unintended uses: underwriters reusing scores for larger loans outside the validated range; marketing staff wanting to use scores to target offers. The data section records the sources, time span and known gaps: historical approvals reflect past underwriter decisions, and businesses in rural areas and newly founded businesses are under-represented. The model section records the algorithm type, validation results, the external language model's supplier documentation and its known limitations. The deployment environment covers three countries with different consumer credit laws, three languages, and applicants who range from experienced finance managers to sole traders applying from a phone.

3. Interested parties

Directly affected parties are the applicants and the business owners behind them, including owners whose first language is not English and owners with disabilities. Other relevant parties include the underwriters whose work changes, employees of the applicant businesses (whose jobs may depend on the credit), Kestrel's regulators, and local communities where access to small-business credit matters for the economy.

4. Benefits and harms

Working through the harm and benefit headings, the team records, among others:

Benefits: decisions in minutes instead of days; more consistent treatment across branches; underwriters freed to spend time on complex cases; clearer written explanations than the old template letters.
Fairness and discrimination: because training data reflects past decisions, the model could replicate past disadvantages for rural and young businesses. Graded high (serious effect on livelihoods, many people, partly reversible through appeal).
Transparency and explainability: generated explanations might sound confident but not match the real reasons for a score. Graded high.
Privacy: application data sent to the external language model. Graded medium after checking the supplier's contractual terms.
Reliability: accuracy may fall in an economic downturn, when patterns differ from the training years. Graded medium.
Accountability: applicants may not know whom to contact to challenge a decline. Graded medium.
Environmental impact: modest compute use; recorded as low.

5. Failures and misuse

For failures, the team considers an outage (applications pile up; fallback to manual review), silent drift (scores degrade without anyone noticing) and the language model producing an explanation that contains a wrong reason or an inappropriate phrase. For reasonably foreseeable misuse, they note that busy underwriters may accept every "decline" recommendation without reading the file (automation bias), that staff may reuse scores for larger loans, and that applicants may try to game the form once they learn which fields matter.

6. Measures

The analysis produces a short, owned action list:

No fully automated declines: every decline recommendation goes to an underwriter, who sees the main factors behind the score and has authority and time to overturn it. Override rates are monitored.
Fairness testing: error and approval rates compared across region, business age, and other relevant groups before launch and monthly afterwards, with an agreed tolerance that triggers investigation.
Explanations are generated only from the actual top score factors, reviewed against a checklist, and sent with a clear route to request human review.
Technical controls block use of scores above the validated loan amount; marketing reuse is listed as a prohibited use.
Personal data sent to the language model is minimised, and the supplier contract prohibits training on it.
Drift monitoring with alerts, and an automatic reassessment if the model is retrained or a new country is added.

7. Record, approval and follow-up

The completed record, built on Kestrel's version of the Annex E style template, goes to the governance committee with the residual impacts clearly shown: fairness remains medium until three months of live monitoring confirm the test results. The committee approves launch in one country first, with a review after three months. The privacy officer reuses the relevant sections for the DPIA, and the lawyer maps the record to the content required by the applicable credit and AI laws. Six months later, when the data science team retrains the model on newer data, the change triggers a reassessment – which turns out to be quick, because the original record clearly shows what to recheck.

Figure 5 – In the worked example, each key harm is traced from an interested party to a measure, and the remaining impacts go to the approving committee.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 42005 is one piece of a larger landscape. Knowing its neighbours prevents both gaps and duplicated effort.

Standard or framework	What it is	How it relates to ISO/IEC 42005
ISO/IEC 42001 (AI management system)	Certifiable requirements for governing AI across an organisation	Requires an impact assessment process and records; 42005 explains how to meet that requirement well.
ISO/IEC 23894 (AI risk management)	Guidance on managing AI-related risk to the organisation, based on ISO 31000	Complementary: impact findings feed risk analysis; an annex of 42005 explains the differences and shared principles.
ISO/IEC 22989 and ISO/IEC 23053	AI concepts, terms and a machine learning system framework	Foundation documents: 22989 (a normative reference of 42005) supplies the vocabulary and lifecycle stages; 23053 describes the parts of an ML system being assessed.
ISO/IEC 42006	Requirements for bodies auditing and certifying AI management systems	Shapes how 42001 auditors examine impact assessment evidence.
NIST AI Risk Management Framework	Voluntary US framework with Govern, Map, Measure and Manage functions	Its Map function covers context and impacts; a 42005 record can serve as the impact evidence when an organisation uses both.
GDPR data protection impact assessment	Legal assessment for high-risk personal data processing	Narrower (personal data only) and legally defined; can reuse sections of a 42005 record.
EU AI Act fundamental rights impact assessment	Legal assessment for certain deployers of high-risk AI systems	Legally defined content; a 42005 assessment can supply evidence, mapped to the Act's elements.

Two relationships deserve a short comment. First, 42001 and 42005 are a pair: the management system says "you must assess and keep records", the guidance says "here is a sound way to do it". Second, ISO/IEC 23894 and ISO/IEC 42005 are siblings with different viewpoints. An organisation that uses both should make sure its impact findings actually flow into the risk register, and that risk decisions refer back to the impact record, rather than letting two teams produce disconnected documents about the same system.

Finally, remember that sector rules can add their own requirements, for example in medical devices, financial services, employment or public administration. The general-purpose structure of ISO/IEC 42005 makes it a good backbone onto which those sector-specific questions can be attached.

Common pitfalls and best practices

Common pitfalls

Assess once, file forever. Treating the assessment as a launch checkbox means drift, new uses and new users go unexamined.
Only the organisation's view. Writing a risk register in disguise, where every harm is expressed as a cost to the company, misses harms to people that never reach the balance sheet.
Ignoring benefits. Recording only harms makes trade-offs invisible and can lead to rejecting systems that would help people, or to approving harmful ones because no one wrote down what the benefit really is.
Intended use only. Skipping unintended uses, failures and reasonably foreseeable misuse leaves out the scenarios where most real harm occurs.
Template theatre. Filling every box with vague statements ("bias is low") and no evidence.
Approval without authority. An approver who cannot stop or delay a launch turns the approval step into a formality.
Parallel questionnaires. Running separate AI, privacy, security and legal assessments that never talk to each other, wasting effort and producing contradictions.

Best practices

Start early. Run a first assessment at the idea stage, when changing the design or deciding not to build is still cheap.
Calibrate with thresholds. Use clear screening criteria so high-impact systems get deep assessments and trivial ones get a light, recorded screening.
Involve diverse perspectives. Include domain experts, frontline staff, accessibility and legal specialists and, where impacts are significant, people from affected groups.
Use evidence. Support claims with test results broken down by relevant groups and conditions, supplier documentation and real-world monitoring data.
Own every measure. Give each measure an owner and a date, and track it to completion.
Define reassessment triggers. Write down which changes and incidents force a new look, and connect them to change management.
Assess once, report many ways. Keep one master record and map it to DPIAs, legal assessments and audit evidence.
Close the loop. Review incidents and complaints against past assessments to learn what was missed and improve the process.

Summary and key takeaways

ISO/IEC 42005:2025 (first edition, May 2025) is international guidance from ISO/IEC JTC 1/SC 42 on assessing and documenting the impacts of AI systems on individuals, groups and society.
Impact assessment looks outwards at people and society, while risk management looks at the organisation's objectives; the two feed each other but are not interchangeable.
Clause 5 sets up a repeatable process: documentation, integration, timing, scope, responsibilities, thresholds, performing, analysing, recording, approval and monitoring.
Clause 6 defines the record: system information, data, models, deployment environment, interested parties, benefits and harms, failures and misuse, and measures.
Assessments follow the lifecycle: early, before deployment, on significant change and periodically.
Thresholds, use categories and impact scales let an organisation match the depth of assessment to the stakes.
There is no certification to ISO/IEC 42005; it is used as evidence for ISO/IEC 42001 and as a backbone for legal assessments that still must be met on their own terms.
Good assessments rest on evidence, diverse perspectives, owned measures and real authority to change or stop a system.

Reflection questions

Pick an AI system your organisation uses or plans to use. Who are its directly affected interested parties, and which of them have no say in whether the system is used?
What screening criteria and impact scale would make sense for your organisation, and which uses would you classify as sensitive, restricted or prohibited?
Think of a realistic misuse of a system you know. Would it be "reasonably foreseeable" and what measure could reduce it without making the system useless?
Which existing processes in your organisation (design review, procurement, change management, privacy) should trigger or receive an AI impact assessment, and how would you connect them?
If an approver in your organisation reviewed an assessment showing a high residual harm, would they have the authority and information to delay the launch? What would need to change if not?