ISO/IEC 42001 asks you to assess what your AI systems do to people and society, not just the risks they pose to your business. That's a different exercise, and I see businesses skip it or fold it into a standard risk assessment. It needs its own process, its own evidence, and its own place in your management system.
What the standard actually asks for
Clause 6.1.4 requires you to assess the potential consequences of your AI systems for individuals and groups — fairness, safety, and wider effects on society — before you deploy them. Clause 8.4 asks you to actually carry that assessment out, and to repeat it when something material changes about the system, its data, or how it's used. These sit alongside, not instead of, the AI risk assessment required under clauses 6.1.2 and 8.2, and the risk treatment plan under 6.1.3 and 8.3. Treat them as separate exercises that happen to run in parallel.
Risk assessment and impact assessment are not the same thing
I've seen organisations try to tick off impact assessment by adding a "societal impact" column to their normal risk register. It doesn't hold up. Risk assessment asks what could go wrong for your organisation — reputational damage, failed outputs, compliance exposure. Impact assessment asks a different question: who is affected by this system, and how, regardless of whether anything has "gone wrong" by your own definition. An AI system that performs exactly as designed can still produce an outcome that's unfair, exclusionary, or harmful to someone outside your organisation. Auditors are increasingly alert to the difference, and a merged document is an easy finding.
What a usable assessment actually contains
A usable impact assessment names the groups the system affects — customers, employees, job applicants, members of the public — and sets out, system by system, what could happen to them: unfair treatment, loss of access to a service, a safety issue, a privacy intrusion. It records what you did about anything significant, who reviewed it, and when. It's dated and tied to a specific version of the system, because the assessment for version one doesn't automatically cover version two. A generic paragraph in a policy stating that you "consider the impact of AI on society" will not satisfy an assessor, and it won't help you if something does go wrong.
When to redo it
Clause 8.4 is explicit that this isn't a one-off exercise done once before certification and filed away. A material change — new training data, a new use case, a new population the system now serves, a vendor update to a third-party model you rely on — should trigger a fresh assessment, not an assumption that the original one still holds. I've seen businesses treat the impact assessment purely as a certification exercise. That's the gap assessors are now trained to look for, and it's one of the easiest nonconformities to pick up if your change control process doesn't feed back into it.
Where this sits in your management system
This assessment isn't a side document that exists to satisfy an auditor once a year. It needs to connect to your risk treatment plan, to the Annex A controls you've selected to manage AI-related risk, and to whoever holds the role of AIMS owner under clause 5.3. If your impact assessment identifies something significant and nothing changes in your controls or your statement of applicable controls as a result, you have a gap between what you found and what you did about it. That gap, more than the assessment's existence or absence, is where audits actually fail.
If you're working towards ISO 42001 certification, don't leave the impact assessment until the audit is booked. Build it into how you approve a new AI system, or a significant change to an existing one, so it produces something an assessor — and more importantly, the people actually affected by the system — can read and trust.
Ready to talk about your business?
Book a free, no-obligation call. We will tell you exactly what certification would involve for your size, sector, and starting point.