What Is ISO 42001 Clause 6: Planning for AI Risk Management
Planning is where governance stops being a statement and becomes a set of decisions. Clause 6 makes you define risk criteria, assess and treat AI risks, assess the impact on actual people, set measurable objectives, and control how the system changes.
ISO/IEC 42001:2023 spends Clause 4 asking what you are governing and Clause 5 asking who owns it. Clause 6 asks the harder question: what are you actually going to do about the risks? This is the planning clause, and it is where an AI management system starts producing decisions instead of statements.
Clause 6 carries the title Planning. It has three numbered parts. Sub-clause 6.1 covers actions to address risks and opportunities, and it splits into four pieces of its own: general planning and risk criteria (6.1.1), AI risk assessment (6.1.2), AI risk treatment (6.1.3), and the AI system impact assessment (6.1.4). Then 6.2 requires AI objectives and a plan to achieve them, and 6.3 requires that changes to the management system happen in a planned way rather than by accident.
The center of gravity sits in that first sub-clause. The standard wants a repeatable machine: criteria that say what risk you will and will not accept, an assessment process that finds and prioritizes risks against those criteria, a treatment process that picks controls and writes down why, and an impact assessment that looks past your own walls at the individuals, groups, and societies your AI systems touch. Each piece produces documented outputs the next piece consumes, and the whole thing is later executed and re-run under Clause 8.
A quick note on how to read this guide. ISO/IEC 42001 states its requirements with the word shall. Those are the things an auditor will look for. Supporting practice, such as how to build a risk matrix or run scenario planning, comes largely from ISO/IEC 23894, the AI risk management guidance standard, which speaks in should. This article keeps the two apart so you always know what is mandatory and what is simply sensible.
Why Clause 6 Is the Operational Heart of the AIMS
Every other clause either feeds Clause 6 or executes what Clause 6 decided. If planning is weak, the whole management system runs on guesses.
Here is the structural reality. The context and stakeholder work from Clause 4 has no effect on anything until 6.1.1 turns it into risks and opportunities. The AI policy leadership signed under Clause 5 is just words until 6.1.2 aligns a risk assessment process with it. And Clause 8, the operation clause, does not invent anything new. It runs the assessment process you defined in 6.1.2, implements the treatment plan you wrote in 6.1.3, and executes the impact assessment process from 6.1.4. Clause 6 is the room where the decisions get made. Everything after it is execution and checking.
There is also a quiet discipline built into this clause that separates real programs from paper ones. Risk criteria force you to say, in advance and in writing, what an acceptable risk looks like. The Statement of Applicability forces you to justify every control you adopt and every one you skip. Measurable objectives force you to define what success means. None of that is busywork. It is the difference between a program that can defend its choices and one that discovers its choices during an incident.
Risk Appetite in Writing
AI risk criteria draw the acceptable/non-acceptable line before any single project argues its case.
Repeatable, Not Heroic
The 6.1.2 process must give consistent, valid, comparable results every time it runs, not one good workshop.
Controls With Receipts
Risk treatment ends in a Statement of Applicability that justifies every included and excluded control.
People on the Receiving End
The impact assessment looks at consequences for individuals, groups, and societies, beyond the balance sheet.
The Six Parts of Clause 6, In Sequence
Six numbered parts, one pipeline. Criteria feed assessment, assessment feeds treatment, impact assessment feeds back into assessment, and objectives plus change planning keep the whole thing pointed somewhere. Expand any item for the detail.
The ordering is deliberate. You cannot prioritize risks without criteria to compare them against, and you cannot pick controls without a prioritized risk list. The impact assessment runs alongside the risk assessment and feeds it. Objectives give the plans a destination, and change planning keeps later modifications from quietly unwinding all of it.
6.1.1 General: Risks, Opportunities, and Risk Criteria
Take the issues from 4.1 and the interested-party requirements from 4.2, determine the risks and opportunities the AIMS must address, plan actions for them, and establish AI risk criteria.
The purpose is threefold: give assurance the AIMS can achieve its intended outcomes, prevent or reduce undesired effects, and achieve continual improvement. The organization plans actions to address the risks and opportunities, integrates those actions into AIMS processes, and evaluates their effectiveness. The risk criteria requirement is the anchor: criteria that state which AI risks you will accept and which you will not, and that give the assessment, treatment, and impact analysis work a common yardstick to compare against. Page 16 of the standard.
This is a 42001 requirement (a shall). The common practice of expressing criteria as a likelihood-and-impact matrix comes from risk guidance, not the standard itself.
6.1.2 AI Risk Assessment
Define and establish an AI risk assessment process that identifies, analyzes, and prioritizes AI risks against the criteria from 6.1.1.
The process must align with the AI policy and AI objectives, and it must be built to produce consistent, valid, and comparable results on repeated runs. It identifies risks that can affect the AI objectives, analyzes them by assessing potential consequences to the organization, individuals, and societies, assesses likelihood where applicable, determines risk levels, and prioritizes the analyzed risks by comparing them against the risk criteria. Page 17 of the standard.
This is a 42001 requirement. Techniques like asset inventories and what-if scenario planning are guidance-level practice you can adapt.
6.1.3 AI Risk Treatment
Define and apply a treatment process: pick treatment options, determine controls, compare against Annex A, and produce a Statement of Applicability and a treatment plan.
Treatment selects the appropriate options for each prioritized risk, determines the controls needed to implement them, and then runs the Annex A comparison to verify no necessary control was missed. Controls beyond Annex A can be added where the risk demands it. The outputs are concrete: a Statement of Applicability with justifications for inclusions and exclusions, an AI risk treatment plan, and management approval of that plan along with acceptance of the residual risks. Pages 17 and 18 of the standard.
This is a 42001 requirement, and it produces the most audit-visible documents in the whole clause.
6.1.4 AI System Impact Assessment
Define a process for assessing the potential consequences of your AI systems for individuals, groups of individuals, and societies.
The assessment covers consequences that can result from the development, provision, or use of AI systems. It must account for deployment, intended use, and reasonably foreseeable misuse, read against the technical and societal context and the jurisdictions the system operates in. Results are documented and fed into the broader 6.1.2 risk assessment. Page 18 of the standard.
This is a 42001 requirement, and it is the sub-clause most often confused with the risk assessment. The distinction gets its own treatment below.
6.2 AI Objectives and Planning to Achieve Them
Establish AI objectives at relevant functions and levels, make them measurable where practicable, and plan concretely how each will be achieved.
Objectives must be consistent with the AI policy, measurable if practicable, mindful of applicable requirements, monitored, communicated, updated as appropriate, and kept as documented information. The achievement plan has to answer five plain questions: what will be done, what resources are required, who is responsible, when it will be completed, and how the results will be evaluated.
This is a 42001 requirement. Vague aspirations do not satisfy it; the documentation and communication duties are explicit.
6.3 Planning of Changes
When the organization determines the AIMS needs to change, carry the change out in a planned manner.
One sentence of requirement with a long shadow. New models, new vendors, new use cases, and reorganizations all change the management system. This sub-clause says none of that happens informally. The change is planned, which in practice means the risk and impact processes from 6.1 get a say before the change lands.
This is a 42001 requirement, short enough to memorize and easy to violate.
Requirement or guidance? Read the verb.
Across Clause 6, a sentence that says the organization shall do something is a requirement of ISO/IEC 42001. The practical technique layer, such as risk matrices, asset inventories, and scenario planning, comes largely from ISO/IEC 23894 guidance and says should. Frameworks such as NIST AI RMF appear here as cross-references, not as 42001 obligations.
The Risk Trio: Assess, Treat, and Assess the Impact
Sub-clause 6.1 is a chain of four connected processes. Criteria set the bar, assessment finds and ranks the risks, treatment picks the controls, and the impact assessment keeps the analysis honest about the people on the receiving end.
Start with the criteria, because everything else compares against them. In practice, organizations express risk criteria as a likelihood-and-impact matrix, often a red-amber-green scheme or a numeric 5×5 scale that runs from negligible to critical. ISO/IEC 23894 guidance adds a warning that matters for AI specifically: understand the uncertainty in every part of the system, meaning the data, the software, the mathematical models, any physical extensions, and the human aspects such as data collection and labeling. A matrix built only around software failure misses most of what makes AI risk different.
The assessment process then works through what it could lose and how. Guidance frames the inputs in three groups. Assets: tangible ones like data, models, and hardware, intangible ones like reputation and trust, plus things of value to individuals (privacy, health, safety) and to societies (environmental sustainability, equity). Risk sources: data quality, model complexity, the deployment environment, the human-AI configuration, and dependencies on external parties. And scenarios: what-if simulations of malfunction, malicious use, or data poisoning that put severity and likelihood on something concrete. Treatment closes the loop with four familiar moves. Avoid the risk by not proceeding. Reduce it with safeguards, process changes, or guardrails. Transfer it through insurance or vendor contracts. Or accept it, knowingly and on the record, when it sits inside your criteria.
The table below is the working map of 6.1. Each row is one planning component. Click any row for what it requires, what it consumes, what it produces, where it sits in the standard, and the mistake that most often sinks it.
▸ The Clause 6.1 planning components. Click any row for requirements, inputs, outputs, and the common mistake.
| Planning Component | What It Does | Key Output |
|---|---|---|
| Risk Criteria (6.1.1) | Sets the line between acceptable and non-acceptable AI risk before any project argues its case. | Documented AI risk criteria plus planned actions for risks and opportunities. |
| Risk Assessment (6.1.2) | Identifies, analyzes, and prioritizes AI risks against the criteria, repeatably. | A prioritized, comparable risk picture aligned to policy and objectives. |
| Risk Treatment (6.1.3) | Selects treatment options and controls, checked against Annex A so nothing necessary is missed. | Approved treatment plan and accepted residual risks. |
| Statement of Applicability (6.1.3) | Justifies every control you include, every one you exclude, and whether each is implemented. | The SoA, the audit’s favorite document. |
| Impact Assessment (6.1.4) | Assesses consequences for individuals, groups, and societies, including foreseeable misuse. | Documented impact results feeding the 6.1.2 assessment. |
Component structure drawn from the Clause 6.1 sub-clause sequence, pages 16 through 18 of ISO/IEC 42001:2023.
The pair that trips people up is 6.1.2 versus 6.1.4. They sound alike, they both produce risk-shaped documents, and plenty of programs quietly merge them into one exercise. The standard keeps them separate for a reason, and the tabs below show where the line runs.
The 6.1.2 risk assessment is governance and organization oriented. It asks what threatens your objectives, your compliance posture, your finances, and your technology alignment, and it weighs consequences to the organization alongside downstream effects on individuals and societies. Risk management and compliance teams usually run it, and it acts as the master decision-making frame for the AIMS. Its defining trait is repeatability: the process has to produce consistent, valid, comparable results every time, so two assessors looking at the same system land in the same place.
The 6.1.3 treatment process is where analysis becomes commitment. For each prioritized risk you pick a treatment option (avoid, reduce, transfer, or accept), determine the controls that implement it, and compare your control set against the Annex A reference controls to verify nothing necessary was omitted. You can add controls beyond Annex A when the risk calls for it. Then comes the paperwork that makes it real: the Statement of Applicability, the risk treatment plan, and sign-off from designated management, including explicit acceptance of the residual risks that remain after treatment.
The 6.1.4 impact assessment is product and service oriented, and it deliberately narrows its audience to individuals, groups of individuals, and societies. It examines how deployment, intended use, and reasonably foreseeable misuse could affect fairness, accountability, transparency, safety, health, and human rights, read against the technical and societal context and the jurisdictions involved. Interdisciplinary teams tend to run it, blending engineering with social-science perspectives. It does not replace the risk assessment. It feeds it.
Turn Clause 6 into working assessments. The ISO 42001 Starter Bundle includes the AIMS Assessment and Implementation Toolkit and the AIMS Automated Assessment Spreadsheet, so your risk criteria, assessments, and treatment records exist as documents an auditor can read, not intentions.
Seven editable templates that turn the planning clause into audit-aligned documented information.
The Statement of Applicability, in plain terms
The SoA produced under 6.1.3 answers four questions in one document. Which controls, from Annex A and beyond, are necessary to treat your risks? Why are they included? Is each one actually implemented yet? And for every Annex A control you left out, what is the documented justification? Valid exclusions exist, such as controls your risk assessment shows are not needed or that no applicable framework requires. What does not exist is a valid silent exclusion.
AI Objectives You Can Actually Measure
Sub-clause 6.2 turns the AI policy into targets. Objectives get set at the functions and levels where the work happens, and each comes with a concrete plan.
The requirement has two halves. The first defines what a valid AI objective looks like: consistent with the AI policy from Clause 5, measurable if practicable, mindful of applicable requirements, monitored, communicated, updated as appropriate, and available as documented information. Each of those words carries weight. An objective nobody communicates fails the clause even if it is written down somewhere. An objective nobody monitors fails it even if it was communicated on day one.
The second half is the planning test. For every objective, the standard wants five answers: what will be done, what resources it takes, who is responsible, when it will be complete, and how the results will be evaluated. Notice how hostile that list is to vagueness. “Improve model fairness” survives none of the five questions. “Reduce false-positive disparity between demographic groups below a defined threshold by Q3, owned by the ML platform lead, evaluated through the quarterly bias audit” survives all of them. The clause also expects objectives at relevant functions and levels, plural. A single corporate-level aspiration does not reach the teams whose daily decisions carry the risk.
What an Objective Must Be
What Must Happen to It
The Five Planning Answers
Objectives are load-bearing for the risk work
The 6.1.2 risk assessment process identifies risks that can affect the AI objectives. That means weak objectives quietly weaken the risk assessment too, because there is nothing sharp for risks to be assessed against. Set objectives that mean something and the risk register inherits that precision.
Planning of Changes: One Sentence With a Long Reach
When the organization decides the AIMS needs to change, the change happens in a planned manner. That is the whole requirement, and it is easy to underestimate.
AI programs change constantly. A new foundation model swap. A vendor replacement. A use case migrating from internal pilot to customer-facing product. A reorganization that moves the AI platform team under a different executive. Every one of those alters the management system, and 6.3 says none of them happens informally. Planned, in practice, means the change gets the same treatment as any other risk-bearing decision: the 6.1.2 assessment process gets a look, the impact assessment from 6.1.4 gets re-run if people-facing consequences shift, and the treatment plan and Statement of Applicability get updated if the control picture moves.
This sub-clause pairs with the continual-improvement thread that runs through the whole standard. Clause 4 told you to keep context under review, and Clause 8 will require re-running assessments at planned intervals or on significant change. Sub-clause 6.3 is the connective tissue: it makes “we changed the system” a planned event with inputs and records, rather than something the audit discovers by comparing this year’s architecture diagram against last year’s.
Where Organizations Actually Fail at Clause 6
Planning failures rarely look like failures at the time. They look like efficiency. These are the recurring patterns documented across AI governance sources, and each one traces back to a specific sub-clause being shortcut.
Risk assessment run as an IT exercise
Data scientists or engineers assess socio-technical risks alone, without legal, compliance, ethics, security, and business-unit involvement. The 6.1.2 consequence analysis for individuals and societies never really happens.
Vague risk criteria
Ambiguous policies and undefined risk tolerances cascade downward into incomplete documentation and poorly executed project-level assessments. If 6.1.1 never draws the acceptable/non-acceptable line, nothing downstream can respect it.
Point-in-time assessments
Risk and impact assessments run once at project inception and never again, while the model meets live data, drifts, and gets updated. The 6.1.2 requirement for repeatable, comparable results assumes you actually repeat them.
Foreseeable misuse never analyzed
Off-label use, unintended applications, and reasonably foreseeable misuse get skipped during planning, even though 6.1.4 names them explicitly. The gap surfaces later, in production, with real people involved.
AI left out of existing governance
AI systems stay off the corporate risk register, out of threat modeling, and absent from business continuity planning. The AIMS becomes an island, and Clause 6’s outputs never reach the processes that could act on them.
Automation bias in the plan itself
The planning team assumes a sophisticated or reputable-vendor system is error-free, so human-in-the-loop oversight and rollback procedures never get planned. Trust in the tool substitutes for evidence, which is exactly what the impact assessment exists to prevent.
From Clause 4 Context to Clause 8 Operation
Clause 6 is the Plan stage of the management system’s Plan-Do-Check-Act rhythm. It consumes everything Clauses 4 and 5 produced and hands Clause 8 its marching orders.
Upstream, the connections are explicit. Sub-clause 6.1.1 takes the external and internal issues from 4.1 and the interested-party requirements from 4.2 as the raw material for determining risks and opportunities. The risk assessment process in 6.1.2 must align with the AI policy leadership established under Clause 5 and with the objectives set in 6.2. If the Clause 4 context work was thin, Clause 6 inherits the thinness and formalizes it, which is worth remembering before blaming the risk register.
Downstream, Clause 8 is the execution of everything planned here. Operation runs risk assessments in accordance with the process you defined in 6.1.2, at planned intervals and when significant changes occur. It implements the treatment plan from 6.1.3 and verifies the plan actually works. It executes AI system impact assessments according to the 6.1.4 process. Clause 8 invents nothing; it runs what Clause 6 wrote. Between the two sits Clause 7, which supplies the resources, competence, awareness, and documentation machinery your plans quietly assume exist.
The through-line
A risk criteria decision made in 6.1.1 shapes which risks 6.1.2 prioritizes, which controls 6.1.3 selects, and which operational checks Clause 8 runs for years afterward. Planning debt compounds. The standard’s sequencing exists so that by the time anything ships, the hard arguments about acceptable risk have already been had, in writing, with names attached.
Where This Comes From
Every requirement on this page traces to the published standards below. We cite clause numbers and paraphrase in plain language rather than reproducing the standards’ copyrighted text, so treat this as a guide to the standard, not a replacement for it.
Standards this guide is grounded in
ISO/IEC 42001:2023 is the source of every Clause 6 requirement, the statements written with “shall”: 6.1.1 general planning and risk criteria, 6.1.2 AI risk assessment, 6.1.3 AI risk treatment and the Statement of Applicability, 6.1.4 the AI system impact assessment, 6.2 AI objectives, and 6.3 planning of changes, along with the Annex A reference controls the treatment process compares against. ISO/IEC 23894:2023, the AI risk management guidance standard, supplies the “should” layer: risk matrix practice, uncertainty across data, models, and human factors, asset and risk-source framing, and scenario planning. NIST AI RMF 1.0 appears as a cross-reference for risk management practice, not as a 42001 obligation.
Keep going: compare ISO 42001 against NIST AI RMF and the EU AI Act in the Framework Explorer, look up any unfamiliar term in the AI Glossary, or browse the full clause series and templates in the ISO 42001 Resource Center.
Frequently Asked Questions
