An AI system impact assessment is the documented process ISO/IEC 42001 clause 6.1.4 requires for identifying, evaluating and addressing an AI system’s consequences for individuals, groups and societies. Any organization certifying an AI management system (AIMS) must define that process. It covers intended use and foreseeable misuse, and its results flow into the AI risk assessment. Clause 8.4 then requires the assessment to run again at planned intervals or when significant changes are proposed.
The term travels under several names. Practitioners write AIIA, AI-SIA or simply AI impact assessment, and researchers use algorithmic impact assessment for the wider family. A data protection impact assessment can feed it, and its results feed the clause 6.1.2 risk assessment, but it replaces neither. ISO/IEC 42005:2025 explains how to run one, though nobody certifies against 42005. What clause 6.1.4 asks for comes first, followed by the record, the triggers, the sign-off, the audit evidence and an academic critique of the exercise.
What clause 6.1.4 requires
Clause 6.1.4 of ISO/IEC 42001:2023 requires a defined process for assessing what AI systems could do to individuals, groups and societies. The process has four parts that an auditor can test:
- Consequences arising from the system’s deployment, its intended use and its foreseeable misuse.
- The specific technical and societal context of deployment, including the jurisdictions where the system is used.
- Documented results, which you may choose to share with relevant interested parties.
- Use of those results in the AI risk assessment under clause 6.1.2.
These points paraphrase the clause as secondary sources reproduce it. Check the exact clause text in a purchased copy before you quote it in a procedure.
The definition behind the clause
Clause 3.24 defines the assessment as a formal, documented process. Its job is to find, weigh and deal with impacts on people, groups and societies. Three words in that definition carry the audit weight. Formal means the work follows a defined method. Documented means a retained record. Addressed means the assessment ends in decisions and actions as well as findings.
Clause 8.4 runs it in operation
Clause 8.4 turns the planned process into recurring work: the organization performs impact assessments according to 6.1.4 at planned intervals, and again when significant changes are proposed. Clause 6.1.4 is the design, and clause 8.4 is the proof that the design runs. A well-written procedure with no completed records satisfies the first and fails the second. Our overview of clause 6 places the impact assessment next to risk criteria, treatment planning and the Statement of Applicability.
Risk assessment vs impact assessment under 42001
The clause 6.1.2 risk assessment and the clause 6.1.4 impact assessment are separate requirements. The popular explanation of the difference is wrong. Google’s AI Overview for “iso 42001 ai system impact assessment”, captured on 4 October 2026, puts it simply. The risk assessment looks inward at the company, and the impact assessment looks outward at people. Several ranking pages repeat the line.
Under ISO/IEC 42001 that split does not hold. Clause 6.1.2 asks you to weigh what could happen to the organization, to individuals and to societies. Harm to people already sits inside the risk assessment. The impact assessment is a second, system-level look whose results feed that risk assessment.
Where the two differ in practice
The two differ in their unit of analysis, their method and the record each one produces, as the table shows.
| Attribute | AI risk assessment (6.1.2) | AI system impact assessment (6.1.4) |
| Consequences in view | Organization, individuals and societies | Individuals, groups of individuals and societies |
| Unit of analysis (in practice) | Risks across the AIMS scope | One AI system, or one version, in one deployment context |
| Method | Analysis against the organization’s AI risk criteria | Identification and evaluation of benefits and harms, including foreseeable misuse; ISO/IEC 42005 offers guidance |
| Output | Risk register entries, then treatment and the Statement of Applicability under 6.1.3 | An approved impact assessment record, retained as documented information |
| Direction of the link | Takes impact results into account | Sends its results into the risk assessment |
| Repeated under | Clause 8.2 | Clause 8.4 |
| Annex A controls | Chosen through 6.1.3 | A.5.2 to A.5.5 |
A practical test follows from the table. If a harm to people appears in the impact record but not in the risk register, the feed into 6.1.2 is broken. If it appears only in the risk register, the system-level analysis that A.5 expects is missing. The scoring method itself belongs to the risk side, and our guide to conducting the risk assessment covers it step by step.
Annex A.5 controls and ISO/IEC 42005
Annex A.5 holds the four controls that put the impact assessment into practice. ISO/IEC 42005:2025 is a separate guidance standard on how to run one. Its place among the other SC 42 documents is mapped in the ISO/IEC 42000 standards family.
The four A.5 controls
| Control | Topic in brief | What you show an auditor |
| A.5.2 | The assessment process | A defined process: when it runs, who runs it, which method and thresholds it uses |
| A.5.3 | Records of each assessment | Completed records, retained for a period you define |
| A.5.4 | Effects on individuals and groups | Analysis of effects on people and on groups that may need particular care |
| A.5.5 | Effects on society | Analysis of wider effects beyond the people who use or are scored by the system |
The topic labels are GAICC shorthand. Official titles appear in public enumerations of Annex A, namely ISO’s FDIS contents list and the 2026 AWS implementation guide, and in your purchased copy. Normative Annex B gives matching guidance in B.5.2 to B.5.5. Per Annex A of ISO/IEC 42001:2023, there are 38 controls in nine areas under ten control objectives. Our page on selecting Annex A controls shows where A.5 sits among them.
What ISO/IEC 42005:2025 adds
ISO/IEC 42005:2025, published on 28 May 2025, gives guidance to organizations performing AI system impact assessments, and its clause 5 describes the process in 12 sub-clauses. They include timing, scope, allocating responsibilities, thresholds for sensitive and restricted uses, approval, and monitoring and review. Its clause 6 lists what to document. That covers system information, data and model information, the deployment environment, interested parties, benefits and harms, failures and misuse, and the measures taken. Five informative annexes follow, among them guidance for use with ISO/IEC 42001, a harms and benefits taxonomy and an example template.
Three facts keep 42005 in its place. ISO/IEC 42001 does not cite it anywhere, since 42001 was published 17 months earlier. As a guidance document, 42005 contains nothing for a certification body to certify against. Using it is optional. Any method that covers clause 6.1.4 will do. Our post on the ISO/IEC 42005 impact assessment standard covers the guidance itself. Teams mapping to the NIST AI RMF as well can draw on the INCITS crosswalk between 42005 and the AI RMF. Dated 14 August 2025, it maps the draft text. With the requirement and its guidance in view, the practical work starts with the record.
The assessment record, field by field
An impact assessment record is the documented output of one assessment of one system. The fields below combine the clause 6.1.4 elements, the documentation items in Annex B.5.3 and the structure of ISO/IEC 42005 clause 6. The field names are GAICC’s editorial structure, and the standard words each item in its own way.
| # | Field | What to capture | Grounded in |
| 1 | Identification | System name, version, owner, inventory reference, AIMS scope reference | 4.3 scope; inventory practice |
| 2 | Trigger and date | Why the assessment runs now: new system, planned interval or change | 8.4; B.5.2 |
| 3 | Intended use and context | Purpose, users, decisions the output influences, technical and social setting | 6.1.4; B.5.3; 42005 6.3 and 6.6 |
| 4 | Foreseeable misuse | Plausible uses outside the intent, by users or by others | 6.1.4; B.5.3; 42005 6.8.3 |
| 5 | Data and model | Data sources and quality, model type, provider if bought | 42005 6.4 and 6.5 |
| 6 | Affected people and groups | Who is affected, the demographic groups the system applies to, groups needing particular care | B.5.3; B.5.4; 42005 6.7 |
| 7 | Benefits and harms | Positive and negative effects on individuals, groups and society | B.5.3 to B.5.5; 42005 6.8.2 |
| 8 | Predictable failures | Likely failure modes, what each would do to people, how each is mitigated | B.5.3; 42005 6.8.3 |
| 9 | Complexity and automation | How complex the system is and how much it acts without a person | B.5.2; B.5.3 |
| 10 | Human role | Who oversees outputs, and who can intervene or override | B.5.3 |
| 11 | Workforce effects | Effects on employment and on the skills staff need | B.5.3 |
| 12 | Jurisdictions | Laws and regulators in each place the system is used | 6.1.4 |
| 13 | Impact rating | Severity and scale against your documented thresholds | 42005 5.7 |
| 14 | Measures | Actions that reduce harms or preserve benefits, each with an owner and due date | 3.24; 42005 6.9 |
| 15 | Risk feed | Risk register entries created or updated from this record | 6.1.4 into 6.1.2 |
| 16 | Decision and approval | Go, go with conditions, or stop; approver name and date | 42005 5.11; 6.1.3 |
| 17 | Disclosure | What is shared, with whom, and in what form | 6.1.4 |
| 18 | Retention and next review | Retention period, next planned date, conditions that reopen it | A.5.3; 8.4 |
B.5.3 lists seven items to consider documenting, and rows 3, 4, 6, 7, 8, 9, 10 and 11 carry them. B.5.4 adds groups that may need particular attention, such as children, elderly people, people with impairments and workers. Retention is left to you. Your rules for documented information must set the period. Version every record against the system version. An assessment of version 2 is not evidence for version 3. Keep the old record too. The record then joins the documentation set that the AIMS controls under clause 7.5.
When to run it and when to reopen it
An impact assessment runs for each in-scope AI system, at the planned intervals the organization sets, and when significant changes are proposed. ISO/IEC 42005 treats timing as a design decision of the process. Run the first assessment before deployment, because deployment consequences are exactly what clause 6.1.4 asks about.
A screening rule built from B.5.2
Annex B.5.2 links the need for an assessment to three factors. They are the criticality of purpose and context, the complexity and level of automation, and the sensitivity of the data. A short intake screen turns those factors into questions anyone can answer. The screen below is a GAICC editorial example, and its questions are ours.
| Factor | Screening question | Assess in depth when |
| Criticality | Does the output affect access to a job, credit, housing, insurance, health care, education, public benefits or anyone’s safety? | Yes |
| Automation | Does a person review each output before it takes effect? | No |
| Complexity | Can the team explain how an output was produced? | No, or only partly |
| Data sensitivity | Does it process personal data, data about protected classes or children’s data? | Yes |
A system that answers every question the low-impact way still gets a short record. The record shows the screen was applied.
Triggers that reopen an assessment
Any significant change reopens the record. Write the triggers into the procedure so an auditor can test them against your change log:
- The intended use, user group or deployment context changes, including a move into a new jurisdiction.
- The model, its training data or its provider changes. For bought systems, a provider’s release note or material-update notice is the signal.
- Monitoring shows drift, a new failure mode or a pattern of complaints.
- An incident or near miss involves the system.
- A new law or regulator guidance applies where the system runs.
- The planned interval expires.
ISO/IEC 42001 sets no interval. Set one per impact tier, and record the reasoning. Triggers only work when every system is known, which is why intake normally starts from the AI system inventory.
Who does it and who signs off
Clause 6.1.4 assigns the assessment to the organization and names no role. Top management assigns it as part of the role allocation under clause 5.3. The note to clause 4.1 lists AI impact assessors among the AI producer roles drawn from ISO/IEC 22989. The split below is a GAICC editorial example for a mid-size AIMS scope. Small teams combine roles.
| Role | Typical holder | Responsibility |
| Assessment lead | Responsible AI, risk or compliance specialist | Runs the process and writes the record |
| AI system owner | Business owner of the use case | Supplies context, owns the measures |
| Technical contributors | Data science and engineering | Data, model, testing and failure modes |
| Domain and affected-party input | Front-line staff, legal, customer or employee representatives | A view of harm close to the people affected |
| Independent reviewer | Someone outside the build team | Challenges gaps before approval |
| Approver | Designated management or an AI governance committee | Decides go, conditions or stop; accepts residual risk |
| Internal auditor | Internal audit function | Tests that the process works, under clause 9.2 |
Clause 6.1.3 already requires designated management to approve the AI risk treatment plan and accept residual AI risk. Giving the same person or committee the impact decision means one owner answers for both. OMB memorandum M-25-21 offers a tested pattern for the review step, because it requires an independent reviewer inside the agency who was not involved in development. It also requires the reviewer’s comments to go into the assessment and a signature from the person accepting the risk. ISO/IEC 42001 does not demand that design, but it maps cleanly onto it. The full matrix, including who owns risk acceptance, sits in our guide to who does what in an AIMS. New assessment leads can practice the work in the risk and impact assessment module of the Lead Implementer course, which covers clauses 6.1.1 to 6.1.4.
[TRAINER INSIGHT NEEDED: In the implementations GAICC instructors have seen, who most often signs off an AI system impact assessment, and what goes wrong when the system owner approves their own assessment?]
Worked example with an LLM support assistant
Everything in this example is illustrative. The company is a fictional US electric and gas utility with no link to any GAICC client. The record shows how the fields fill in for a bought large language model (LLM).
The utility plans a customer support assistant for its website and app. The assistant runs on a third-party LLM through an API and retrieves answers from the utility’s own tariff and policy documents. It answers billing and outage questions, explains published payment-plan options and hands complex cases to staff. It does not approve payment plans or make disconnection decisions. Staff make those calls.
| Field | Illustrative entry |
| Trigger | New system, assessed before deployment |
| Intended use | Answer billing and outage questions; explain published payment options; hand off to staff |
| Foreseeable misuse | Customers treat an answer as a binding decision on disconnection; prompt injection aimed at other customers’ data; staff paste answers into formal notices |
| Affected people and groups | Residential customers, including elderly customers, customers with limited English and customers with disabilities; contact-center staff |
| Benefits | Answers outside business hours; shorter queues for complex cases |
| Harms | A wrong statement about shut-off protections leads a customer to miss a deadline; weaker answers in Spanish than in English; exposure of another customer’s data |
| Predictable failures | Invented policy details; stale tariff text after a rate change; behavior shifts after a provider model update |
| Human role | Every payment-plan or disconnection question goes to a person; staff can review and correct transcripts |
| Workforce effects | Agents move to complex cases and need training to review AI transcripts |
| Jurisdictions | State utility commission notice rules and state privacy law, confirmed by counsel; if the assistant ever ranks or recommends payment-plan eligibility, re-screen against state automated decision laws such as Colorado SB 26-189 |
| Measures | Retrieval limited to approved documents; refusal for account-specific decisions; Spanish test set before launch; content refresh tied to every tariff change; recurring transcript sampling |
| Risk feed | Three new risk register entries: misinformation on protections, data exposure, language disparity |
| Decision | Go with conditions, approved by the customer operations executive and the AI governance committee |
| Next review | Six months, or any provider model change, whichever comes first |
Two details in the example matter beyond utilities. First, much of the record rests on the provider’s documents, which makes the supplier controls in A.10 an input. Our guide to assessing AI vendors covers that side. Second, the most serious harm is written at the level of the customer who misses a deadline. A business risk register might log the same event as a regulatory complaint. Writing it as the person lives it keeps the record close to the harm.
US laws an impact assessment should take into account
Clause 6.1.4 asks the assessment to account for every jurisdiction where a system is used. Three US instruments shape what a US record should cover. None of them names ISO/IEC 42001. A 42001 certificate does not satisfy any of them on its own.
| Instrument | Who it binds | What it requires | What a 6.1.4 record can supply |
| OMB M-25-21 (3 April 2025) | Federal agencies using high-impact AI | An AI impact assessment before deploying any high-impact use case, covering purpose and expected benefit, data quality, effects on privacy, civil rights and civil liberties, reassessment schedules, costs, independent review and signed risk acceptance | Vendor-side facts on data, model, testing and failure modes that the agency needs for its own assessment |
| Colorado SB 26-189 (signed 14 May 2026, effective 1 January 2027) | Developers and deployers of automated decision-making technology that materially influences consequential decisions in covered domains | No impact assessment duty. Developers give deployers documentation on intended and known harmful uses, training data categories, limitations and human review, plus notices of material updates. Deployers give notice before use and an explanation within 30 days of an adverse outcome. On request, they also offer data correction and meaningful human review. Both keep records for three years | Intended use, misuse, data, limitations, human-review design and version history |
| NYC Local Law 144 (enforced since 5 July 2023) | Employers and employment agencies using automated employment decision tools | A bias audit within one year before use, a public summary of the results, and notices to candidates or employees | Affected groups, fairness harms and the measures taken; the internal record is not the bias audit itself |
Under M-25-21, AI is high-impact when its output is the main basis for decisions with a legal, material, binding or significant effect on rights or safety. Colorado’s covered domains are education, employment, residential housing, financial or lending services, insurance, health care, and essential government services and public benefits. The screening questions earlier on this page track both lists on purpose.
Google’s AI Overview for “colorado ai act iso 42001” is out of date. The capture from 5 October 2026 still describes annual impact assessments and an ISO/IEC 42001 safe harbor. Both came from SB 24-205, which SB 26-189 repealed and re-enacted. The enacted 2026 text contains no impact assessment duty and names no framework. Our page on whether ISO 42001 counts under US state AI laws covers Texas TRAIGA, Connecticut’s Public Act 26-15 and other states. EU deployments add the AI Act’s fundamental rights impact assessment, which our comparison of how ISO 42001 relates to the EU AI Act covers. Once the records exist, attention turns to what a certification auditor will ask to see.
Evidence an auditor expects
A certification auditor tests the impact assessment twice. Stage 1 looks at the designed process, and Stage 2 looks at records that show the process runs.
| Audit point | What the auditor asks | Evidence that answers it |
| Stage 1 | Is there a defined 6.1.4 process? | Approved procedure with scope, screen, triggers, method, thresholds, roles, approval and retention |
| Stage 1 | Are A.5 controls in the Statement of Applicability? | Entries for A.5.2 to A.5.5 with their justification |
| Stage 2 | Were in-scope systems assessed? | Inventory reconciled to completed records |
| Stage 2 | Did results reach the risk assessment? | Risk register entries that cite the impact record |
| Stage 2 | Were triggers honored? | Change log compared with reassessment dates |
| Stage 2 | Were measures carried out? | Tickets, test results and monitoring data |
| Stage 2 | Who approved, and when? | Signed approvals and version history |
| Surveillance | Does it keep running? | Assessments completed since the last audit; overdue list |
The final draft of ISO/IEC 42006 expects the certification audit team to know the legal obligations that apply to AI. Expect the auditor to read the jurisdiction field closely. Not every auditor looks, though. An ISO/IEC 27001 lead auditor wrote on a public forum in March 2026 that verifying AI impact assessments was not part of a 27001 audit. That is right for 27001, and it is a warning for integrated audits. Confirm with your certification body that the 42001 team samples A.5. Our walkthrough of the Stage 1 and Stage 2 certification audit covers the full cycle.
[TRAINER INSIGHT NEEDED: Which impact assessment findings do GAICC instructors see most often in Stage 2 audits or mock audits, and what evidence closed them?]
Why critics call impacts co-constructed
A 2021 FAccT paper by Metcalf, Moss, Watkins, Singh and Elish questions what impact assessments can achieve. The authors, all affiliated with the Data & Society Research Institute, argue that impacts are constructed by the people who run the assessment. Their warning is that impacts risk being built as metrics that make sense to the organization yet sit “inappropriately distant from the harms experienced by people.”
The authors make three recommendations. Treat impacts as built within accountability relationships, and construct them as close to actual harms as possible. Draw on several kinds of expertise and on affected communities. They add that an assessment produces accountability only when a forum with power to mandate changes reviews it. They also warn about the case where the actor doubles as its own forum.
Read against ISO/IEC 42001, the critique lands on a real design feature. The organization defines the process, runs it, approves it and decides what to disclose, while the certification body audits whether the process conforms and works. A certification auditor does not substitute a separate judgment about which harms matter most. In Metcalf’s terms, a 42001 organization is both actor and forum.
The standard still leaves room to answer the critique:
- Write each harm at the level of the person, such as a missed shut-off deadline. A proxy such as complaint volume sits one step away from the harm.
- Bring in people outside the build team, including front-line staff, domain experts and representatives of affected users.
- Give the approval forum real power to stop or change a deployment, and record each time it uses that power.
- Share a summary with affected people where you can, which clause 6.1.4 permits.
None of these steps is mandatory under ISO/IEC 42001. Each one makes the record harder to dismiss as paperwork.
Where to go next
Choose the line closest to your situation.
- Organizations that only buy AI can build the record from provider documentation and their supplier controls, treating every provider model change as a trigger.
- Teams that already run privacy impact assessments can reuse the data sections, then add group and societal effects, foreseeable misuse and the jurisdiction field.
- Vendors to federal agencies should map the record to the M-25-21 fields. The agency’s own assessment can then draw on it.
- Employers hiring through automated tools in New York City should keep the bias audit and the 6.1.4 record as separate, cross-referenced artifacts.
- With Stage 1 close, check the procedure, the A.5 entries in the Statement of Applicability, and one complete record per in-scope system.
- Exam candidates will find risk and impact assessment in Domain II, the heaviest at 40 percent, of the ISO 42001 Lead Implementer exam.
- Anyone who will run these assessments can get hands-on AI impact assessment training from GAICC. The course lists conducting risk and impact assessments and developing treatment plans among its outcomes.
Frequently asked questions
Is the AI system impact assessment mandatory under ISO 42001?
Yes, for any organization that claims conformity, because clauses 6.1.4 and 8.4 sit in the body of the standard. Unlike an Annex A control, they have no exclusion route through the Statement of Applicability. If the real question is whether your organization needs the standard at all, see the pillar page on whether ISO 42001 applies to your organization.
Does a privacy impact assessment satisfy clause 6.1.4?
Not on its own. A privacy or data protection impact assessment looks at the processing of personal data. Clause 6.1.4 also reaches group and societal effects, harms without personal data and foreseeable misuse, so the privacy assessment becomes one input to the impact record.
Does a bought AI system need its own impact assessment?
Yes. Clause 6.1.4 covers consequences arising from the development, provision or use of AI systems, so a bought system that you use is in scope. Much of the record will rest on provider documentation, so the A.10 supplier controls and the provider’s update notices feed the assessment.
Do we have to publish our impact assessments?
No. Clause 6.1.4 lets the organization decide whether to make results available to relevant interested parties, a group the organization itself defines. Specific laws can still require disclosures, such as the Colorado explanation after an adverse outcome or the public NYC bias audit summary.
Do we need to buy ISO/IEC 42005 to get certified?
Not for certification. ISO/IEC 42005 is optional guidance, ISO/IEC 42001 does not reference it, and any method that meets clause 6.1.4 will do. Buying it can still pay off, since its clause 6 documentation list and its Annex E example template shorten the design work.
What happens to impact assessments after certification?
Clause 8.4 keeps them running at planned intervals and when significant changes are proposed, and every result must be retained as documented information. ISO/IEC 17021-1 puts a surveillance audit in each year of the certification cycle apart from the recertification year. At each one, expect the auditor to ask which assessments were completed since the last visit and which are overdue.
