Most organizations approaching ISO/IEC 42001 for the first time treat Clause 6 — the risk assessment and treatment requirements — as a documentation exercise. They produce a risk register, assign likelihood and impact scores, populate a treatment column, and consider the requirement satisfied. That is not what the standard asks for.
What 42001's risk management requirements actually ask for is harder to fake and more useful when done correctly: a structured process that connects identified risks to specific AI system behaviors, to the organization's stated objectives, and to controls that are measurably operating. The gap between "we have a risk register" and "we have a functioning AI risk management process" is where most implementations fall short — and where most gap assessments spend the bulk of their time.
The scope problem most organizations get wrong
ISO/IEC 42001 applies to the organization's AI management system — the defined scope of AI activities the organization has chosen to govern under the standard. Defining that scope sounds straightforward until you start working through it. Which AI systems are in scope? Which departments? Which use of AI by third parties on the organization's behalf?
The risk assessment must address risks within the defined scope. But the scope definition and the risk assessment are mutually dependent: a scope defined too narrowly excludes risks the organization actually carries, and a scope defined without reference to risk exposure leaves the organization arguing about which systems to include long after the rest of the AIMS is built.
In practice, the more useful question to start with is: where in this organization could an AI system cause harm to an individual, fail to perform as intended, or create material compliance exposure? The answer to that question draws a more honest scope boundary than a policy document alone.
What Clause 6.1 actually requires
Clause 6.1 requires the organization to determine risks and opportunities relevant to the AIMS and to its ability to achieve its intended outcomes. The key phrase is "intended outcomes" — the standard is not asking for a generic risk inventory. It is asking the organization to articulate what it is trying to accomplish with its AI systems and then identify what could prevent that.
For a high-risk AI system under the EU AI Act, that might mean identifying risks to the accuracy and reliability of the system's outputs, risks to the rights of individuals affected by those outputs, and risks to the organization's ability to demonstrate conformity during an audit. Those are different risk categories, and the treatment actions for each look different.
Treatment plans that actually link to controls
Clause 6.1.3 requires the organization to determine appropriate risk treatment actions. Annex A of ISO/IEC 42001 provides a reference control set — 38 controls organized across seven domains — but Annex A is informative, not normative. The organization is not required to implement every control; it is required to justify its control selections relative to its risk treatment decisions.
That justification lives in the Statement of Applicability. A well-constructed SoA maps each identified risk to the treatment decision (accept, avoid, transfer, reduce), the control or controls selected to implement that decision, and the rationale for excluding controls the organization chose not to apply. In a gap assessment, we find roughly half of organizations have either no SoA or one that lists controls without connecting them to the risk register. The two documents exist independently rather than as parts of a single argument.
Monitoring and measurement — the requirement most implementations skip
Clause 9.1 requires the organization to monitor, measure, analyze and evaluate the AI management system. For risk management specifically, this means the organization needs a way to know whether its treatment actions are actually reducing risk — not just whether the actions have been taken.
A training data review policy can be "implemented" in the sense that a policy document exists. It is not "effective" until someone has reviewed training data according to that policy and the review produced a findable record. The difference between implementation and effectiveness is the difference between a paper AIMS and one that actually does what it claims.
The monitoring requirement is where AI risk management intersects with measurement in a way that most policy-driven implementations cannot satisfy. You need quantitative baselines, defined thresholds, and a schedule for review. Whether those baselines come from model performance metrics, audit findings, incident data, or bias testing outputs depends on the specific risk — but some form of measurement has to exist.
Where this leaves most organizations
The organizations that approach 42001 as a documentation exercise find their gap assessments revealing a large number of gaps, most of which require going back to rebuild the risk management process rather than add documentation to an existing one. The organizations that approach it as an operational question — what are we actually doing to manage AI risk, and how would we know if it stopped working — find the documentation easier to produce because it describes something that exists.
That is the harder starting point, but it is the one that results in a certification that means something. A certificate issued against a paper AIMS holds until the first surveillance audit.