An AI system impact assessment is a “formal, documented process” for identifying, evaluating and addressing how an AI system affects individuals, groups of individuals and societies, as defined in ISO/IEC 42001:2023, definition 3.24 (official preview). ISO/IEC 42001 requires the process in clause 6.1.4 and requires you to run it in operation under clause 8.4. ISO/IEC 42005:2025, published by ISO in May 2025, gives guidance on how to do it.
The output is a dated, approved record for each AI system: who it can affect, how (positively or negatively), and what you will do about it. You finish it before the system ships and repeat it when the system or its use changes.
What ISO/IEC 42001 requires for an AI system impact assessment
ISO/IEC 42001 asks for an AI system impact assessment in three places. Clause 6.1.4 sets up the process during planning, and clause 8.4 requires you to perform it in operation. Annex A carries a group of impact assessment controls that you include or exclude in your Statement of Applicability. A guide that stops at 6.1.4 misses the operational repeat in 8.4.
| Where in ISO/IEC 42001:2023 | What it asks for | Record it produces |
| 3.24 AI system impact assessment | The term: a formal, documented process covering impacts on individuals, groups and societies | The definition your procedure cites |
| 6.1.4 AI system impact assessment (planning) | Define a process to assess potential consequences of an AI system’s deployment, intended use and foreseeable misuse, taking account of the technical and societal context and applicable jurisdictions; document the result; consider the result in the AI risk assessment (6.1.2) | Impact assessment procedure and a documented result per system |
| 8.4 AI system impact assessment (operation) | Perform impact assessments at planned intervals or when significant changes are proposed or occur; retain documented information of the results | Dated assessment records with version history |
| Annex A (normative), impact assessment controls | Controls on the assessment process and its documentation, with implementation guidance in Annex B (normative) | Statement of Applicability entries and the evidence behind them |
Sources: ISO/IEC 42001:2023 official preview (definition 3.24, clause titles and annex status); clause 6.1.4 and 8.4 wording as reproduced in published clause summaries; Annex B items B.5.2 to B.5.5 as numbered in the draft-era (FDIS) crosswalk contributed by Microsoft and listed on NIST’s AI Resource Center.
Note two details in clause 6.1.4: the assessment covers foreseeable misuse, not only intended use, and the result can be shared with relevant interested parties, so write it in language an outsider could read. The ISO/IEC 42001:2023 standard on iso.org is sold, so check the full clause text in your licensed copy.
The impact assessment sits in the planning step, after the scope and the AI system register, and alongside the risk assessment. If you already hold ISO/IEC 27001, see where this step fits in ISO 42001 implementation for ISO 27001 holders. The Annex A impact assessment group is one of the controls behind an ISO 42001 SoA.
How ISO/IEC 42005 structures the impact assessment process
ISO/IEC 42005:2025 splits the work in two: clause 5 tells you how to build and run an impact assessment process, and clause 6 tells you what to document for each system. ISO describes it as guidance for organizations conducting AI system impact assessments, covering effects on individuals, groups and society across the AI system life cycle.
The clause 5 process, in the order the standard lists it (official preview table of contents):
- Document the process (5.2). Write the procedure your organization will follow.
- Integrate it with other management processes (5.3). Connect it to risk management, privacy review, procurement and change control.
- Set the timing (5.4). Decide when an assessment must happen in the life cycle.
- Define the scope (5.5). Decide which system, version and uses one assessment covers.
- Allocate responsibilities (5.6). Name who assesses, who contributes and who decides.
- Set thresholds (5.7). Define sensitive uses, restricted uses and impact scales.
- Perform the assessment (5.8). Gather the facts and assess impacts.
- Analyze the results (5.9). Decide what the findings mean against your thresholds.
- Record and report (5.10). Write it up for the people who need it.
- Approve (5.11). Run the approval process.
- Monitor and review (5.12). Keep the assessment current after go-live.
Clause 6 lists the documentation headings: scope (6.2), AI system information (6.3), data information and quality (6.4), algorithm and model information (6.5), deployment environment (6.6), relevant interested parties (6.7), actual and reasonably foreseeable impacts (6.8) and measures to address harms and benefits (6.9). Five annexes follow: guidance for use with ISO/IEC 42001 (A), guidance for use with ISO/IEC 23894 (B), a harms and benefits taxonomy (C), aligning the impact assessment with other assessments (D) and an example template (E).
ISO/IEC 42005 is guidance, so there is no ISO/IEC 42005 certification; organizations certify against ISO/IEC 42001. Free previews show only its front matter and contents. Use ISO/IEC 42005 for the method and ISO/IEC 42001 for the requirement. If you also work to the NIST AI RMF, map these steps to Govern, Map, Measure and Manage alongside ISO 42001 clauses.
AI system impact assessment vs DPIA vs algorithmic impact assessment
An AI system impact assessment looks at the effects of an AI system on people and society, while a DPIA looks at risks to individuals from processing personal data. An algorithmic impact assessment is a policy term most often used for public agencies’ automated systems. The three overlap, and ISO/IEC 42005 has a whole annex (D) on aligning the impact assessment with other assessments.
| Attribute | AI system impact assessment | Data protection impact assessment (DPIA) | Algorithmic impact assessment |
| Defined or required by | ISO/IEC 42001 3.24, 6.1.4 and 8.4; guidance in ISO/IEC 42005 | GDPR Article 35, in the EU | Policy frameworks, such as the AI Now Institute’s 2018 framework for public agency accountability |
| Trigger | Every AI system in the AIMS scope, at planned intervals and on significant change | Processing likely to result in a high risk to individuals’ rights and freedoms | Set by the agency or framework that adopts it |
| Who it protects | Individuals, groups of individuals and societies | Individuals whose personal data is processed | Members of the public affected by government systems |
| Covers systems with no personal data | Yes | No | Depends on the framework |
| Timing | Before deployment, then in operation | Before the processing starts | Usually before procurement or deployment |
| Feeds | The AI risk assessment (6.1.2) and the Statement of Applicability | Privacy controls, and consultation with the regulator where residual high risk remains | Public notice and accountability measures |
Sources: ISO/IEC 42001:2023 official preview and published clause summaries; European Commission DPIA guidance; AI Now Institute, April 2018.
The European Commission’s DPIA guidance says a DPIA is required where processing “is likely to result in a high risk to the rights and freedoms of individuals” and should be done before the processing. A model with no personal data, such as a pricing model, can still affect people; the AI system impact assessment covers that gap.
Decision rules:
- Run both if the AI system processes personal data and its outputs affect people. Share the system description and data sections, and cross-reference the DPIA from the impact assessment record.
- Run the AI system impact assessment alone if no personal data is processed but outputs still reach people or communities.
- Extend your privacy assessment only if the template adds the 42005 headings for foreseeable misuse, groups and societal effects.
Privacy professionals who already run DPIAs bring much of this skill set with them, and it carries into AI governance roles from analyst to head of the function.
Impact assessment questions, grouped by stage
AI Training Skool’s question set turns the ISO/IEC 42005 headings into an interview script for a system owner. Each group names the heading it feeds; the questions are ours, not text from the standard.
Before the assessment: scope and thresholds (42005 5.5 and 5.7)
- Which system, version and use does this assessment cover, and what is out of scope?
- Is the use on your list of sensitive or restricted uses?
- Which impact scale will you use, and what level triggers escalation?
Describing the system (42005 6.3)
- What does the system do, in one paragraph a member of the public could follow?
- What is the intended use, and who are the intended users?
- What unintended uses or misuses are reasonably foreseeable?
Data, models and deployment (42005 6.4 to 6.6)
- Where does the training and input data come from, and how was its quality checked?
- Is the model built in-house, fine-tuned or bought from a supplier?
- In which states or countries, and in which languages, will it run?
People and impacts (42005 6.7 and 6.8)
- Who is directly affected by the output, and who is affected indirectly?
- Could any group be affected differently from others?
- What benefits and harms could follow from a failure, an error or foreseeable misuse?
Measures and decision (42005 6.9, 5.9 to 5.11)
- What measures reduce each harm, and who owns each one?
- Which impacts remain after the measures, and are they within your threshold?
- Who approves, and on what conditions?
After go-live (42005 5.12; 42001 8.4)
- What will you monitor to show the measures work?
- What change would force a new assessment?
- When is the next planned review?
A worked impact assessment example: fraud flags at a fictional credit union
This example is fictional and is here to show the method. The organization, figures and decisions are invented.
A US credit union plans to deploy a vendor model that freezes a card when a transaction scores above a threshold. A DPIA already covers the transaction data. The impact assessment asks what happens to members when the model is wrong.
| Impact found | Who is affected | Rating (example 1 to 5 scale) | Measure | Owner |
| Card frozen in error while traveling, leaving a member without funds | Members, especially those traveling | Severity 4, likelihood 3 | Freeze only after a text-message check; 24-hour unfreeze line | Head of card operations |
| Members with irregular spending patterns flagged more often | Groups whose spending looks unusual to the model | Severity 3, likelihood 3 | Monthly false-positive review by member segment | Model owner |
| Staff trust the score and stop checking | Members whose appeals are handled by staff | Severity 3, likelihood 2 | Reviewer guidance and a sample check of overrides | Fraud team lead |
| Fraud losses fall | All members | Benefit | Track and report quarterly | Finance |
Source: AI Training Skool fictional worked example.
Decision: approved with conditions by the risk committee, because two impacts reached the example escalation level; both went into the risk register with a reference to this record. Reassessment triggers: a vendor model update, a change to the freeze threshold, or an extension of the system to business accounts.
The assessment record: fields, purpose and clause
An assessment record is the document an auditor samples under clause 8.4. Use the fields below as a template, mapped to ISO/IEC 42001 and the ISO/IEC 42005 documentation headings.
| Field | Purpose | ISO/IEC 42001:2023 | ISO/IEC 42005:2025 heading |
| Assessment ID, version and date | Proves which version was in force when | 8.4, 7.5 | 5.10 |
| System name and register ID | Ties the record to one entry in the AI system register | 6.1.4 | 6.2 |
| Scope and exclusions | States what this assessment covers | 6.1.4 | 6.2 |
| System description, purpose, intended and unintended uses | Sets out what could go wrong, including foreseeable misuse | 6.1.4 | 6.3 |
| Data sources and quality | Shows where bias or error could enter | 6.1.4 | 6.4 |
| Algorithm and model information | Records build or supplier details and versions | 6.1.4 | 6.5 |
| Deployment environment, geography, languages, jurisdictions | Captures the technical and societal context | 6.1.4 | 6.6 |
| Affected interested parties | Names individuals, groups and communities affected | 6.1.4, 4.2 | 6.7 |
| Benefits and harms, failures and foreseeable misuse | Records the findings themselves | 6.1.4 | 6.8 |
| Measures, owners and due dates | Shows how each harm is addressed | 6.1.4, 6.1.3 | 6.9 |
| Risk register cross-reference | Shows the results were considered in the risk assessment | 6.1.4, 6.1.2 | Annexes A and B |
| Approval: name, role, date, conditions | Shows an authorized person accepted the result | 6.1.4 | 5.11 |
| Disclosure decision | Records whether and to whom results are shared | 6.1.4 | 5.10 |
| Next review date and change triggers | Shows when the assessment will be repeated | 8.4 | 5.12 |
Source: AI Training Skool record template, mapped to the ISO/IEC 42001:2023 clause titles (official preview) and the ISO/IEC 42005:2025 table of contents (official preview).
Two fields matter most at audit. Without the register ID, nobody can show every in-scope system was assessed; start from an AI system inventory for ISO 42001. Without the risk register cross-reference, nobody can show clause 6.1.4’s link to risk; impacts that threaten the organization’s objectives go into the risk register with the same reference number, as in a worked AI risk register.
When should you reassess an AI system impact assessment?
Reassess at the interval your procedure sets and whenever a significant change is proposed or occurs (clause 8.4). Define “significant change” in advance, as a list, so system owners cannot decide case by case.
Triggers worth writing into the procedure:
- A new model version, retraining or a supplier model change
- A new use, new user group or new decision the output feeds
- Expansion into a new state, country or language
- New or changed laws, regulator guidance or industry standards
- Incidents, complaints, odd outputs or poor user feedback
- Monitoring results that cross a threshold set in the original assessment
Most of these match the triggers in the IAPP article on how and when to conduct AI assessments (August 2024), which places assessments at procurement, before deployment and after it. ISACA’s guide to conducting an AI impact assessment (August 2025) makes the same point: define specific triggers for reassessment, such as changes to the system’s structure or functions.
Who conducts and who signs the impact assessment?
ISO/IEC 42001 does not name a signer. It requires a defined process, and ISO/IEC 42005 asks you to allocate responsibilities (5.6) and set an approval process (5.11). A note to clause 4.1 of ISO/IEC 42001 even lists “AI impact assessors” among example roles (official preview).
A pattern that holds up at audit:
- Assessor: runs the interviews, drafts the record and keeps it current; often the AIMS lead, a privacy professional or a risk analyst.
- Contributors: the system owner, data science, legal and privacy, a domain expert, and someone who understands the affected users.
- Approver: the system owner for impacts below your escalation threshold; a risk committee or top management above it. The approver should not be the person who drafted the record.
Impact assessments also appear among the duties named in US AI governance job postings; see AI governance hiring requirements in the US. If you want to practice the full chain, from register to impact assessment to risk register to Statement of Applicability, an ISO 42001 Lead Implementer course with a case study workbook works through each record end to end.
Frequently Asked Questions
What is the difference between ISO 42001 and ISO 42005?
ISO/IEC 42001:2023 is the certifiable management system standard; its clauses 6.1.4 and 8.4 require an AI system impact assessment process and repeat assessments in operation. ISO/IEC 42005:2025, published in May 2025, is guidance on running that assessment, with process steps in clause 5 and documentation headings in clause 6.
Can an organization get ISO 42005 certification?
No. ISO/IEC 42005:2025 provides guidance, not requirements, so there is nothing to certify against. Organizations certify their AI management system to ISO/IEC 42001:2023, and an auditor checks the impact assessment process under clauses 6.1.4 and 8.4. Following ISO/IEC 42005 is a way to show that process is well designed.
Is an AI impact assessment the same as a DPIA?
No. A data protection impact assessment covers risks to individuals from processing personal data and, under the GDPR, is required when processing is likely to result in a high risk to their rights and freedoms. An AI system impact assessment under ISO/IEC 42001 covers effects on individuals, groups and societies, including systems that use no personal data.
When is an AI system impact assessment required under ISO 42001?
Under ISO/IEC 42001:2023, you define the process during planning (clause 6.1.4) and perform assessments in operation at planned intervals or when significant changes are proposed or occur (clause 8.4). In practice, that means one before the system is deployed and another after each significant change to the model, its use or its users.
Who should conduct an AI impact assessment?
A named assessor, often the AI governance lead, a privacy professional or a risk analyst, runs it with the system owner, data science, legal and a domain expert. ISO/IEC 42005:2025 asks organizations to allocate responsibilities and define an approval process, and the approver should not be the drafter.
Is there an official ISO 42005 template?
Yes. ISO/IEC 42005:2025 includes an example AI system impact assessment template in Annex E, according to the official preview’s table of contents. The standard is sold by ISO and national standards bodies, not given away free. An ISO/IEC 42001 auditor does not require that template; any record works if it covers the clause 6.1.4 points and is approved and dated.
