What ISO 42001 AI impact assessment requires and who does it
If a customer questionnaire, contract or regulator asks for ISO 42001 evidence on AI impacts, the answer starts here: ISO/IEC 42001 requires your organization to run AI system impact assessments, once during planning under clause 6.1.4 and again during operation under clause 8.4, and to keep these separate from AI risk assessment under clauses 6.1.2 and 8.2. Your organization owns the assessment and its conclusions. An external certification body may audit the management system and issue a certificate, but it does not perform or sign off your impact assessments on your behalf, and an implementation partner can only prepare the systems and records that the assessment draws on. The effort differs considerably between organizations because the assessment is scoped by what the organization actually does with AI. The inputs that drive it include which AI systems are in scope, whether the organization builds them, supplies them or only uses them, the purposes they serve, and which groups of people or parts of society they could affect, such as applicants, patients, employees or customers in a particular region. An organization running one internal productivity tool faces a very different workload from one that makes automated decisions about credit, hiring or care. Before any work starts, confirm with the customer or auditor which systems and affected groups the questionnaire covers, because that boundary sets the size of the assessment.
A practical first step is an inventory that links each in-scope AI system to its intended purpose, the people it touches and the decisions it informs. The Annex A controls under objective A.5 give the structure for that work: A.5.2 defines the assessment process, A.5.3 requires its documentation, A.5.4 addresses impacts on individuals or groups, and A.5.5 addresses societal impacts. Whether your statement of applicability includes each of these, and how you justify any exclusion, is a decision for your management, and an auditor will test that justification. ISO/IEC 42005:2025, which the organization can use as guidance for this work, is a separate standard that covers the same human and societal ground in more depth. Confirm with your certification body whether it expects the guidance to be followed or only referenced.
What the four A.5 controls ask the organization to show
The four A.5 controls turn impact assessment from a principle into records an assessor can sample. Each card below names one control, the evidence an assessor would expect to see, and what to confirm in the statement of applicability under clause 6.1.3 before deciding whether a control applies.
A.5.2 AI system impact assessment process
This control asks for a defined process that decides when an AI system needs an impact assessment, who runs it and how its outcome feeds back into planning and operation. An assessor will look for a written procedure, trigger criteria tied to use cases and affected groups, and records showing the process ran for each system in scope. The Annex B guidance for this control maps to AI RMF MAP 1.1, MAP 3.1 to 3.3 and MAP 5.1 in the NIST crosswalk, which is a useful reference for aligning terminology. Confirm that the process covers both planning and operation, since clauses 6.1.4 and 8.4 require assessment at both points.
A.5.3 Documentation of AI system impact assessments
This control asks that each impact assessment be recorded in a way that someone outside the project can follow. An assessor will expect a dated assessment record for each system, the intended purpose and context, the methodology used, identified impacts, the people who approved the outcome and a link to any resulting changes in design or controls. Records that exist only in meeting notes or email rarely satisfy this. Check that every assessment has an owner, a version and a review date.
A.5.4 Assessing impact on individuals or groups
This control asks the organization to examine how a system may affect individuals or identifiable groups, including people who never interact with it directly. An assessor will look for evidence that the assessment considered affected groups, foreseeable misuse, potential harms such as discrimination or privacy loss, and the safeguards chosen in response. ISO/IEC 42005:2025 offers guidance on this scope and is a natural reference for the work. Confirm that the affected groups are named in the record, not described only as users.
A.5.5 Assessing societal impacts of AI systems
This control asks the organization to consider effects beyond individuals, such as on public trust, democratic processes, labor markets, the environment or other communities. An assessor will expect evidence that these wider effects were considered for systems where they are plausible, a rationale when they were judged not relevant, and a record of who was consulted. Because the scope of societal impact depends on the use case, the assessment should explain its reasoning rather than leave the question blank. Confirm the rationale for each exclusion in the statement of applicability.
How an AI impact assessment runs across the life cycle
The sequence moves from defining the AI system and its foreseeable uses to recording, acting on and re-checking impacts after deployment, so each phase hands a documented output to the next. ISO/IEC 42005 recommends running it from design through post-market monitoring rather than as a one-time sign-off.
Define the AI system and its foreseeable applications
The system owner, with product and business stakeholders, describes what the AI system does, the decisions or outputs it produces, the settings where it will be used, and the uses the organization does not intend but can reasonably foresee. The output is a scoped system description that names its intended purpose, deployment context and the boundary of the assessment. The step is complete when someone outside the build team can read the description and identify what is in and out of scope, and when the list of foreseeable applications has been reviewed by the people who will operate the system.
Identify affected individuals, groups and society
The assessment team lists who the system touches directly and indirectly, including end users, people subject to its outputs, groups who may be treated differently by it, and wider societal interests. Input from domain experts, legal and privacy staff and, where practical, representatives of affected groups improves this list. The output is a register of affected parties and the relationship each has to the system. The step is complete when each group is named specifically enough that a later harm can be traced back to it, and the register is approved by the accountable owner.
Characterize benefits, harms, failures and misuse
For each affected group, the team describes the benefits the system is expected to deliver, the harms it could cause, the ways it could fail, and the foreseeable misuse that could produce harm. Failure modes include wrong outputs, degraded performance for some populations and unavailability, and misuse includes use outside the stated purpose. The output is a characterized impact list linking each harm to a group, a system behavior and a likelihood and severity judgment made in plain terms. The step is complete when the list has been challenged by someone who did not write it, and it is clear which harms the organization has chosen to accept.
Record the assessment in a controlled document
The team writes the results into a version-controlled impact assessment record that ties together the system description, affected parties, characterized impacts and the rationale behind each judgment. Clause 6.1.4 and control A.5.3 expect the assessment to be documented so that another reviewer can follow the reasoning. The output is a signed or approved document with an owner, a version number and the date of the assessment. The step is complete when the record can be retrieved by the system name and an auditor can trace a sample impact to its evidence.
Decide and document impact measures
For each impact that the organization does not accept, the owner selects a measure such as a design change, a restriction on use, a human review step, user notice, a monitoring signal or a decision not to deploy. The decision, the person who made it and the reason are recorded alongside the measure. The output is a measures register with an accepted residual impact statement for anything left unmitigated. The step is complete when each measure has an assigned owner, a link to the system change or procedure that implements it, and an approved statement of residual impact.
Deploy with the assessment as a release condition
Before the system goes live or a material change ships, the release process checks that the impact assessment is current, that its measures are implemented and that open items are either closed or formally accepted. The output is a release record that references the assessment version. The step is complete when the release gate can block a deployment that depends on an outdated or incomplete assessment, and the organization can show which version applied to each release.
Review the assessment through operation and post-market monitoring
During operation, the team monitors the signals that were chosen in the measures register, such as complaints, error patterns, drift in outcomes across groups, misuse reports and incidents. Triggers for reassessment, such as a new use case, new data source, new affected group or a serious incident, send the record back to the earlier steps. ISO/IEC 42005 recommends this review continue through post-market monitoring. The output is a dated review log and, when triggered, a new assessment version. The step is complete when the review schedule is documented, each trigger has an owner, and the log shows that reviews happened.
How the EU AI Act fundamental rights impact assessment differs
Article 27 of the EU AI Act is a legal duty, not a management system choice. It applies to certain deployers of high-risk AI systems: bodies governed by public law, private entities providing public services, and deployers of systems listed in Annex III points 5(b) and (c). If your organization falls into one of these groups, the assessment is mandatory before first use of the system. Other deployers and most providers are not caught by this specific duty, although other AI Act obligations may still apply to them.
- Bodies governed by public law: public authorities and bodies funded or controlled by the state that deploy covered systems.
- Private entities providing public services: private organizations delivering public services that deploy covered systems.
- Annex III points 5(b) and (c): the deployer categories that the Article 27 duty names, which you should confirm against the Annex text for your specific use case.
- Timing: the assessment must be completed before the system is first used.
- Scope check: confirm with counsel whether your deployment falls inside the Article 27 categories before relying on this duty.
Ask your legal team to document the scope decision in writing, because the answer determines whether the assessment is a legal obligation or a voluntary control.
Article 27 sets six elements, labelled (a) to (f), that the deployer's fundamental rights assessment must cover. They describe the use of the system in operational terms, so the assessment has to reflect how the system is actually run, not only how the vendor describes it. The elements are summarized here in plain language, and the legal text should be read directly for exact wording.
- (a) Deployer processes: how the system fits into the deployer's business processes, including the purpose of use.
- (b) Period and frequency: how long and how often the system is used.
- (c) Affected groups: the categories of natural persons and groups likely to be affected in the context of use.
- (d) Specific risks of harm: the risks of harm to those groups that are likely to affect them.
- (e) Human oversight: the human oversight measures applied, in line with the instructions for use.
- (f) Measures if risks materialize: the governance steps and measures to take if those risks occur.
Check that each element has a named owner and a dated record, because an assessor will look for evidence for all six, not only for the parts the team finds easiest.
Under Article 27, the deployer must notify the market surveillance authority of the results of the assessment. The notification is part of the legal duty, so it needs an internal owner and a documented process. Where a GDPR data protection impact assessment already covers some of the same ground, the fundamental rights assessment does not replace it. It complements the DPIA, filling in the rights and obligations the DPIA does not address.
- Notification: report the results to the market surveillance authority as the Article requires.
- Overlap with GDPR: reuse DPIA analysis where it already covers affected individuals and risks, and avoid repeating it without reason.
- Gaps to fill: rights and harms beyond personal data processing still need explicit assessment under Article 27.
- Ownership: assign one owner who keeps the DPIA and the fundamental rights assessment consistent with each other.
- Records: keep both documents linked so an authority can trace how the findings relate.
Confirm with your data protection officer and counsel how the two assessments will be cross-referenced before the first deployment.
Organizations that run ISO/IEC 42001 without the Article 27 duty can design their AI system impact assessment to cover similar ground. The ISO impact controls ask for assessment of impacts on individuals, groups and society, with documentation of the process. Under ISO/IEC 42001, that assessment is a management system requirement you choose to meet, and it is separate from AI risk assessment. However, an ISO assessment does not replace the legal Article 27 assessment where the duty applies, and it does not give the notification that the law requires.
- Overlapping coverage: an ISO impact assessment can address affected groups, harms and human oversight in a similar way.
- No legal substitute: a certificate or an internal ISO record does not discharge the Article 27 duty.
- Missing notification: the ISO process does not, by itself, include notifying a market surveillance authority.
- Documentation: keep records that show the assessment was done and reviewed, which an auditor will test.
- Scope note: the ISO assessment is voluntary unless a contract or customer requires it.
Ask your auditor and counsel whether an ISO assessment meets your specific obligations, and do not assume that certification covers the legal requirement.
As amended by the Digital Omnibus on AI, the high-risk obligations of the EU AI Act apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I systems, under Article 113. These dates set when the high-risk regime, including the deployer duties that surround the Article 27 assessment, becomes applicable. Planning should start before these dates, because an assessment has to be complete before first use of an affected system.
- Annex III systems: high-risk obligations apply from 2 December 2027.
- Annex I systems: high-risk obligations apply from 2 August 2028.
- Before first use: for covered deployers, the Article 27 assessment must be finished before the system is first used.
- Date source: the dates come from the Article 113 text as amended, so check the current consolidated version before you plan.
- Internal planning: map each system to its annex and set a dated assessment plan from that mapping.
Confirm the applicable dates for each system with your legal team, because the category a system falls into determines which date governs it.
Mapping ISO/IEC 42005 to NIST AI RMF without overstating the match
An assessment that feeds both ISO/IEC 42005 and the NIST AI RMF can reuse much of its evidence, but the overlap is narrower than the framework names suggest. The INCITS/AI crosswalk of ISO/IEC DIS 42005 to the NIST AI RMF, posted on the NIST AI Resource Center on 14 August 2025, maps MAP 5 (impacts characterized) to 42005 subclauses on benefits, harms, failures and foreseeable misuse. It shows no 42005 counterpart for MANAGE 1 to 4. In practice, the impact assessment record can support the characterization of impacts under MAP 5, but it does not by itself cover how risks are prioritized, treated and monitored after deployment.
Before relying on any subclause reference in that crosswalk, check it against the published text of ISO/IEC 42005:2025. The crosswalk was made against the draft (DIS), so numbering, wording and scope may have changed in the final standard. Confirm each mapped subclause against the published edition, record the edition you used, and note the date you checked it. Do not carry a draft-era reference into an audit file, a customer questionnaire or a regulator submission without that check.
For a single assessment that feeds both frameworks, a practical approach is to keep the impact record separate from the risk register. Document the impact assessment under A.5.2 and A.5.3 of ISO/IEC 42001 and the subclause evidence you verified, then map the findings to MAP 5 only where the content matches. Treat MANAGE 1 to 4 as work the risk register and monitoring plan must carry, with named owners and review dates. Ask the certification body or assessor how they expect the two sets of records to be cross-referenced before the file is built.
What must exist before an impact assessment is audit-ready
An impact assessment under ISO/IEC 42001 is only as credible as the records behind it. The items below are the prerequisites an assessor will look for before reading the assessment itself, and each one can be checked in an internal review before the external audit begins.
Defined AI system inventory
Every AI system in scope needs a record that names it, states its intended purpose, identifies who provides and who uses it, and lists the populations it touches. Without a fixed purpose, the assessment has no boundary, and foreseeable misuse cannot be judged. To check this in an internal review, pick two systems at random and confirm the inventory entry matches what is actually deployed, including any vendor-supplied features that were switched on later.
Documented assessment procedure
The organization needs a written procedure that says when an impact assessment is triggered, who runs it, which inputs it uses and how results feed into decisions. Clause 6.1.4 and clause 8.4 both expect the process to be repeatable, so a one-off template is not enough. In an internal review, ask whether the procedure covers a new system, a material change and a reassessment, and whether staff who ran the last assessment can follow it.
Named owners and approvers
Each assessment needs an accountable owner who prepares it and an approver with authority to accept residual impact or stop a deployment. Assessors look for names, roles and dates rather than team labels. During an internal review, check that the approver is independent of the team that built the system and that the approval record is signed or otherwise traceable.
Affected-group analysis
Before the assessment can address impacts on individuals, groups and society, the organization must identify which groups the system affects, including people who never use it directly. The analysis should record how each group is affected and the basis for that finding. In an internal review, test whether the list includes indirect groups such as applicants, bystanders or communities, and whether any vulnerable groups were considered and either addressed or justified.
Records location with version control
Assessments must live in a controlled repository with clear ownership, change history and retention rules. Where a record is edited without a trail, an assessor cannot confirm which version was in force when a decision was made. In an internal review, confirm that each assessment has a version number, that superseded versions remain retrievable, and that access is limited to people who need it.
Link to statement of applicability and risk register
The impact assessment must connect to the statement of applicability, which records which Annex A controls are included or excluded under clause 6.1.3, and to the AI risk register. Impacts identified in the assessment should appear as risks or be explicitly justified as out of scope. In an internal review, trace one identified impact forward to a risk entry and a control decision, and back to the system inventory, then confirm the chain has no gaps.
Who owns the assessment, who helps and who certifies
The organization that develops, provides or uses the AI system owns the impact assessment in full. Under ISO/IEC 42001 the assessment sits inside the organization's AI management system, so the organization must decide which systems are in scope, who is affected, which impacts matter and what to do about them. No outside party can make those decisions on its behalf, and no outside party can accept the residual risk.
- Scope and triggers: The organization decides which AI systems and foreseeable applications are assessed, and when a reassessment is needed after a change in purpose, data or deployment context.
- Affected-group judgments: Staff with business, legal, HR or domain knowledge identify the individuals and groups who could be affected and judge the severity and likelihood of harm.
- Decisions and mitigations: Named accountable owners decide whether to proceed, add human oversight, restrict use or stop the system.
- Sign-off and records: Senior management approves the assessment and the organization keeps the documented results under its own document control.
- Post-deployment monitoring: The organization watches for impacts that appear after launch and feeds them back into the assessment.
Before engaging anyone else, confirm that named individuals in your organization hold each of these roles and have the authority to stop a system.
An implementation partner such as DeployOpen works on the organization's side of the line. It helps build the assessment procedure, templates and supporting systems, then gathers the evidence that shows how the procedure runs. The partner does not decide impacts, does not accept risk and does not sign the assessment as if it were the organization's own decision.
- Procedure and templates: Drafting the impact assessment procedure, record templates and review workflow so they fit the organization's existing AI management system.
- System documentation: Preparing the technical description of each AI system, its data sources and its intended purpose so the assessors have the facts they need.
- Workshops: Running facilitated sessions where the organization's own staff identify affected groups and foreseeable misuse. The partner records the outcomes but the organization makes the call.
- Evidence preparation: Organizing the assessment records, approvals and monitoring logs so they are easy to retrieve at audit.
- Tooling: Configuring self-hosted open-source tools in the organization's own environment to store records and track reviews.
Ask any partner to put in writing which tasks it performs, which it only supports and which it will never perform, such as signing or approving assessments.
An independent auditor or certification body tests the impact assessment against the requirements of ISO/IEC 42001 and issues any report or certificate. ISO does not certify organizations, and certification bodies are independent of the organization and of any consultant that helped prepare the work. The auditor's job is to test what the organization did, not to design it.
- Requirement testing: The auditor checks that the assessment meets the requirements in clauses 6.1.4 and 8.4 and that the applicable Annex A impact controls are implemented or justified in the statement of applicability.
- Sampling evidence: The auditor selects AI systems and reviews the assessment records, the decisions taken and the monitoring evidence behind them.
- Interviews: The auditor speaks with the people who own the assessment to confirm they understand and act on the results.
- Findings and certificate: Only the certification body issues a report or certificate, and it may be accredited or unaccredited depending on how it is recognized.
- Independence: The certification body cannot prepare the assessment it is testing, and a consultant cannot be the body that certifies the same work.
Before hiring a certification body, check its accreditation status and confirm that it has the competence to certify AI management systems under ISO/IEC 42006.
Questions buyers ask about AI impact assessment
Does ISO 42001 require an impact assessment for every AI system?
ISO/IEC 42001:2023 requires your organization to run AI system impact assessments as part of its management system, with the requirement placed in clause 6.1.4 (planning) and clause 8.4 (operation). The standard does not set a single threshold that exempts low-risk systems, so your scope statement and statement of applicability decide which systems are covered and how. Under clause 6.1.3, you must justify including or excluding each Annex A control, so write down the reasoning for every AI system in scope. Confirm the exact scoping logic with your certification body before your stage 1 audit, because interpretation of applicability is a question for the auditor to test, not for the vendor to decide.
How much internal effort does an AI impact assessment take, and what drives it?
The effort depends mainly on how many AI systems are in scope, how many people or groups each system can affect, and how many teams must contribute evidence. Costs fall into two groups: one-time work to design the assessment process and templates, and recurring work to repeat assessments when a system changes, its use expands, or monitoring finds new impacts. Systems that touch hiring, credit, healthcare or public services usually take longer because the affected groups and harms need more analysis. ISO/IEC 42005:2025 recommends assessments throughout the life cycle, so plan for re-assessment rather than a single exercise. No public effort figure is supplied for this work, so ask any partner for a written estimate that lists systems, stakeholders, workshops and review cycles.
Will an auditor accept an impact assessment written by a consultant?
An auditor tests whether your organization performed and owns the assessment, not who typed it. Your organization must approve the assessment, record decisions, and show that the people accountable for the AI system reviewed the results. A consultant can help design the process, draft templates and facilitate workshops, but the content must reflect your systems, your data and your stakeholders. Independence matters here: the certification body must remain independent of any firm that prepared your management system. Ask the certification body directly how it reviews consultant-prepared documentation before you rely on that approach.
How does the ISO 42001 impact assessment relate to the EU AI Act fundamental rights impact assessment?
They overlap in subject matter but are different obligations. The ISO/IEC 42001 impact assessment is a voluntary management system requirement that addresses individuals, groups and society through controls A.5.2 to A.5.5. Article 27 of the EU AI Act requires certain deployers of high-risk AI systems, including bodies governed by public law, private entities providing public services, and deployers of certain Annex III systems, to assess impact on fundamental rights before first use. Article 27 has six required elements, and the deployer must notify the market surveillance authority of the results. Where a GDPR data protection impact assessment already covers some of these obligations, the fundamental rights assessment complements it. An ISO assessment can supply much of the underlying analysis, but it does not replace the Article 27 content or notification. Confirm your obligations with counsel against the dates in Article 113, as amended by the Digital Omnibus on AI: 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems.
Is ISO/IEC 42005 required to pass an ISO 42001 audit?
No. ISO/IEC 42005:2025 is guidance, published on 28 May 2025, that complements ISO/IEC 42001 by focusing on how AI systems may affect individuals, groups and society. ISO/IEC 42001 is the certifiable requirements standard, and an auditor tests your process against its clauses and Annex A controls. Using 42005 as a reference can make the method easier to defend and explain, and it is a common reference point for impact work. Check with your certification body whether it expects a particular method, and record in your statement of applicability how you apply the guidance. ISO/IEC 42005 is also useful for mapping impact work to the NIST AI RMF, since the INCITS/AI crosswalk links MAP 5 to 42005 subclauses.
What should we ask a partner before scoping an AI impact assessment?
Ask what the partner will prepare, what your organization must own, and what the certification body will examine. Useful questions include: which AI systems and stakeholder groups the scope covers, which Annex A controls the statement of applicability will include, how the assessment method maps to clauses 6.1.4 and 8.4, and who signs off each assessment. Ask for deliverables in writing, a list of workshops and reviewers, and a plan for re-assessment when a system changes. DeployOpen plans and implements systems and prepares evidence under a fixed scope agreed in writing before work starts, but it does not issue audit reports or certificates, and the certification body makes that decision. Ask for a quote that follows directly from the written scope.
How DeployOpen prepares impact assessment evidence
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For ISO 42001 impact assessment, we prepare the systems, records and evidence that the organization's own assessment process produces, while the organization owns its controls and an independent certification body decides certification.
How we scope
- Agree in writing which AI systems, life cycle stages and affected groups the impact assessment covers before work starts.
- Map the A.5.2 to A.5.5 controls to the systems in scope and record which the statement of applicability includes.
- Confirm with the organization who approves impact assessment decisions and who signs off on documented results.
How we build
- Configure self-hosted tooling so assessment templates, approvals and version history are kept in the client's environment.
- Prepare documented assessment records covering intended use, foreseeable misuse, affected groups and harm scenarios.
- Test that review triggers, such as a model change or a new deployment context, route to a re-assessment with a traceable record.
How we hand over
- Deliver the assessment procedure, templates, completed records and an evidence index mapped to the in-scope Annex A controls.
- Walk the internal owners through how to run, update and retire assessments without outside help.
- Document open items, residual impacts and decisions that the organization must still accept or escalate.
How we support
- Offer ongoing support and upgrades as a retainer when the AI systems, models or affected groups change over time.
- Run periodic reviews of assessment records ahead of internal audit or the certification body's visits.
- Clarify with the client which questions belong to the certification body, which belong to counsel and which belong to the organization.
