There is a version of an AI risk assessment that exists to be filed, and a version that exists to be used. They look similar on the page. They are not the same document.
Clause 6.1.2 requires organizations to establish and apply a risk assessment process for AI systems. It’s short. It’s also frequently misread as requiring a single, static assessment exercise rather than a repeatable process.
Three risk vocabularies, one assessment
Before writing anything, it’s worth being explicit about which risk you’re assessing, because “AI risk,” “information security risk,” and “organizational risk” get used interchangeably in a way that produces confused assessments.
-
ISMS risk (if you have one) is about confidentiality, integrity, and availability of information assets
-
AI management system risk, per 42001, is broader — it includes the AI-specific risk categories in Annex A (fairness, transparency, robustness, human oversight, misuse potential) that don’t map cleanly onto CIA triad thinking
-
Organizational/enterprise risk is the business-level view that your risk assessment needs to speak to.
A 42001-conformant risk assessment has to explicitly address the AI-specific risk categories. An assessment that’s really just your existing ISMS risk register with “AI” typed into the asset name column will not survive audit scrutiny, because it will conspicuously fail to address things like training data provenance, model drift, or automated decision-making impact on individuals, categories with no analog in traditional information security risk thinking.
The four-part structure Clause 6.1.2 actually asks for
Strip the clause down to its operative requirements and you get four things you have to be able to demonstrate, per AI system, per assessment cycle:
-
Identify the AI systems and their intended purpose: this is why the Register stage matters; you can’t assess what you haven’t scoped
-
Identify and characterize the risks: what could go wrong, for whom, and through what mechanism (technical failure, misuse, data issue, oversight gap)
-
Evaluate the risks: likelihood and impact, using consistent criteria across systems so risk levels are comparable, not vibes-based
-
Document the process and its outputs in a form that can be reproduced and defended later
The fourth requirement is the one organizations most often shortcut, and it’s the one that costs them at audit time. “We assessed this and decided it was low risk” is not documentation. A reproducible assessment records which criteria were applied, who applied them, what evidence supported the conclusion, and what would change the conclusion if circumstances shifted.
Choosing your assessment direction: top-down or bottom-up
There are two workable starting approaches, and the choice matters less than making it deliberately.
-
Top-down: start with organizational risk appetite and regulatory obligations, then assess how each AI system’s characteristics map to that appetite. Works well when you have a mature enterprise risk function already and want AI risk to plug into existing governance.
-
Bottom-up: start with the individual AI system’s technical characteristics (training data, model architecture, deployment context, user population) and build risk conclusions from those specifics, then aggregate upward. Works well when your AI portfolio is heterogeneous and organization-wide risk appetite statements don’t yet exist or don’t capture AI-specific nuance.
Most organizations end up doing both eventually but starting with one clear direction avoids the common trap of trying to build both simultaneously and producing an assessment that’s coherent at neither level.
Risk factors that actually differentiate AI systems
A workable per-system risk characterization needs to capture, at minimum: the system’s purpose and deployment context (internal tool vs. customer-facing vs. regulatory-impacting decision), the nature of the training or grounding data (proprietary, public, third-party licensed, synthetic), the degree of human oversight in the loop (fully automated decision, human-in-the-loop, human-on-the-loop advisory), the affected population (employees, general public, vulnerable groups), and the consequence of failure (nuisance, financial loss, safety impact, legal/civil rights impact).
Systems that score high on autonomy, high-consequence failure, and low human oversight deserve materially more assessment rigor and materially faster reassessment cycles than an internal drafting assistant with a human reviewing every output. An assessment process that applies the same depth of scrutiny to both is either wasting effort on the low-risk system or under-scrutinizing the high-risk one.
Avoiding risk assessment theater
The tell for an assessment built to satisfy an audit rather than inform decisions: risk levels that don’t actually change anything downstream. If every system in your portfolio gets assessed as “medium risk” and the control implementation looks identical regardless of the assessment outcome, the assessment isn’t doing governance work. A real assessment should be uncomfortable in at least one direction: either it flags something that changes a deployment decision, or it clears something faster than instinct would have, freeing scrutiny for what actually needs it.
Once you have a defensible, differentiated risk picture per system, the next question is what to actually do about it. That’s the subject of the next post, and it’s where most of the implementation effort in an ISO 42001 program actually lives.
Put these ideas to work.
Schedule a 30-minute walkthrough with our team.