The seven sections every AI risk management plan needs — with a worked example and the five mistakes auditors flag most
Among the documents ISO/IEC 42001 requires, one causes more hesitation than most: "How are we supposed to write the AI risk management plan? Is there a required format?" There isn't — the standard specifies no template, and organizations are free to design their own. What it does specify is substance: the elements the document must contain. This article lays out a seven-section structure you can adopt as-is, a worked example, and the five mistakes that most often turn this document into an audit finding.
What the document is
An AI risk management plan documents, systematically and per AI system: what risks exist (identification), how serious each one is (analysis and evaluation), what the organization will do about them (treatment), and whether what remains after treatment is acceptable (residual risk review). In ISO/IEC 42001 terms it is the core output of Clause 6.1 — risks and opportunities. The word plan is doing real work in that title: a list of risks is not enough; the document has to show how the risks will be managed. The assessment methodology behind it is its own discipline — our five-step AI risk assessment guide covers the how; this article covers how to write the result down so it stands up in an audit.
The seven sections
Section 1 — Document control
Document name and number, version, dates of issue and last revision, author, reviewer, approver, and scope of application. Keep a revision history table (version, date, change, author) from day one. An auditor opening this document turns first to the revision history and the approval line — a plan with neither reads as shelf-ware before page two.
Section 2 — AI system overview
Describe the system well enough that a reader who has never seen it understands what it does. Cover:
- Name and purpose — e.g. "Customer service AI chatbot — 24/7 automated first-line handling of customer inquiries"
- Technology and model — e.g. "Conversational AI built on an external large-language-model API"
- Input data — e.g. "Customer message text; account data (signup date, purchase history)"
- Outputs and decisions — e.g. "FAQ answers; inquiry categorization; escalation-to-human decisions"
- Degree of automation — e.g. "FAQ responses fully automated; refund and compensation decisions require human agent approval"
Section 3 — Risk identification
This is where AI-specific risk categories must appear — every one of them reviewed, even if some are then assessed as negligible. A working checklist of nine, each with its screening question:
- Bias — could the AI treat particular groups unfairly?
- Opacity — can the organization explain why the AI decided what it decided?
- Malfunction — could the AI produce unintended, incorrect outputs?
- Data quality — could errors or bias in training or input data flow into outcomes?
- Security — is the system exposed to adversarial inputs or prompt injection?
- Human-oversight failure — could AI decisions escape appropriate human review?
- Supply chain — could disruption or change in an external AI service break yours?
- Privacy — could personal data leak or be misused in AI processing?
- Performance drift — could model performance degrade over time?
Section 4 — Risk analysis and evaluation
Score each identified risk for likelihood and impact on 1–5 scales, multiply for a risk score, and band the results: 20–25 critical (treat immediately), 12–19 high (treat as a priority), 6–11 medium (treat on a planned schedule), 1–5 low (monitor). From the chatbot example: "chatbot gives incorrect refund-policy guidance" (malfunction, likelihood 3 × impact 3 = 9, medium); "prompt-injection attack produces anomalous responses" (security, 2 × 5 = 10, medium); "external API outage takes the chatbot down entirely" (supply chain, 2 × 4 = 8, medium); "personal data appears in AI responses" (privacy, 2 × 5 = 10, medium). Each risk gets an ID — you will reference them everywhere downstream.
Section 5 — Risk treatment plan
For each risk: a strategy (avoid, reduce, transfer, accept), a concrete control, an owner, and a completion date. Concrete is the operative word. Continuing the example: the refund-guidance risk gets "human agent review mandatory for refund and compensation responses; monthly review of incorrect-guidance cases — owner: customer service lead"; the injection risk gets "hardened input filtering; automated anomaly alerts — owner: IT lead"; the outage risk gets "fallback customer path plus strengthened SLA terms with the provider" — a reduce-and-transfer combination.
Section 6 — Residual risk review and approval
After controls, re-score. The example plan closes with all five risks reduced to low, inside the organization's stated risk appetite — and a management approval line saying exactly that, with the approver's name and date. Acceptance is a management decision, not a practitioner's default.
Section 7 — Monitoring and re-review
Define what gets monitored, how, how often, and by whom — incorrect-guidance counts monthly from service records, response-quality sampling quarterly, anomaly detection in real time, privacy log audits monthly. Then define the re-review triggers: model updates, service-scope changes, incidents or complaints, new regulation, and in any case at least annually.
The five mistakes auditors flag most
- Only IT risks listed. Hacking and server outages, but no bias, opacity, or malfunction — the register reads as an IT document with an AI title, and in an ISO 42001 audit that is a fast route to the most common nonconformity there is.
- Abstract controls. "Strengthen monitoring" and "conduct training" cannot be verified as done or not done. "Measure the incorrect-guidance rate monthly and report to the AI officer" can.
- No residual risk review. Controls were planned, but nothing shows whether the risk that remains afterwards is acceptable. If residual risk is still high, further treatment is due — and no one can know without the re-score.
- No management approval. A practitioner can draft the plan, but review and approval belong to management — acceptance decisions above all.
- Never updated. A plan untouched since its first version tells an auditor the document is not part of how the organization actually operates. The periodic re-review records are what prove it lives.
One document or several?
With multiple AI systems, two structures work. Separate plans per system capture each system's specifics but multiply the maintenance burden. A combined document — common policy and procedure in the body, per-system risk tables as annexes — keeps the overhead manageable and is usually the better fit for smaller organizations. Either is acceptable to the standard; what matters is that every in-scope system is covered and traceable.
A completion checklist
- ☐ Document control complete — version, dates, author, approver
- ☐ System overview a stranger could understand
- ☐ All nine AI-specific risk categories reviewed
- ☐ Likelihood and impact scored per risk
- ☐ Strategy and concrete control per risk, with owner and date
- ☐ Residual risk re-scored and management-approved
- ☐ Monitoring items, methods, frequency, and owners defined
- ☐ Re-review triggers stated
- ☐ For the audit: latest version in hand, control implementation records kept separately, monitoring results on file, approval signature present
The bottom line
The AI risk management plan is one of the documents a certification auditor examines most closely — it sits at the junction where the required document set meets actual operation. Format matters far less than fidelity: a plan that reflects the real context of your AI systems, in your own structure, will outperform a borrowed template filled in from imagination every time. Build on the seven sections above, keep it current, and the audit conversation about this document becomes a short one.
Not sure whether your risk documentation is where it needs to be? Our free AI governance readiness assessment takes about 10 minutes, requires no document uploads, and shows where you stand against ISO/IEC 42001 — risk management included.
Related
📗 The methodology behind the document: a five-step AI risk assessment methodology that holds up in an audit.
📄 Where this document fits: the 10 documents your certification audit will check.
🔍 What goes wrong: the 5 nonconformities most likely to appear in your ISO 42001 audit.
🗺 The whole portfolio: part of our SC 42 AI Standards Map — the international AI standards portfolio, explained.