ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
An AI risk register is the document that turns the NIST AI Risk Management Framework from four verbs into a working record: which AI systems the organization runs, what could go wrong with each, how likely and how severe that is, what has been done about it, and who owns the residual. NIST AI 100-1 does not prescribe a register by name, but its Map, Measure and Manage functions describe exactly the information one holds, and its Govern function requires the risk tolerance and the accountability the register is scored against. This guide sets out the twelve fields an AI risk register needs, the seven risk sources the AI RMF and ISO/IEC 42001 agree on, how to score AI risks when likelihood is not a frequency, and how the register connects to the model inventory, the impact assessment and the incident process.
A cybersecurity risk register records threats to assets with likelihood and impact. An AI risk register records something wider, because the AI RMF defines AI risk as the composite of the probability of an event and the magnitude of its consequences to individuals, organizations and society — including harms the organization does not itself suffer. Three differences follow. The risk sources include the model’s own behaviour (bias, drift, hallucination), not only external threats. The affected parties include people outside the organization, which is why the AI RMF’s Map function asks whose interests are at stake. And likelihood is often not a frequency but a judgement about a system whose behaviour is statistical, which changes how the register is scored. Our guide to the cybersecurity risk register covers the conventional model this one extends.
| # | Field | AI RMF source | What goes in it |
|---|---|---|---|
| 1 | System ID and name | Map 1 | Link to the AI inventory entry; version; owner |
| 2 | Use case and context | Map 1.1–1.2 | Intended purpose, deployment setting, users, affected parties |
| 3 | Risk statement | Map 5 | Cause, event, consequence: ‘Because X, Y could happen, harming Z’ |
| 4 | Risk source | Map 5; ISO 42001 Annex C | One of the seven sources below |
| 5 | Trustworthiness characteristic affected | AI RMF section 3 | Valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; fair with harmful bias managed |
| 6 | Affected parties | Map 1.6, 5.2 | Users, subjects, third parties, the organization, society |
| 7 | Likelihood | Measure 2 | A rated judgement with its basis: test results, monitoring data, incident history, expert estimate |
| 8 | Severity | Measure 2 | Magnitude of harm to the affected parties, rated; legal and regulatory exposure noted |
| 9 | Inherent and residual rating | Govern 1.3 tolerance | Rating before and after treatment, against the organization’s AI risk tolerance |
| 10 | Treatment and controls | Manage 1–2 | Avoid, mitigate, transfer, accept; the specific controls, tests and human oversight applied |
| 11 | Metrics and monitoring | Measure 1, 3 | The metric that shows the risk is controlled, its threshold, its frequency, its owner |
| 12 | Owner, status, review date | Govern 2; Manage 4 | Accountable role; open/treated/accepted; next review and trigger events |
The AI RMF’s Map function and ISO/IEC 42001’s Annex C describe risk sources in overlapping terms; combining them gives a checklist that catches most of what an AI system can do wrong.
| Risk source | Typical risks | Where it shows up |
|---|---|---|
| Data quality and provenance | Training data unrepresentative, mislabelled, stale, obtained without rights; data leakage into training | Bias findings; legal exposure; performance drift |
| Model performance and reliability | Accuracy below requirement in production; degradation over time; failure on edge cases; hallucination in generative models | Wrong outputs acted on; safety incidents |
| Bias and fairness | Disparate outcomes across protected groups; proxy discrimination | Regulatory action; individual harm |
| Security and adversarial | Prompt injection, data poisoning, model extraction, evasion, supply chain compromise of models or libraries | Confidentiality and integrity failures |
| Transparency and explainability | Decisions that cannot be explained to the affected person or the regulator; undisclosed AI use | Legal obligations (EU AI Act Article 50, GDPR Article 22); loss of trust |
| Human oversight and misuse | Over-reliance on outputs; oversight that cannot intervene in time; use outside intended purpose | Automation bias; scope creep into high-risk uses |
| Third-party and lifecycle | Foundation model changes without notice; vendor terms; decommissioning without records | Loss of control over the system’s behaviour |
Likelihood in an AI risk register has three legitimate bases, and the register should say which was used: measured — a test or monitoring metric (false positive rate on the holdout set, disparity ratio in production); observed — incident and near-miss history for this or a comparable system; or estimated — expert judgement, with the estimator named. Severity is rated on the magnitude of harm to the affected parties, and for AI the scale needs a legal column: a risk that engages the EU AI Act’s high-risk obligations, a GDPR Article 22 decision, or a sector regulator’s rules is severe regardless of the number of people affected. The AI RMF’s Govern 1.3 requires the organization to define its risk tolerance; the register applies it as the line between accepted residual risk and risk that must be treated further. Our guide to the NIST AI RMF Playbook covers the suggested actions behind each of these subcategories.
Does the NIST AI RMF require an AI risk register?
Not by name. Its Map, Measure and Manage functions describe the information a register holds — context, risks, likelihood and severity, treatment, residual risk and monitoring — and Govern requires the tolerance and accountability the register is scored against. A register is the practical way to evidence all four.
How is an AI risk register different from an IT risk register?
It includes the model’s own behaviour — bias, drift, hallucination — as a risk source, records harm to people outside the organization, and states the basis for each likelihood because AI behaviour is statistical rather than a frequency.
What are the AI risk sources?
Data quality and provenance; model performance and reliability; bias and fairness; security and adversarial; transparency and explainability; human oversight and misuse; third-party and lifecycle — drawn from the AI RMF Map function and ISO/IEC 42001 Annex C.
Can one register serve NIST AI RMF and ISO 42001?
Yes. The fields map onto ISO 42001 clause 6.1 risk assessment and treatment and Annex C’s objectives and sources; the register is the same document with a crosswalk column.
How often should it be reviewed?
On trigger events — model updates, foundation-model changes, new contexts, incidents — and on a scheduled cycle per system, with the top residual risks reported to leadership at management review.
Build the AI risk register with twelve fields, one row per risk rather than per system, the seven sources as the checklist, likelihood with its basis stated, severity with a legal column, and a metric behind every treatment. Join it to the inventory, the impact assessment, the monitoring and the incident process, and it becomes the record the AI RMF’s four functions describe — and the evidence an ISO/IEC 42001 auditor or an EU AI Act conformity assessment reads first.
The AI Risk Register and Risk Treatment Plan templates, the AI Inventory and Use Case Register, the AI Impact Assessment procedure and the AI Risk Tolerance and Acceptance Criteria document are in the NIST AI RMF Toolkit (36 templates), or start with the free templates.
September 21, 2026
September 21, 2026
September 20, 2026
September 20, 2026
September 19, 2026