On this page
Build a living AI risk register by mapping each deployed system to a concrete harm, named owner, documented controls, retrievable evidence, and an event-driven review trigger. Start with these three fields before anything else:
- Use case + system ID: which AI system, what it does, and a stable identifier that never changes
- Risk event: the specific mechanism (e.g., hallucination, dataset shift, prompt injection) and the harm it causes to a named affected party
- Owner + residual risk + review trigger: a named individual accountable for the risk, the score after controls, and the condition that forces an immediate re-review
Every other field adds governance depth, but those three make the register operational on day one. Keep evidence links retrievable. Set periodic reviews as the default cadence, with event-driven triggers for model updates, incidents, and regulatory changes.
Pro Tip: Start with your highest-stakes AI systems and build a few complete rows before expanding the register. A sparse register with five auditable rows beats a 50-row spreadsheet where every “owner” cell says “AI Team.” Each row should include a named individual as risk owner, in line with audit requirements.
Key Takeaways
An auditable AI risk register requires named owners, dated evidence links, and event-driven review triggers mapped to the NIST AI RMF functions GOVERN, MAP, MEASURE, and MANAGE.
| Point | Details |
|---|---|
| Start with five complete rows | Build five fully populated rows for your highest-stakes systems before expanding; sparse but auditable beats wide but hollow. |
| Evidence must be dated and retrievable | Every control evidence link needs a date; a policy document title alone cannot validate a residual-risk claim during assurance review. |
| Named owners, not teams | Each row requires a named individual as risk owner; “AI Team” creates no accountability and fails basic audit scrutiny. Start with a few complete rows, each owned by a named individual, when building your register. |
| Score inherent and residual separately | Inherent score reflects pre-control exposure; conflating the two is the most common register error auditors flag. |
| Glitchive for evidence validation | Link verified Glitchive case studies in the “Related incidents” field to validate mechanisms, inherent ratings, and control choices with citable, permanent URLs. |
Table of Contents
- What is an AI risk register and why does it matter for governance?
- How register fields map to NIST AI RMF and ISO/IEC 23894
- What does a copy-ready AI risk register template look like?
- Illustrative register entry: a fully populated example row
- How do you identify and classify AI risks for the register?
- How do you score and prioritize risks in the register?
- How do you document controls, evidence, and review triggers?
- Who owns the register and how does it connect to ERM and board reporting?
- What tools and storage options work best for an AI risk register?
- How do you use verified failure cases to populate and validate register entries?
- The register is only as honest as the people filling it in
- Glitchive gives you verified evidence to populate your register faster
- Sources
- FAQ
What is an AI risk register and why does it matter for governance?
An AI risk register is a system-level artifact: each row records one identified risk for one AI system, along with its cause, affected parties, inherent rating, controls, evidence, residual rating, named owner, and review cadence. It is not a strategy document or a policy statement. Auditors, board members, and ERM teams use it to verify that specific risks are owned, controlled, and monitored.
The register feeds several governance processes at once. It provides the traceability an auditor needs to follow a risk from identification through control to residual exposure. It gives the board a concise view of which AI risks exceed appetite and what decisions are pending. It connects to enterprise risk management by translating AI-specific exposures into the language of likelihood, impact, and treatment that ERM frameworks already use.
Two international standards anchor the design. The NIST AI Risk Management Framework (AI RMF) organizes AI risk management into four functions: GOVERN, MAP, MEASURE, and MANAGE. ISO/IEC 23894:2023 provides guidance for integrating AI-specific risk management into organizational processes, mapping closely to ISO 31000 concepts. Both treat the register as a living artifact, not a one-time compliance exercise. Glitchive’s repository of verified AI failure cases provides the real-world evidence that populates register rows with credible mechanisms and control gaps.
A register without evidence links is a wish list. The moment an auditor asks “how do you know this control is working?” the answer must be a URL, a log reference, or a dated sampling record — not a policy document title.
How register fields map to NIST AI RMF and ISO/IEC 23894
The NIST AI RMF 1.0 treats its four functions as a living, non-checklist resource. Profiles let teams tailor which fields, metrics, and cadence apply to their specific context and risk tolerance. That tailoring logic maps directly onto register design.
| Register field | NIST AI RMF function | ISO/IEC 23894 clause area |
|---|---|---|
| System inventory link, use case, affected parties | MAP | Context, scope, stakeholder identification |
| Inherent likelihood, inherent impact, risk event mechanism | MAP / MEASURE | Risk identification, risk analysis |
| Controls (IDs), control evidence links | MEASURE / MANAGE | Risk treatment, monitoring |
| Residual likelihood, residual impact, residual score | MEASURE | Risk evaluation, recording |
| Named owner, review cadence, board action | GOVERN | Leadership, accountability, continual improvement |
| Review triggers, related incidents | MANAGE | Monitoring, review, communication |
GOVERN covers the accountability structure: who owns the risk, who owns the control, and what the board has decided. MAP is where the system inventory and risk identification live. MEASURE is where scoring and evidence validation happen. MANAGE is where treatment decisions, monitoring, and event-driven reviews are recorded.
ISO/IEC 23894:2023 applies to organizations that develop, produce, deploy, or use AI and recommends customization to organizational context, which aligns with the NIST Profiles concept. A published NIST crosswalk document maps AI RMF functions to ISO/IEC 23894 clauses directly, making it straightforward to demonstrate dual-framework alignment to auditors without maintaining two separate registers.
The Profiles concept deserves a practical note. A team running a low-stakes internal scheduling tool and a team running a credit-decisioning model should not use the same cadence or the same evidence thresholds. Profiles let you document those differences formally, so the register itself explains why a quarterly review is sufficient for one system and a monthly review is required for another.
What does a copy-ready AI risk register template look like?
The table below defines the minimal column set for an auditable register. Copy it into a spreadsheet or GRC tool and add columns only when a governance requirement demands them.
| Column | Definition | Audit-ready format |
|---|---|---|
| Risk ID | Stable, sequential identifier (never reused) | AIR-007 |
| System / Inventory link | AI system name + URL to system inventory record | Loan Scoring Model v3 / [link] |
| Risk event | Mechanism + harm in one sentence | Model drift causes biased credit denials for minority applicants |
| Affected parties / data | Who or what is harmed; data types involved | Loan applicants; personal financial data |
| Cause / source | Root technical or process cause | Training data underrepresents recent applicant demographics |
| Inherent likelihood | 1–5 score before controls; include rationale | 4 — model retrained infrequently; drift observed in prior quarter |
| Inherent impact | 1–5 score; include harm category | 5 — regulatory breach, financial harm to applicants |
| Inherent score | Likelihood × Impact | 16 |
| Controls (IDs) | Comma-separated IDs from control catalog | CTL-008, CTL-019, CTL-033 |
| Control evidence link(s) | Dated, retrievable URLs or log references | [Drift monitoring dashboard, sampled March 2025] |
| Residual likelihood | 1–5 after controls; rationale required | 2 — monthly drift checks now in place |
| Residual impact | 1–5 after controls | 5 — harm category unchanged |
| Residual score | Residual likelihood × Residual impact | 10 |
| Owner | Named individual (not a team) | Jane Smith, Chief Risk Officer |
| Review cadence + triggers | Default cadence + event conditions | Quarterly; trigger: model retrain, regulatory change, incident |
| Related incidents | Links to incident records or external cases | [Glitchive case URL] |
| Board action / decision | Accept, reduce, stop, escalate, or commission assurance | Reduce — additional monitoring commissioned Q2 2026 |
Three things make each field audit-ready:
- Stable IDs: Risk IDs and control IDs must never be reused or renumbered. Auditors trace findings across review cycles using these identifiers.
- Dated evidence: Every control evidence link must carry a date. A policy document with no retrieval date cannot validate a residual-risk claim.
- Named owners: “AI Team” or “Compliance” is not an owner. A named individual with a title creates accountability and a clear escalation path.
Pro Tip: Map each Control ID in the register to a row in a separate control catalog that describes the control, its type (preventive, detective, corrective), and its test frequency. The register then references the catalog; auditors can pull both documents and verify the chain.
Illustrative register entry: a fully populated example row
The entry below is fictional and illustrative only. It does not represent a real incident, organization, or system.
How the scoring works: Inherent score = 4 × 4 = 16. After implementing CTL-008, CTL-019, and CTL-033, residual likelihood drops to 2 while impact stays at 4, giving a residual score of 8. That score sits in the “medium” band (see Section 7), which triggers a management-level review rather than immediate board escalation.
NIST function mapping for this row:
- MAP: system inventory link, risk event, affected parties, cause
- MEASURE: inherent and residual scores, control evidence links
- MANAGE: board action, review triggers, related incident link
- GOVERN: named owner, review cadence, board decision field
The “Related incidents” field links to a Glitchive case study documenting a real-world analogue: a support chatbot that invented a refund policy and resulted in the airline being held liable. That case provides the mechanism, contributing factors, and remediation steps that validate the inherent rating and the choice of controls.
How do you identify and classify AI risks for the register?
Discovery is where most registers stall. Teams either cast the net too wide (every conceivable harm) or too narrow (only the risks they already know about). A structured set of inputs and techniques keeps the scope manageable and defensible.
Discovery inputs to work through systematically:
- System inventory: every AI system in production or active development, including third-party models accessed via API
- Data flow maps: where training data originates, how inference inputs arrive, where outputs go and who acts on them
- Incident logs: past failures, near-misses, and customer complaints that point to live risk mechanisms
- Vendor change notices: model version updates, deprecation notices, and API changes from third-party providers
- DPIA outputs: Data Protection Impact Assessments often surface privacy and fairness risks that belong in the register
- External failure repositories: the MIT AI Risk Initiative and Glitchive both publish verified failure scenarios that help teams identify mechanisms they have not yet encountered internally
Techniques for surfacing register rows:
- Threat modeling: walk each system’s data flow and ask “what could go wrong at this step?” for each node. STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) adapts reasonably well to AI pipelines.
- Red-team prompting: for LLM-based systems, structured adversarial prompting surfaces hallucination, prompt injection, and jailbreak risks before they appear in production.
- Model-change trigger reviews: every time a model is retrained or updated, run a delta risk assessment to identify new or changed risks.
- Stakeholder interviews: product managers, customer-facing staff, and legal counsel often know about harms that engineering teams have not formally documented.
- Supplier questionnaires: for third-party AI components, ask vendors directly about known failure modes, incident history, and model change processes.
For taxonomy, use consistent labels across the register. Six categories cover most AI risks: privacy, fairness, safety, security, financial, and reputational. A risk can carry more than one category label, but every row must have at least one. Consistent labels make it possible to filter the register by category for board reporting and regulatory submissions.
How do you score and prioritize risks in the register?
A 1–5 likelihood scale and a 1–5 impact scale give enough granularity to differentiate risks without false precision. The product of the two scores (1–25) maps to three priority bands.
Likelihood scale:
- Rare: no known occurrence in similar systems; theoretical
- Unlikely: occurred in external cases but not in this system type
- Possible: has occurred in comparable deployments; plausible given current controls
- Likely: observed in pre-deployment testing or in prior incidents
- Almost certain: occurring now or expected without intervention
Impact scale:
- Negligible: no material harm; easily corrected
- Minor: limited harm to a small group; recoverable
- Moderate: measurable harm; regulatory notice possible
- Major: significant harm to a defined population; regulatory breach likely
- Severe: irreversible harm, systemic failure, or material legal liability
Priority bands and remediation SLAs:
| Score range | Priority band | Default SLA |
|---|---|---|
| 16 | Critical | Immediate escalation; board notification within 5 business days |
| 8 | High | Management review within 30 days; treatment plan within 30 days |
| 8 | Medium | Quarterly review; treatment plan within 30 days |
| 1–4 | Low | Annual review; accept or monitor |
Worked example using the illustrative entry from Section 5: Inherent likelihood 4 × inherent impact 4 = 16 (High). After controls, residual likelihood 2 × residual impact 4 = 8 (Medium). The risk moves from a 30-day management review to a quarterly review cycle, but the impact score of 4 means the board action field still requires an explicit decision rather than a passive “monitor.”
Pro Tip: Never let a high inherent score disappear behind a low residual score without documenting why the controls are effective. Auditors will ask. If the only evidence is a policy document, the residual score is not credible.
How do you document controls, evidence, and review triggers?
Controls fall into three categories, and the register should record all three types where they apply:
- Preventive: stop the harm before it occurs (input validation, RAG grounding, access controls, training data governance)
- Detective: identify when the harm is occurring (drift monitoring, output sampling, anomaly detection, audit logging)
- Corrective: limit or reverse harm after it occurs (human escalation paths, rollback procedures, customer notification workflows)
Each control ID in the register maps to a row in a control catalog. The catalog entry describes the control, its type, its test frequency, and who is responsible for testing it. The register links to the catalog; the catalog links to evidence. That two-document structure keeps the register readable while making the full evidence chain available to auditors.
Evidence sources by control type:
- Policy documents: acceptable as supporting context, not as standalone evidence of effectiveness
- Runtime policy engine logs: dated, retrievable, and directly tied to control operation
- Audit logs: timestamped records of system decisions and human overrides
- Sampling records: documented spot-checks of model outputs with dates, sample sizes, and findings
- Human-review records: escalation logs showing volume, disposition, and reviewer identity
Runbook for residual risk above appetite:
- Flag the row in the register with a “Residual exceeds appetite” status
- Notify the named owner within 24 hours
- Owner documents a temporary mitigation within 5 business days
- Risk committee reviews within 30 days and records a formal decision (accept with justification, reduce further, or stop the system)
- Board liaison notifies the board risk committee if the residual score is 10 or above after temporary mitigation
- Update the register row with the decision, date, and any new control IDs
Pro Tip: Set review triggers as explicit conditions beyond just periodic dates to keep the register current between scheduled reviews.
Who owns the register and how does it connect to ERM and board reporting?
Ownership without accountability is just a name in a cell. Each register row needs four distinct roles:
- Risk owner: the named individual accountable for the risk existing and being managed; typically a business-line leader, not an IT role
- Control owner: the individual responsible for operating and evidencing each control; may differ from the risk owner
- Assurance owner: the internal audit or second-line function that independently validates control effectiveness
- Executive sponsor / board liaison: the C-suite or board-level individual who receives escalations and signs off on accept/stop decisions
Review cadence by audience:
| Artifact | Audience | Frequency | Content |
|---|---|---|---|
| Full register | Risk committee | Quarterly | All rows, all fields, evidence status |
| Risk summary | Executive team | Monthly | High and critical rows only; treatment status |
| Board risk report | Board / Audit committee | Quarterly | Critical rows; board action decisions; residual vs. appetite |
| Audit evidence package | Internal / external audit | On request | Full row + control catalog entries + evidence links |
Auditors will follow a specific chain: register row → control ID → control catalog entry → evidence link → dated artifact. If any link in that chain is broken or undated, the residual-risk claim fails. Prepare for this by running a quarterly internal audit of the evidence links before the formal audit cycle begins.
ISO 42001 specifies requirements for an AI Management System (AIMS), including continual improvement processes that map naturally onto the register’s review cadence and board action field. Organizations pursuing ISO 42001 certification can use the register as a primary artifact for demonstrating risk management compliance.
For ERM integration, translate each AI risk row into the organization’s standard risk taxonomy before the quarterly ERM submission. The register’s likelihood × impact scores map directly to most ERM heat maps. The board action field maps to the ERM treatment category.
What tools and storage options work best for an AI risk register?
The right storage option depends on the number of AI systems, the maturity of the governance program, and the audit requirements. Three tiers cover most organizations:
Spreadsheet (Google Sheets, Microsoft Excel):
- Low friction to start; no procurement required
- Versioning is manual and error-prone without strict naming conventions
- Evidence links can be added as hyperlinks but are not validated automatically
- Access controls are coarse; sharing a spreadsheet with an auditor often means sharing the whole file
- Best for: teams with fewer than 10 AI systems and a governance program in its first year
Database or GRC platform (ServiceNow GRC, Archer, LogicGate):
- Immutable audit trail built in; row-level change history is automatic
- Role-based access controls allow auditors to view without editing
- Workflow automation can trigger review notifications and escalation alerts
- Evidence links can be validated on ingestion
- Best for: organizations with 10+ AI systems or existing GRC infrastructure
Specialist AI risk modules (Kovrr and similar vendors):
- Purpose-built for AI risk with pre-mapped NIST and ISO fields
- Automated evidence ingestion from monitoring tools is possible
- Vendor lock-in is a real constraint; data portability should be a procurement requirement
- Best for: organizations that want pre-built framework alignment and are willing to accept vendor dependency
Minimum controls for any storage option:
- Immutable audit trail: every change to a row must be logged with a timestamp and user identity
- Role-based access: risk owners edit their rows; auditors have read-only access; no anonymous editing
- Backup and versioning: at minimum, a dated export at each review cycle stored in a separate location
- Evidence link validation: at least quarterly, check that every evidence URL resolves and the linked artifact is current
Migrating from a spreadsheet to a GRC tool: export the spreadsheet to CSV, map columns to the GRC tool’s field schema, import, and then run a full evidence-link audit before decommissioning the spreadsheet. Do not run both in parallel for more than one review cycle.
How do you use verified failure cases to populate and validate register entries?
External failure cases are the fastest way to validate that your inherent ratings and control choices are realistic. The MIT AI Risk Initiative and Glitchive both publish verified scenarios with mechanisms, contributing factors, and remediation steps. MIT researchers released a dedicated AI risk repository in 2024, expanding the pool of citable external evidence available to risk managers.
Workflow for using an external case:
- Locate a case relevant to a system or risk category in your register (search by mechanism: hallucination, drift, prompt injection, access control failure)
- Extract the mechanism, contributing factors, and remediation steps from the case record
- Link the case URL, publication date, and public source in the “Related incidents” field of the matching register row
- Compare the case’s contributing factors to your current controls; if a factor is unaddressed, add a control gap finding
- Update the inherent likelihood if the case demonstrates the mechanism is more common than your current rating assumes
- Set a review trigger: if the case involves a model type or deployment pattern you use, flag the row for an out-of-cycle review
What to record from an external case:
- URL and publication date (for traceability)
- Mechanism in one sentence (e.g., “LLM hallucinated policy terms not present in grounding documents”)
- Contributing factors (e.g., “no retrieval-augmented grounding; no output confidence threshold”)
- Remediation steps applied in the case (e.g., “RAG layer added; human escalation path implemented”)
- Label: “External case — illustrative analogue” to distinguish it from a first-party incident
External cases change inherent ratings, not residual ratings. If a verified case shows your mechanism is more prevalent than assumed, raise the inherent likelihood score and re-evaluate whether your controls are sufficient. Do not lower the inherent score because you have controls in place — that conflates inherent and residual risk, which is one of the most common register errors auditors flag.
Glitchive cases carry permanent, citable URLs and fully sourced references, which satisfies the “dated, retrievable” evidence standard that board-ready registers require. The coding agent case documenting a production database wipe during an active code freeze, for example, provides the mechanism and remediation detail needed to populate an operational risk row for any organization running autonomous coding agents.
The register is only as honest as the people filling it in
Most AI risk registers fail for the same reason most compliance artifacts fail: they are built for the audit, not for the team. The fields get filled with plausible-sounding text, the owner column gets a department name, and the evidence links point to a policy PDF that nobody has read since it was drafted. Six months later, the register is stale, the risks have changed, and the document is a liability rather than a governance asset.
The approach in this article is deliberately uncomfortable in one respect: it requires named individuals to own rows and to produce dated, retrievable evidence that their controls are working. That is harder than writing “human review in place.” It is also the only version of a register that survives an audit or a board question.
The NIST AI RMF’s insistence that the framework is a living, non-checklist resource is not boilerplate. It is a direct warning against the static register. Event-driven triggers, quarterly evidence refreshes, and the discipline of linking external failure cases to register rows are what keep the document honest. Glitchive exists precisely to make that last step easier: verified cases with permanent URLs give risk managers citable evidence that does not require inventing scenarios or relying on internal anecdote.
One thing the standards do not say loudly enough: the board action field is the most important column in the register. A row without an explicit decision — accept, reduce, stop, escalate, or commission assurance — is a row where nobody has actually decided anything. That is where most AI governance programs quietly break down.
Glitchive gives you verified evidence to populate your register faster
Building an AI risk register from scratch means finding credible evidence for every mechanism you document. That search usually ends with generic threat lists or invented scenarios that auditors will question.
Glitchive’s searchable case library gives you verified, fully sourced AI failure cases with permanent URLs you can link directly into your register’s “Related incidents” field. Each case documents the mechanism, contributing factors, and the specific remediation applied, so you get the evidence chain an auditor expects without fabricating scenarios. Browse the Glitchive case repository to find cases relevant to your systems and start populating register rows with citable, dated evidence today.
Sources
The sources below are the primary references for register design, framework alignment, and evidence gathering.
- AI RMF - AIRC (NIST)
- Artificial Intelligence Risk Management Framework (AI RMF 1.0) — NIST
- ISO/IEC 23894:2023 - AI — Guidance on risk management
- AI risk register template for boards | Governance AI
- MIT AI Risk Initiative
FAQ
What is an AI risk register?
An AI risk register is a system-level document where each row records one identified risk for one AI system, including its mechanism, affected parties, likelihood and impact scores, controls, evidence links, named owner, and review cadence. It is an operational governance artifact, not a policy statement.
How many fields does a minimal AI risk register need?
A minimal auditable row requires a stable risk ID, system inventory link, risk event description, inherent and residual likelihood and impact scores, control IDs with evidence links, a named owner, and a review trigger. The board action field is also required for any row reviewed at board level.
How does an AI risk register align with the NIST AI RMF?
The four NIST AI RMF functions map directly to register fields: GOVERN covers ownership and board decisions, MAP covers system inventory and risk identification, MEASURE covers scoring and evidence, and MANAGE covers treatment, monitoring, and event-driven reviews. The NIST AI RMF Profiles mechanism lets teams tailor which fields and cadence apply to each system’s risk tolerance.
How often should you review and update the register?
Quarterly is the standard default cadence, with event-driven reviews triggered by model retraining, new incidents, regulatory changes, or vendor model updates. A row should never go more than several months without a review regardless of its priority band.
How do you use external failure cases to improve the register?
Locate a verified case matching your system’s mechanism, extract the contributing factors and remediation steps, link the case URL in the “Related incidents” field, and update the inherent likelihood if the case shows the mechanism is more prevalent than your current rating assumes. Glitchive cases carry permanent, citable URLs that satisfy the dated, retrievable evidence standard auditors expect.