AI Risk Register Template: How to Build and Maintain Your AI Risk Register
A dynamic, documented log that tracks identified vulnerabilities, their scores, treatment plans, and ownership across the full AI lifecycle
An AI Risk Register is not a static spreadsheet you fill in once and forget. It is a dynamic, documented log used throughout the AI lifecycle to track identified vulnerabilities, their severity scores, treatment plans, and named ownership. Without one, your organization is flying blind on AI risk.
This guide walks you through the 15 required fields every register needs, the 5×5 scoring methodology that drives risk-informed decisions, how the register evolves across lifecycle stages, and three worked examples at different risk levels. If you are building an AI governance program, the risk register is one of your first operational artifacts.
Every field, threshold, and treatment option in this guide traces back to ISO 42001 (Cl. 6.1, 8.2, 8.4), NIST AI RMF (MAP, MEASURE, MANAGE functions), and the EU AI Act (Art. 9 risk management). For the full assessment methodology that feeds this register, see our AI Risk Assessment Guide.
15 Required Fields Per AI System
Every AI system in your inventory needs these fields documented. Missing even one creates a blind spot that auditors and regulators will find before you do.
Risk ID
Unique identifier for each risk entry. Use a consistent naming convention (e.g., RISK-HR-001).
Risk Category
Bias, security, privacy, robustness, legal, transparency, or third-party. Multiple categories allowed.
Risk Description
Clear, specific statement of what could go wrong and why it matters. Avoid vague language.
Impact Score (1-5)
Severity of consequences if the risk materializes. 1 = negligible, 5 = catastrophic.
Likelihood Score (1-5)
Probability the risk will occur. 1 = rare, 5 = almost certain.
Total Calculated Score
Likelihood × Impact = Score (1-25). This is the number that drives your risk tier assignment.
Risk Level
Low (1-6), Medium (7-12), High (13-18), or Critical (19-25). Determines governance controls applied.
Mitigation Plan
Specific actions to reduce likelihood or impact. Include timelines, resources, and success criteria.
Risk Treatment
Mitigate, Transfer, Avoid, Accept, or Supersede/Disengage. Each carries different documentation requirements.
Owner
Named individual (not a team). If no one owns it, no one manages it. RACI alignment required.
Status
Open, In Treatment, Mitigated, Accepted, or Closed. Drives dashboard reporting and review triggers.
Review Date
Next scheduled review. High/Critical risks: monthly. Medium: quarterly. Low: semi-annually.
Last Assessment Date
When the risk was last formally evaluated. Stale dates trigger automatic review escalation.
Residual Risk Score
Risk score after treatment is applied. The gap between total and residual shows treatment effectiveness.
5×5 Risk Scoring Methodology
Likelihood (1-5) × Impact (1-5) = Score (1-25). Four tolerance thresholds determine governance controls. For the full assessment methodology, see our AI Risk Assessment Guide.
| Impact ↓ / Likelihood → | 1 - Rare | 2 - Unlikely | 3 - Possible | 4 - Likely | 5 - Almost Certain |
|---|---|---|---|---|---|
| 5 - Catastrophic | 5 | 10 | 15 | 20 | 25 |
| 4 - Major | 4 | 8 | 12 | 16 | 20 |
| 3 - Moderate | 3 | 6 | 9 | 12 | 15 |
| 2 - Minor | 2 | 4 | 6 | 8 | 10 |
| 1 - Negligible | 1 | 2 | 3 | 4 | 5 |
Low: Accept with monitoring. Medium: Mitigation plan required. High: Executive review and active treatment. Critical: Immediate escalation, possible deployment halt. Each threshold triggers different governance controls, review cadences, and approval requirements per committee implementation Stage 4.
Lifecycle Traceability: When the Register Gets Updated
Your risk register is not a point-in-time document. It evolves with each stage of the AI lifecycle. Here is when and how it changes.
Ideation Stage 1
Register initiated with preliminary severity rankings. Identify broad risk categories based on the use case proposal. Flag potential regulatory triggers (EU AI Act risk tier, sector-specific requirements). This is the first tollgate artifact.
Development Stage 2
Updated with specific, measurable mitigations. Data bias risks documented with proposed remediation (e.g., resampling, additional training data). Security controls mapped to identified attack surfaces. Each risk gets a named owner from the development team.
Validation Stage 3
Finalized with residual risk acceptances. Testing results feed back into likelihood and impact scores. Risks that testing could not reduce below threshold require formal acceptance sign-off from the risk owner and committee.
Deployment Stage 4
Continuously updated with new operational risks discovered in production. Real-world data often reveals risks that testing environments missed. Integration risks, user behavior patterns, and performance degradation all create new register entries.
Monitoring Stage 5
New risks added from incidents, model drift, data drift, or regulatory changes. EU AI Act Art. 72 requires ongoing post-market monitoring for high-risk systems. Incident reports trigger immediate register updates and re-scoring.
Retirement Stage 6
Risks marked as retired or transferred to replacement systems. Data retention risks may persist beyond system shutdown. Document lessons learned and feed them into the risk library for future assessments.
5 Risk Treatment Options
Every risk in your register requires a documented treatment decision. The choice depends on risk tolerance, cost-benefit analysis, and regulatory requirements.
Mitigate
Reduce likelihood or impact through controls, testing, or design changes. Most common treatment for Medium and High risks.
Transfer
Shift risk via indemnification clauses, insurance, or third-party agreements. Common for vendor-supplied AI systems.
Avoid
Modify the plan or halt deployment entirely. Required when risk exceeds organizational tolerance or regulatory limits.
Accept
Document residual risk without further action. Requires formal sign-off and documented justification. Monitor for changes.
Supersede / Disengage
Turn off systems with inconsistent performance. Replace with alternative that meets risk thresholds.
Worked Examples: 3 AI Systems at Different Risk Levels
See what completed register entries look like across the risk spectrum. Each example shows the full field set and the governance response triggered by the risk score.
Internal HR Chatbot
Customer Credit Scoring Model
Quarterly bias audit, disparate impact testing, EU AI Act Art. 9 conformity assessment, explainability documentation
Autonomous Hiring Screening
Immediate executive review. Deployment halted pending EU AI Act Art. 5 prohibited practices screening and full human oversight implementation per Art. 14.
Integration with Committee Review
Your risk register does not exist in isolation. It feeds directly into your governance committee's decision-making process at multiple touchpoints.
How the Register Connects to Committee Stage 4
- Decision Tollgate Artifact: The risk register is a required document at every go/no-go tollgate. No register entry, no progression through the lifecycle pipeline.
- Quarterly Review Cadence: The committee reviews the full register quarterly, or on incident trigger. High and Critical risks get individual attention at each review cycle.
- Escalation Trigger: Any risk scored Critical (19-25) triggers immediate committee notification. The committee chair has authority to halt deployment pending review.
- Residual Risk Acceptance: Only the committee (or designated executive sponsor) can formally accept residual risk above Medium threshold. This is not a team lead decision.
- Board Reporting: Aggregated register data feeds the quarterly Board Summary Template, giving executives a risk posture snapshot without operational detail.
See how the risk register integrates with the full 8-stage committee framework, including tollgate requirements and the 120-day implementation timeline.
Templates and Tools for Your Risk Register
Build and operationalize your register with these downloadable templates. Each is pre-aligned to ISO 42001, NIST AI RMF, and EU AI Act requirements.
40-Field AI Use Case Tracker
The system inventory that feeds your risk register. Track every AI system with 40 governance fields including risk tier, data classification, and owner.
Download Tracker →Regulatory Mapping Cheat Sheet
Map your register fields to ISO 42001, NIST AI RMF, and EU AI Act requirements. Shows which framework clause each field satisfies.
Download Mapping →Board Summary Template
Translate register data into executive-ready reporting. Aggregated risk posture, treatment status, and trend analysis for quarterly board reviews.
Download Template →