An ISO 42001 risk register that exists only to satisfy a checkbox looks fine right up until an auditor asks a specific question about a specific entry, and the trail runs cold. Clauses 6.1.2 through 6.1.4 require a documented AI risk assessment process, a risk treatment methodology, and an AI system impact assessment, but they do not hand over a spreadsheet template. Most organizations build one anyway, because tracking dozens of risks across multiple AI systems without a structured register is unmanageable. The problem is not that organizations skip this step. It is that the register they build is designed to be filled out, not designed to survive an assessor asking why a specific risk was rated the way it was.
This article covers what a risk register actually needs to contain to hold up under audit, how it should connect to the AI system impact assessment and the Statement of Applicability, and where auditability most often breaks down in practice.
What ISO 42001 Requires Versus What a Risk Register Is
ISO 42001 does not use the term risk register in its clause text. Clause 6.1.2 requires a defined AI risk assessment process that produces consistent, valid, and comparable results, identifying risks, analyzing their likelihood and consequences, and evaluating them against defined criteria to prioritize treatment. Clause 6.1.3 requires a risk treatment process that selects an approach for each identified risk, mitigate, avoid, transfer, or accept, and maps the resulting controls against Annex A to produce the Statement of Applicability. Clause 6.1.4 adds a requirement with no equivalent in ISO 27001: an AI system impact assessment evaluating the effects an AI system may have on individuals, groups, or society.
A risk register, as a named, structured document, is the practical artifact organizations build to satisfy all three of these clauses in one connected place. The standard requires the underlying activities. It does not require the specific spreadsheet, database, or tool used to track them, which means the register’s design is entirely the organization’s own decision, and a weak design is not the standard’s fault.
The Fields a Defensible Risk Register Needs
A risk register built for auditability needs more than a description and a severity rating. Nine fields, working together, are what let an assessor trace a conclusion back to evidence rather than take the organization’s word for it.
| Field | What it captures | Why an auditor checks it |
|---|---|---|
| AI system reference | Which specific system the risk belongs to | Confirms the risk is tied to something real in the AIMS scope, not floating unattached |
| Risk description | The specific failure mode or harm being assessed | Distinguishes a genuine risk from a vague restatement of a control name |
| Likelihood and consequence | The analysis behind the risk level, not just the level itself | Shows the rating was derived, not assigned arbitrarily |
| Risk level | The output of the likelihood and consequence analysis | Drives prioritization for treatment |
| Treatment decision | Mitigate, avoid, transfer, or accept, per Clause 6.1.3 | Confirms a deliberate decision was made, not an omission |
| Mapped Annex A control | Which control implements the treatment | Connects the risk register directly to the Statement of Applicability |
| Residual risk | What remains after treatment is applied | Shows the organization did not assume treatment eliminates risk entirely |
| Approval and date | Who accepted the residual risk and when | Documents accountability for risks that were not fully eliminated |
| Review date | When the entry was last revisited | Distinguishes a living register from one populated once and never touched again |
Reading across this table, the pattern that matters most is the link between risk level, treatment, and residual risk. A register that records a risk level and a treatment decision but never documents what risk remains after that treatment is applied has skipped the step an auditor is most likely to probe, because residual risk that was never explicitly accepted by someone with authority to accept it is a governance gap, not a documentation formality.
Why the AI System Reference Field Matters More Than It Looks
An organization operating several AI systems, or several versions of the same system serving different products, needs every risk entry traceable to a specific system, not a general statement about “our AI.” A risk register that aggregates findings across systems without this linkage cannot answer a basic auditor question: for this particular system, what risks were identified and how were they treated. Building this linkage into the register’s structure from the start, rather than trying to reconstruct it after the fact, is one of the highest-leverage design decisions available.
What a Complete Entry Actually Looks Like
The table below illustrates a single, complete risk register entry using the nine fields above, to make the structure concrete rather than abstract. It is illustrative, not a template to copy verbatim, since the actual content depends on the organization’s own systems and risk methodology.
| Field | Example content |
|---|---|
| AI system reference | Customer support chatbot, production environment |
| Risk description | Model may generate factually inaccurate responses to customer billing questions |
| Likelihood and consequence | Moderate likelihood based on observed error rate in testing; moderate consequence given potential for customer confusion, low safety impact |
| Risk level | Medium |
| Treatment decision | Mitigate |
| Mapped Annex A control | Human oversight control requiring escalation path for billing-related queries |
| Residual risk | Low; residual risk of occasional inaccurate response persists despite escalation path |
| Approval and date | Approved by AI Governance Body lead, dated |
| Review date | Quarterly, tied to model update cycle |
Notice that every field in this entry builds on the one before it. The risk description is specific to an actual failure mode, not a generic statement about accuracy. The likelihood and consequence analysis explains where the risk level came from rather than asserting it. The mapped control connects directly to what appears in the Statement of Applicability. The residual risk field is honest that the treatment reduces but does not eliminate the risk. This is the level of specificity an auditor is trained to look for, and it is achievable for every entry in a register without becoming an unreasonable documentation burden once the structure is established.
Connecting the Register to the Impact Assessment and the SoA
A risk register that stands alone, disconnected from the other documents Clauses 6.1.2 through 6.1.4 require, forces an assessor to manually cross-reference three separate artifacts to understand a single risk’s full lifecycle. A well-designed register avoids this by building the connections in directly.
Linking to the AI System Impact Assessment
Clause 6.1.4’s impact assessment evaluates effects on individuals, groups, or society, which is a different lens than the operational risk assessment under 6.1.2, but the two should inform each other rather than run as parallel, disconnected exercises. Designing the AI impact assessment alongside the risk register, with a field in the register that references the relevant impact assessment finding, keeps an auditor from having to independently determine whether a risk with clear societal or individual impact implications was actually considered through that specific lens. Key considerations for conducting the impact assessment apply directly to deciding which risk register entries warrant this deeper cross-reference.
Linking to the Statement of Applicability
The mapped Annex A control field in the risk register should point to the same control entries that appear in the Statement of Applicability, and the justification for a control’s inclusion or exclusion in the SoA should be traceable back to the specific risk register entries that drove that decision. A risk register and an SoA that were built independently, by different people or at different times, frequently drift out of alignment, with a control marked applicable in one document and absent or differently justified in the other. Reconciling this alignment once, early, is far less costly than discovering the mismatch during an external audit.
Who Should Own the Register
A risk register with no single accountable owner tends to accumulate stale entries even when the fields themselves are well designed, since nobody is specifically responsible for revisiting entries as systems change. The individual or function accountable for a given AI system’s risk entries should be the same one accountable for that system’s operational changes, so that a model update or new data source triggers a register review as a natural consequence of the change, not as a separate compliance task someone has to remember to initiate. Whether this accountability sits with a dedicated AI risk function, a governance committee, or individual system owners depends on organizational size and structure, but the register itself should record who that accountable party is for each entry, not just leave it implied.
Where Auditability Breaks Down in Practice
Three patterns repeatedly undermine an otherwise reasonable risk register, each avoidable with a small amount of upfront design discipline.
Risk Levels With No Visible Reasoning
A register that shows a risk level of “high” or “medium” with no record of the likelihood and consequence analysis behind it is asking an auditor to trust a conclusion with no visible evidence. Clause 6.1.2 requires the assessment process to produce consistent, valid, and comparable results, and a rating with no documented reasoning cannot be checked for consistency against any other entry in the same register, let alone reproduced by someone other than the original assessor. A practical test for this gap: pick any two entries rated at the same risk level and confirm the underlying likelihood and consequence reasoning is genuinely comparable between them. If the two entries were rated the same way for reasons that do not actually match, the register’s ratings are not consistent in the way Clause 6.1.2 requires, whatever the final numbers say.
Treatment Decisions Without Residual Risk
A risk marked as treated, with a control mapped and no further detail, implicitly claims the treatment fully eliminated the risk, which is rarely true for AI-specific risks like bias, hallucination, or model drift. ISO 42001 risk remediation and management review depends on residual risk being documented honestly, because a management review that only sees “risk treated” entries with no visibility into what remains cannot make an informed decision about whether the organization’s overall risk posture is acceptable.
A Register That Was Populated Once and Never Revisited
The review date field exists because AI systems change faster than most organizations’ formal review cycles anticipate. A model update, a new data source, or an expanded use case can materially change a risk’s likelihood or consequence, and a register with entries last reviewed a year before a certification audit signals that the risk assessment process is not actually operating continuously, whatever the documentation claims. Internal audit planning for the AIMS should specifically check review dates across the register as part of confirming the process is genuinely ongoing rather than a one-time exercise dressed up as continuous.
Risk Registers for Organizations With an Existing ISO 27001 Program
Organizations already certified to ISO 27001 sometimes assume their existing information security risk register can simply be extended to cover AI risk, since both standards share the same Harmonised Structure. The overlap between ISO 42001 and ISO 27001 is real at the process level, but AI-specific risks, bias, explainability, model drift, and the societal impact dimension Clause 6.1.4 introduces, do not fit cleanly into a register designed around confidentiality, integrity, and availability. A separate, purpose-built AI risk register that references the shared organizational risk methodology, rather than a single undifferentiated register trying to serve both standards, tends to produce cleaner evidence for both certifications.
Vendor and Model Supplier Risk
A risk register also needs to account for risk introduced through third-party AI models, APIs, or vendors, not only risk from systems the organization builds itself. Managing AI model suppliers and third-party risk under ISO 42001 requires these vendor-introduced risks to appear in the same register with the same rigor as internally developed system risks, since an auditor will not accept a narrower scope simply because the underlying model was licensed rather than built in-house.
Elevate helps organizations design ISO 42001 risk registers that connect cleanly to the impact assessment and the Statement of Applicability, with the field-level structure an auditor expects to see rather than a generic spreadsheet retrofitted to the standard. To review whether your current risk register would hold up under certification, book a readiness call with an Elevate advisor.
Conclusion
A risk register is not a document ISO 42001 names directly, but it is the practical structure most organizations need to satisfy Clauses 6.1.2 through 6.1.4 in a connected, defensible way. The nine fields that make a register auditable, system reference, description, likelihood and consequence, risk level, treatment decision, mapped control, residual risk, approval, and review date, are not bureaucratic overhead. They are what let an assessor trace a conclusion back to evidence instead of taking the organization’s word for it.
Building this structure before certification pressure forces a rushed retrofit is far less costly than discovering, during an actual audit, that the register cannot answer the specific questions an assessor is trained to ask. Elevate designs risk registers built to survive that exact test. Book a readiness call to review what your current register would need to hold up.
Key Takeaways
- ISO 42001 requires the risk assessment, treatment, and impact assessment activities under Clauses 6.1.2 through 6.1.4, but does not name or template the risk register itself. The register’s design is entirely the organization’s decision, and a weak design is not the standard’s fault.
- Nine fields make a register defensible: system reference, description, likelihood and consequence, risk level, treatment decision, mapped control, residual risk, approval, and review date. The link between treatment and residual risk is where auditors probe most often.
- The register should connect directly to the AI impact assessment and the Statement of Applicability, not stand alone. Independently built documents that drift out of alignment are a common, avoidable audit finding.
- A risk rated without visible likelihood and consequence reasoning cannot be checked for consistency. Clause 6.1.2 requires the assessment process to produce consistent, valid, and comparable results, which an unreasoned rating cannot demonstrate.
- Third-party AI models and vendors need the same register rigor as internally built systems. An auditor will not accept a narrower scope simply because a model was licensed rather than developed in-house.
FAQs
What is an AI risk register? An AI risk register is a structured document organizations build to track identified AI risks, their likelihood and consequence, the treatment decision applied, and the residual risk that remains. It is the practical artifact most organizations use to satisfy ISO 42001’s Clause 6.1.2 risk assessment and Clause 6.1.3 risk treatment requirements in one connected place, although ISO 42001 does not name or template the register directly.
How do I build an AI risk register that will hold up under audit? Build the register around nine core fields: the specific AI system the risk belongs to, a specific risk description, the likelihood and consequence analysis behind the rating, the resulting risk level, the treatment decision, the Annex A control that implements that treatment, the residual risk remaining after treatment, documented approval of that residual risk, and a review date. A register missing the link between treatment and residual risk, or lacking visible reasoning behind risk levels, is the most common gap auditors identify.
What are typical entries in an ISO 42001 AI risk register? Common entries include risks related to model bias or unfair outcomes, hallucination or inaccurate outputs in generative systems, data quality issues affecting training or inference, model drift as a system’s behavior changes over time in production, and risks introduced through third-party models or vendors. Each entry should be tied to a specific AI system rather than described as a general organizational risk.
How does the risk register relate to the Statement of Applicability? The Annex A control mapped to each risk register entry should correspond to the same control’s treatment in the Statement of Applicability, and the justification for including or excluding a control in the SoA should trace back to the specific risk entries that drove that decision. A risk register and an SoA built independently by different people frequently drift out of alignment, which is a common finding when the two documents are compared directly during an audit.
Can an existing ISO 27001 risk register be extended to cover AI risk under ISO 42001? While ISO 27001 and ISO 42001 share the same overall management system structure, AI-specific risks like bias, explainability, and model drift, along with the societal impact dimension ISO 42001’s impact assessment requirement introduces, do not fit cleanly into a register designed around information security’s confidentiality, integrity, and availability model. A separate, purpose-built AI risk register that references the shared organizational risk methodology typically produces cleaner, more defensible evidence for both certifications than a single register trying to serve both standards at once.