Practical checklist
AI Risk Register Template: Risks, Controls, Owners, and Evidence
An AI risk register is a decision record for material AI risk scenarios. It connects a defined system and use case to causes, events, consequences, affected stakeholders, inherent exposure, controls, control evidence, residual exposure, treatment, accountable ownership, acceptance authority, monitoring, and review triggers.
Direct answer
A risk register should preserve reasoning, not just scores
An AI risk register turns assessment findings into managed exposure. Each entry should describe a plausible scenario in context, show why it matters, identify the controls that change the exposure, and record what management decided. Labels such as bias, privacy, or hallucination are themes, not complete risk statements.
A broader AI risk assessment tests how this practice fits the organization's wider ownership, control, and evidence baseline.
This page focuses on the register structure and operating workflow. The AI risk assessment pillar covers the broader assessment discipline, while the scoring-framework guide addresses calibration. Keeping those purposes distinct reduces the common error of treating a register template as the assessment itself.
Risk statement
Begin with a scenario a decision-maker can recognise
A useful scenario separates cause, event, and consequence. It names the AI system and use case, affected people or processes, time horizon, and relevant dependency. “Model bias” is too broad. “Training and validation data under-represent a customer group, causing the eligibility model to produce systematically less accurate recommendations for that group and exposing customers to unfair outcomes and the organisation to remediation and regulatory action” is assessable.
Abbreviated completed risk-register example
| Field | Example entry |
|---|---|
| Cause | Approved policy content in the retrieval index is not updated after a customer-remedy change |
| Event | The assistant generates an obsolete remedy and the service agent sends it without verification |
| Consequence | Customers receive inconsistent treatment, complaints rise, and retrospective correction is required |
| Controls | Controlled source ownership, release reconciliation, mandatory agent confirmation, monthly output sampling, and incident escalation |
| Evidence | Source approval log, reconciliation result, workflow confirmation records, May sample of 200 responses, and complaint analysis |
| Residual risk | Medium: error frequency is reduced, but agent bypass and delayed source updates remain plausible |
| Decision | Conditional acceptance by the Customer Operations risk owner for 90 days, subject to workflow enforcement and successful retesting |
The entry is concise, but the relationship between evidence, residual exposure, conditions, and decision remains inspectable.
For use-case-specific scenario discovery, use the generative AI risk assessment guide before attempting to populate scores or treatments.
Template anatomy
Record the chain from exposure to decision
Core fields and the management question they answer
| Field group | What to record | Management question |
|---|---|---|
| Identity and context | Risk ID, system, use case, purpose, owner, affected stakeholders, lifecycle state | What exactly is exposed and who answers for it? |
| Scenario | Cause, event, consequence, time horizon, dependency, source evidence | What could happen, why, and to whom? |
| Inherent exposure | Impact, likelihood, uncertainty, assumptions, confidence, rating rationale | How serious is the scenario before relevant controls? |
| Controls | Control IDs, owners, design status, test results, limitations, dependencies | Which safeguards actually change the scenario? |
| Residual decision | Residual rating, appetite position, treatment, acceptance authority, conditions | What exposure remains and who approved it? |
| Monitoring and change | KRI, incidents, action status, next review, trigger events, history | What would cause management to intervene or reassess? |
The register may link to detailed assessments and control records rather than duplicating them, but the decision chain must remain readable from the entry.
Do not collapse risk, issue, and exception into one status
| Record | Meaning | Typical response |
|---|---|---|
| Risk | A possible future event or condition with uncertain consequence | Assess, control, accept, transfer, avoid, and monitor |
| Issue or incident | A problem or event that has occurred or currently exists | Contain, investigate, correct, learn, and reassess related risks |
| Control deficiency | A safeguard is absent, poorly designed, or not operating | Remediate, apply interim measures, retest, and reconsider reliance |
| Exception | An approved temporary departure from a requirement or control | Set authority, rationale, conditions, expiry, monitoring, and closure |
Link related records. Converting every issue into a risk entry makes both the incident history and forward-looking exposure harder to understand.
Use ratings to support a decision, not to manufacture precision. Anchored bands should explain what impact and likelihood mean for people, operations, security, legal exposure, finance, and reputation. Record the time horizon, reversibility, scale, confidence, and information gaps separately. Where one severe consequence could be hidden by an average, preserve the dimension or apply an approved override rather than letting arithmetic erase it.
Confidence and uncertainty answer different questions
| Concept | Practical question | Example |
|---|---|---|
| Confidence | How strongly does the available evidence support the current assessment? | High confidence in observed error frequency because a representative production sample was independently reviewed |
| Uncertainty | Which unknown conditions could materially change the exposure or decision? | The supplier has not disclosed whether the next model version changes retrieval behaviour, so future performance remains uncertain |
A rating can have strong evidence for current conditions and still carry material uncertainty about change. Record both instead of adjusting the score informally.
Risk reasoning
Only verified controls should reduce the residual view
Inherent risk describes exposure before considering the controls selected for the scenario. Residual risk describes the exposure after considering how those controls are designed and evidenced. A planned control, a policy statement, or an untested configuration should not receive the same credit as a control that is implemented for the full population and has produced reliable operating evidence.
Residual-risk decisions
| Residual exposure | Required action | Typical owner |
|---|---|---|
| Within appetite with reliable control evidence | Approve continued operation, define monitoring and change triggers, and retain the decision basis | Business risk owner within delegated authority |
| Near appetite or dependent on conditions | Use time-bound conditional acceptance, interim safeguards, named remediation, and a mandatory review date | Senior business owner with risk or governance challenge |
| Outside appetite or supported by unreliable evidence | Restrict, redesign, suspend, avoid, or escalate before continued operation | Executive risk authority or designated governance committee |
The organisation's approved appetite and delegation rules determine the decision. A numerical score alone should not grant acceptance authority.
Control definitions should come from the AI control library, while operating-effectiveness results should be linked from control testing rather than rewritten in the risk entry.
Execution
Make acceptance and review explicit
Workflow for a decision-ready risk entry
- 01
Confirm the governed object
Link the scenario to a validated system, use case, purpose, owner, and lifecycle state.
- 02
Write and evidence the scenario
Separate cause, event, and consequence; cite incidents, evaluations, data, supplier facts, or expert analysis.
- 03
Assess inherent exposure
Record impact, likelihood, uncertainty, assumptions, confidence, aggregation, and rating rationale.
- 04
Evaluate relevant controls
Link control design, implementation, test results, limitations, exceptions, and dependencies.
- 05
Decide treatment and residual exposure
Assign actions, interim safeguards, resources, due dates, residual rating, and acceptance authority.
- 06
Monitor and reopen
Define KRIs, incident links, review date, trigger events, action status, and evidence required for closure.
A completed entry ends in an authorised decision with review conditions—not merely a filled row.
Accept residual exposure only when the accountable authority can identify the evidence considered, applicable appetite, control limitations, monitoring conditions, decision period, and resources committed to treatment. Conditional acceptance needs an expiry date and a consequence if the condition is not met; silence after the deadline is not renewed acceptance.
Reassess when purpose, users, affected stakeholders, model, data, supplier, integration, autonomy, scale, operating environment, or control performance changes materially. An incident, threshold breach, failed control test, new dependency, material evidence gap, or movement outside appetite should return the entry to decision status before the normal review date.
Portfolio reporting should preserve scenario detail while showing concentration and aggregation. Ten moderate entries may create high enterprise exposure when they depend on one provider, one dataset, one control, or one business process. Report accepted exposure, overdue treatment, weak evidence, and correlated dependency separately from raw counts.
Risk acceptance should identify the authority, information considered, conditions, duration, monitoring, and circumstances that force escalation. Acceptance is not permanent permission for the system. If an incident occurs, a control test fails, a supplier changes the service, or exposure moves outside appetite, the entry should return to decision status. This history lets management distinguish deliberate acceptance from risk that was simply left unresolved.
Treatment actions should describe the changed condition management expects to see. “Improve monitoring” is not executable; “sample 50 decisions each month, report error and override rates by affected group, investigate threshold breaches within five business days, and retain reviewed results” gives owners and reviewers something they can verify. Keep detailed project plans outside the register, but link the milestone, dependency, interim safeguard, and completion evidence needed for the risk decision.
When ratings are inconsistent across teams, move next to the AI risk scoring framework. When treatment repeatedly stalls, the governance assessment should examine decision rights and escalation rather than adding more register fields.
FAQ
Frequently asked questions
What columns should an AI risk register contain?
Include identity and context, a cause-event-consequence scenario, affected stakeholders, evidence sources, inherent impact and likelihood, uncertainty and confidence, control links and test results, residual exposure, treatment, owner, acceptance authority, monitoring, review date, and change history.
What is the difference between inherent and residual AI risk?
Inherent risk is the exposure before considering selected controls. Residual risk is the exposure after considering controls supported by design and operating evidence. Planned or untested controls should receive limited or no credit.
Should a risk register contain incidents and issues?
Link them, but keep their meanings distinct. Risks are uncertain future scenarios; incidents and issues have occurred or currently exist. Incidents can change likelihood, impact, confidence, control reliance, and treatment for related risks.
Who owns an AI risk entry?
A business risk owner with authority over the use case and resources should own the exposure and treatment. Specialists contribute analysis and challenge; control owners operate safeguards; the designated acceptance authority approves residual exposure.
How should AI risks be scored?
Score a defined scenario using anchored impact and likelihood criteria, then record uncertainty, confidence, assumptions, control evidence, and any override. The rationale matters more than mathematical precision.
When should an AI risk be reassessed?
Reassess after material changes to purpose, model, data, users, autonomy, supplier, integration, controls, incidents, environment, or affected stakeholders, as well as on the approved periodic cycle.
When can a risk entry be closed?
Close it only when the scenario no longer applies, the system is retired, or treatment and evidence justify closure under the organisation's criteria. Preserve the decision, evidence, owner, date, and links to replacement risks or issues.