AI Risk Assessment vs. AI System Impact Assessment

What the AI system impact assessment is, and why ISO 42001 asks for it #

Most management system standards protect the firm that adopts them. ISO 27001 asks you to assess risk to your information. ISO 9001 asks you to assess risk to your product quality. ISO/IEC 42001 does that too, in Clause 8.2. Then it adds something new.

No other ISO management system standard asks for this next part. Clause 6.1.4 and Clause 8.4 ask you to assess what your AI system could do to people who are not your firm. Nank.ai calls this the AI system impact assessment, or the AIIA, since the standard names it but gives it no short form.

Clause 6.1.4 requires a documented process for the AIIA. Clause 8.4 requires you to run that process on every AI system in scope, before you deploy it.

The two questions differ at the root. Clause 8.2 asks what could go wrong for you. The AIIA asks what your system could do to someone else. Take a bank’s fraud model. It can pass every test built to protect the bank. It can still deny a fair loan to a qualified applicant, because the training data carried an old bias. The risk assessment misses this. Nothing went wrong for the bank.

What Clause 6.1.4 makes you build #

Clause 6.1.4 sits in the planning part of ISO 42001’s structure. It does not ask you to assess any single AI system yet. It asks you to write the process you will use on every system that comes after it. You satisfy the clause once, when you approve the process, then keep it current.

Your documented process has to answer eight questions before you use it for real.

• Scope. Which AI systems need a full assessment, and which fall under a threshold that skips it?
• Triggers. What starts an assessment, or a reassessment: first deployment, a significant change, an incident, a scheduled review.
• Method. How you identify, score, and rank an impact, with a defined severity scale.
• Stakeholders. How you find every group your system affects, including people who never touch it.
• Misuse. How you work out what happens when someone uses the system in a way you did not plan for.
• Mitigation. How you decide what to fix, and how you document a harm you accept instead.
• Ownership. Who runs the assessment, who signs off on it, and who owns the fixes.
• Records. What evidence you keep, and for how long.

What Clause 8.4 makes you run #

Clause 8.4 governs your AI system across its life, from design through retirement. Inside that lifecycle, it names the AIIA as a required step at set points. Four of those points are hard requirements. Two are best practice for a mature program.

1. Before first deployment. No AI system in scope goes live without a completed, approved assessment. This is the gate, and it does not bend.
2. After a significant system change. New training data, a new architecture, a new feature. Any of these can change who gets hurt and how.
3. After an incident. A biased outcome, a harmful output, a privacy failure. The incident is proof your last assessment missed something.
4. When the use case expands. A new user population or a new purpose can put people outside your original scope.
5. On a set schedule. Even with no system change, review it on an interval. Rules change, and so does the population your system reaches.
6. After a relevant rule change. New guidance, or a ruling on a comparable system, can surface a harm category you missed the first time.

The risk assessment and the impact assessment, side by side #

Put the two next to each other and the difference stops being abstract.

The two feed each other without merging. A harm the impact assessment finds belongs in your risk register too. A harm to someone else, once it becomes public, is a real risk to your firm. Both draw mitigation options from the same Annex A controls. Both results reach the same management review, under Clause 9.3, as two separate documents.

How to run an AI system impact assessment #

ISO 42001 does not hand you a methodology. It requires a documented, repeatable one. This six-step version covers what Clause 6.1.4 requires and holds up under audit.

1. Profile the system. Name it, version it, and record its model type, its autonomy level, who deploys it, and where. Every later step draws on this record.
2. Map who is affected. Separate your AI users, the people who use the system, from your AI subjects, whose lives it affects without their involvement. Note who among them counts as vulnerable. The same output can mean one thing for a patient and something else for a healthy adult.
3. Assess the six dimensions. For each affected group, score fairness, privacy, autonomy, transparency, safety, and societal effect. Rate the severity, how many people it reaches, and whether the harm reverses.
4. Test the misuse scenarios. Clause 6.1.4 names this step on its own. Write three to five realistic misuse cases, inside your firm and outside it, and score each one.
5. Assign mitigations, and accept what is left. Fix what you can with technical, process, or policy changes. Where harm remains, write down why you accept it and who signed off.
6. Approve, and schedule the next look. Management signs the report before deployment. Set your next review date and name the changes that would force an earlier one.

The six impact dimensions #

• Fairness. Does the system’s error rate stay level across groups, or does one group absorb more false positives or false negatives?
• Privacy. Does the system expose personal data, or let someone infer a sensitive trait it was never given?
• Autonomy. Does the system leave people a real choice, or push them toward one through opacity or a default setting?
• Transparency. Can someone affected by an output understand why the system produced it, and challenge it?
• Safety. Could the system cause physical, psychological, or financial harm, on its own or through misuse?
• Societal effect. What happens at scale: the environmental cost of compute, job displacement, and strain on institutions people rely on.

The AIIA and the EU AI Act’s Fundamental Rights Impact Assessment #

The EU AI Act’s Article 27 asks deployers of high risk AI systems for a Fundamental Rights Impact Assessment, or FRIA, before deployment. The FRIA and the AIIA ask a similar question from different legal grounds. Build one well and it can answer both.

The deadline moved this year. The original date for Annex III high risk systems, including the FRIA duty, was 2 August 2026. A Digital Omnibus agreement pushed it to 2 December 2027. Regulation (EU) 2026/1744 made that binding when it took effect on 27 July 2026. High risk systems built into already regulated products, under Annex I, now have until 2 August 2028. Neither date is close. Build your assessment on your own timeline, and design it to satisfy both frameworks from the start.

The two are not identical. The FRIA ties to the EU Charter’s specific rights, and its results go into the EU’s public AI systems database under Article 71. The AIIA is a certification requirement with a broader rights frame and no public filing. Map one to the other and you write the work once instead of twice.

Frequently asked questions #

Key takeaways #