An AI risk register template should list each AI system, the risk event, affected people or process, owner, inherent and residual risk, control, evidence, review cadence, trigger, and decision required. It is a board tool, not a one-off assessment.
Key takeaways
- A board register is a decision instrument: every row should end with a named owner, dated evidence and the next action, not just a red, amber or green status.
- The strongest structure is NIST's Govern, Map, Measure, Manage model, because the NIST AI RMF Core forces each risk to carry accountability, context, measurement and treatment.
- The register is not the same as an AI system inventory, risk assessment, data protection impact assessment or incident log; those records feed it.
- UK boards should connect the register to the ICO's AI and data protection guidance and the five UK AI principles confirmed in the government response to the pro-innovation AI regulation consultation.
- A useful register routes work: low-risk rows stay monitored, weak-control rows go to the owner, and board-level gaps become diagnostic or assurance actions.
Who should use this, and what it is not
Use this template when a board, audit committee, risk committee or executive owner needs a current view of AI exposure across the organisation. It is most useful once the organisation has at least a basic inventory of AI systems, including AI features embedded in existing software. The GOV.UK AI Playbook uses inventories, risk assessments and accountability records as part of public-sector AI assurance; private and voluntary-sector boards can use the same discipline even when the playbook is not binding on them.
The register should not replace more specific artefacts. It is the board-facing index that points to them.
| Artefact | What it answers | How it feeds the register |
|---|---|---|
| AI system inventory | What AI systems or AI-enabled features exist, who owns them and what data they touch. | Supplies the system name, owner, supplier and business process. |
| AI risk assessment | What could go wrong in a specific use case, before or after a material change. | Supplies the risk event, likelihood, impact and control options. |
| Data protection impact assessment | Whether processing personal data is likely to create high risk for people and what mitigations are required. The ICO's AI and data protection risk toolkit is built for that assessment. | Supplies privacy risks, lawful-basis questions, fairness issues and residual data protection risk. |
| Incident log | What actually happened, who was affected, what was contained and what changed afterwards. | Supplies trigger events, control failures and evidence that remediation closed. |
| Board AI risk register | Which AI risks remain live, who owns them, what evidence shows the control is working and what decision is needed. | Gives the board a current risk and action view across systems. |
This distinction matters because a register that tries to hold every detail becomes unreadable. A register that holds none of the detail becomes theatre. The right shape is a short board row with links to the evidence underneath.
AI risk register template: the board-ready fields
The template below is deliberately stricter than a generic corporate risk spreadsheet. AI risks move when the model changes, when the data changes, when staff use the tool differently, when a supplier switches on a feature, or when an incident exposes a control gap. The row therefore needs a place for evidence, cadence and trigger, not only likelihood and impact.
| Field | What to record | Board test |
|---|---|---|
| Register ID and system | A stable ID, the AI system or AI-enabled feature, supplier if relevant, and the linked inventory record. | Can we find the exact system and owner without asking around? |
| Business process | The decision, recommendation or output the AI supports. | Is this about a real workflow, not a model name? |
| Risk event | A concrete event: inaccurate advice sent, discriminatory ranking, confidential data disclosed, source fabrication accepted. | Would a person know what has happened if this risk occurs? |
| Affected people, data and process | The people, groups, records, services or financial process exposed to harm. | Does the row identify who bears the consequence? |
| Inherent risk and appetite | Severity before controls and the board's tolerance for this kind of risk. | Is this risk acceptable in principle, or only with controls? |
| Control | The policy, technical guardrail, human review, supplier clause or process gate that reduces the risk. | Can the owner show the control operating? |
| Evidence source | The dated artefact: test result, approval record, DPIA action, decision ledger, exception report, incident record or audit finding. | Is the evidence current, named and retrievable? |
| Control owner | One accountable person, with authority to act on exceptions. | Is the owner able to change the system, process or supplier term? |
| Residual risk | The remaining risk after controls, with rationale and date. | Does the rating follow from evidence, not sentiment? |
| Review cadence and trigger | Scheduled review interval plus event triggers: new system, model change, data change, supplier change, incident, regulatory update. | Would this row be reopened before the next board cycle if the risk moved? |
| Board decision or action | Accept, reduce, stop, escalate, commission assurance, or defer with a named next step. | Is there a decision, or only a note? |
The common failure is to fill the control column with "human review" and stop. That is not a control unless the row says who reviews, when review is mandatory, what they can change, where the review is logged and what happens when they disagree with the AI output. The evidence source is the discipline that exposes weak controls.
Owners, evidence and cadence
An AI risk row should not be owned by "technology", "data" or "the project team". Those are functions. The owner is the person accountable for keeping the risk within appetite and for acting when the evidence says it is not. The NIST AI RMF Playbook is useful here because it turns the framework into suggested actions, documentation questions and responsibilities rather than a static list of principles.
Evidence should be specific enough that an assurance reviewer can inspect it without reconstructing the whole project. Good evidence names the artefact and its date: DPIA approved on 18 June 2026, model-output sampling completed for the May release, supplier AI terms reviewed at renewal, 12 exception overrides recorded in the last month, or no high-severity incidents since the previous board pack. Weak evidence says "process in place" or "staff trained" with no date, owner or sample.
Cadence has two parts. The scheduled review sets the ordinary rhythm, often tied to the board, risk committee or management review cycle. The trigger list handles the faster movement: a new deployment, material model or prompt change, new category of personal data, supplier feature change, incident, near miss, complaint, audit finding or regulatory change. A row that waits for the next annual review after one of those triggers is no longer governing the current system.
This is where the template connects to the more conceptual point in our guide to making your AI risk register living evidence. The register should not be a meeting artefact created for governance; it should be the board view of evidence already being produced by controls.
Framework mapping: NIST, ISO 42001 and UK GDPR
A board does not need three separate registers for NIST, ISO 42001 and UK GDPR. It needs one register whose columns can answer each framework's questions. The NIST AI Risk Management Framework, NIST's AI RMF 1.0 publication page, the ICO's guidance and ISO/IEC 42001 use different language, but they all ask whether risk is identified, owned, controlled, evidenced and reviewed.
| Framework or regime | What it asks the register to show | Register fields that answer |
|---|---|---|
| NIST AI RMF | Govern assigns accountability, Map records context, Measure records how risk is assessed, Manage records treatment. | Owner, business process, risk event, evidence source, residual risk, action. |
| ISO/IEC 42001 | ISO describes the standard as requirements for establishing, implementing, maintaining and improving an AI management system. | System inventory link, policy hook, control, review cadence, assurance action. |
| UK GDPR and ICO guidance | Where AI uses personal data, organisations must identify data protection risks, assess effects on people and put mitigations in place. | Affected people and data, DPIA link, lawful-basis note, fairness risk, residual data protection risk. |
| UK AI regulation principles | The UK approach asks regulators to apply principles including safety, transparency, fairness, accountability and contestability. | Regulatory hook, control, evidence source, owner, board decision. |
| GOV.UK AI Playbook | Public-sector teams are asked to manage AI through accountable roles, risk assessment, assurance and documented controls. | Owner, evidence source, cadence, trigger, escalation route. |
The mapping also prevents a common board error: treating framework alignment as a separate project. If the register has to be rewritten to answer a NIST, ISO or ICO question, the register was not board-ready. A well-structured row should already tell the reader where the risk sits, which control applies, what evidence exists, and what remains unresolved. Our broader framework guide explains how this row fits into an AI governance framework for UK organisations, and our policy guide shows how the control column should connect back to what a UK AI policy includes.
Common mistakes, and the next step
The fastest way to improve an existing register is to remove rows that are not decision-ready. The common mistakes are easy to spot.
| Mistake | Why it fails | Fix |
|---|---|---|
| Listing tools instead of risk events | "Copilot risk" or "chatbot risk" does not say what can go wrong. | Write the event: confidential data disclosed, advice hallucinated, tenant triage misclassified. |
| Using the same amber rating for every row | It hides the difference between tolerated risk and unexamined risk. | Tie residual rating to evidence and risk appetite. |
| Treating a DPIA as the register | A DPIA answers data protection questions for a processing activity; it is not the board's whole AI risk view. | Link the DPIA into the row and keep commercial, operational and accountability risks visible. |
| Naming no decision | A board cannot govern a note. | End each row with accept, reduce, stop, escalate, assure or defer with a named owner. |
| Reviewing only by calendar | AI risk can move before the next annual review. | Add trigger-based review events and make the owner reopen the row when they occur. |
Start with the systems most likely to affect people, money, statutory duties or professional judgement. Fill the template for those first, then test each row with one question: if an auditor asked for proof tomorrow, could the owner produce it?
If you want a working starting point, use the AI risk register tool and then compare the output against your live evidence. If the harder question is whether the controls exist, the Board AI Scorecard gives a quick baseline, and the AI governance diagnostic turns the register into a paid assurance and implementation plan. For board-level support, see how we work.
Last reviewed: 18 June 2026.
Sources: NIST AI Risk Management Framework · NIST AI RMF Core · NIST AI RMF 1.0 publication page · NIST AI RMF Playbook · ICO AI and data protection guidance · ICO AI and data protection risk toolkit · GOV.UK AI Playbook · ISO/IEC 42001 · UK government response on AI regulation
