ISO 42001 AI impact assessment: how to run it under clause 6.1.4, with ISO/IEC 42005

What is an AI system impact assessment under ISO 42001?

An ISO 42001 AI impact assessment looks outward. Where the AI risk assessment asks what could help or hinder the organisation's AI objectives, the impact assessment asks what a particular system could do to the people it touches and to society more widely: the applicant screened out, or the patient given the wrong priority.

Clause 6.1.4 of ISO/IEC 42001:2023 requires you to define a process for assessing those potential consequences, whether they arise from developing, providing or using the system. For each system, the assessment covers its deployment, its intended use and the misuse you can reasonably foresee. It must take account of the technical and societal setting in which the system runs and the jurisdictions where it is used. The outcome is documented, and the standard requires the results to be considered in the AI risk assessment of clause 6.1.2.

The standard defines it as a formal, documented process in which impacts are identified, evaluated and addressed; an assessment that never decides what to do about an impact falls short.

Where ISO/IEC 42005 fits

ISO/IEC 42005:2025, titled "AI system impact assessment", was published in May 2025 as its first edition. It is a guidance document for organisations that carry out these assessments. It sits beside ISO/IEC 42001 in the same way that ISO/IEC 23894 sits beside the risk clauses: it helps you design and run the method, but nobody is certified to it.

So the certification body tests your process against clause 6.1.4 and the Annex A controls you selected, not against ISO/IEC 42005. The risk side of the pair, including how ISO/IEC 23894 is used, is covered in our AI risk assessment and treatment guide.

The full set of 38 reference controls, including the other Annex A groups that touch this work, is explained in our Annex A guide.

How to run the assessment, step by step

ISO/IEC 42001 leaves the method to you. The sequence below is Sterling's recommended approach; it meets the clause and keeps each assessment to a workshop or two rather than a research project.

1. Describe the system and its setting

Record what the system does, its owner, your role (developer, provider or user), the decisions it informs or makes and the degree of human review. Name the jurisdictions where its outputs are used. The inventory built during scoping is the starting point.

2. Identify who is affected

List the people inside and outside the organisation whose lives the outputs can reach: direct users, the individuals the system decides about, groups that could be treated differently, and society more broadly where scale or public trust is involved.

3. Consider use and foreseeable misuse

Work through the intended use, then predictable misuse: advice treated as a final decision, or the system applied to a population it was never tested on.

4. Evaluate each consequence

For each potential consequence, record its severity, how many people it could reach, whether it can be reversed, and how likely it is. Sterling's recommended practice is to write short descriptions for each level so that two assessors reach the same answer.

5. Decide what addresses it

Agree a measure for each significant consequence: human review, a data change, a restriction on use, clearer information, or not deploying.

6. Feed the risk assessment, then approve

Carry each significant impact into the AI risk register, where it is treated alongside the organisation's own risks, and have the assessment approved and dated.

A worked example: AI screening of job applications

A mid-sized firm uses a third-party tool that ranks applicants for customer-service roles. The firm is a user of the system, and the vendor supplies the model. Five lines from its assessment show the structure; they are illustrative, not a template to copy.

Because the model belongs to a vendor, much of the evidence comes from the vendor's documentation, agreed and checked under the supplier controls of Annex A group A.10.

The record, and when to repeat it

A useful record holds the system description, the affected parties, each consequence with its evaluation, the decided measures, the link to the risk register entries, the approver and the date. The documentation guide sets out how this fits with the rest of the AIMS records.

Clause 8.4 requires reassessment at planned intervals and whenever a significant change is proposed or takes place. Sterling's recommended triggers include a new model version, new training data, a new population or country of use, a change from advisory to automated decisions, a serious complaint or incident, and a vendor's change to a third-party model. Build them into your change process.

Where the same system also falls under privacy or AI regulation, share the inputs rather than running three unconnected exercises. Under GDPR a data protection impact assessment may be required, and the EU AI Act requires certain deployers, including public bodies and private entities providing public services, to assess fundamental-rights impact before first use. An ISO/IEC 42001 assessment can supply evidence to both but does not replace either; our guide on ISO/IEC 42001 and the EU AI Act explains where the certificate stops.

Mistakes that weaken the impact assessment

• One assessment for the whole organisation. Clause 6.1.4 works system by system; a single generic document cannot show the consequences of a specific deployment.
• Only individuals considered. Group and societal impacts are skipped, although Annex A treats them as a separate control.
• No link to the risk register. Impacts are written up but never appear among the risks, so nothing is treated.
• Vendor systems assumed out of reach. Using a third-party model does not remove the duty to assess its consequences in your own setting.
• Written once. The model has been retrained since the assessment was signed. Our internal audit guide shows how to test for this.

AI impact assessment: questions buyers ask