AI Risk Assessment Framework and Risk Register: A Practical Starting Point

What a risk register is, and what it isn’t

A risk register is a maintained record of the risks an organisation has identified for a system, a project, or an activity, together with who owns each risk and what is being done about it. For AI systems, it is the artefact that turns a risk assessment from a one-time exercise into an ongoing operational habit: the assessment identifies risks; the register is where they live afterwards, get reviewed, get closed out, or get escalated.

A risk register is not the same thing as an AI risk management framework. A framework (NIST’s AI RMF is the most widely referenced general-purpose one) tells you what activities to perform and in what order. The register is one of the outputs of that process — specifically, the output of the framework’s mapping and measurement activities, kept current as the system changes. Confusing the two is a common early mistake: teams sometimes adopt a framework’s vocabulary without ever producing a register that anyone actually looks at after the kickoff meeting.

What a risk register actually contains

There is no single mandated format, but a working AI risk register that survives more than one review cycle consistently has these fields. Fewer than this and it stops being useful for anything except a compliance checkbox; more than this and people stop filling it in.

• Risk description. A specific, falsifiable statement of what could go wrong — not a category label. “The model may leak training-data PII in generated output” is a risk description; “privacy risk” is a category. The description should name the mechanism (how the harm would actually occur), because that is what makes the mitigation field answerable later.
• Likelihood and impact. Most registers use a simple ordinal scale (e.g. low/medium/high, or 1–5) for each, rather than trying to force a false precision of percentages the organisation can’t actually back up. What matters more than the scale itself is that likelihood and impact are scored separately and combined consistently, so risks can be ranked and the register can be sorted by priority rather than by the order entries were added.
• Owner. A named individual, not a team or a function. A risk with a team as its owner is a risk nobody is accountable for. The owner is the person who is expected to know the current status of that risk if asked, and who is responsible for triggering escalation if the risk’s likelihood or impact changes.
• Mitigation. What is actually being done, distinguished from what is planned. A mature register separates “mitigation in place” from “mitigation planned” with a target date, because collapsing the two into one field is how aspirational controls end up being reported as if they already existed.
• Review cadence. When the risk is next due for reassessment, and what would trigger an earlier review outside that schedule. Cadence should not be uniform across the register: a risk tied to a capability threshold the system hasn’t reached yet needs a very different review trigger than a risk tied to a control that’s already live and just needs periodic confirmation it’s still working.

Some organisations add a status field (open/mitigated/accepted/closed) and a residual-risk score after mitigation. Both are useful once the core five fields are working; neither is worth adding first.

Where the register fits inside an AI risk management framework

The NIST AI Risk Management Framework (AI RMF 1.0), published January 2023, is the most commonly used structural reference for this, and it maps onto the register cleanly because it is organised around four functions rather than a single checklist:

• Govern — NIST describes this as cultivating and implementing a culture of risk management within the organisation. In register terms, Govern is what decides the register’s format, who is allowed to close a risk, and what counts as an acceptable residual-risk level. Without a Govern function actually enforcing it, a risk register is just a spreadsheet nobody is required to keep current.
• Map — establishes the context to frame risks related to the AI system: its intended purpose, deployment context, and the range of impacts it could plausibly have. This is where new entries in the register originate. Mapping is also where a shared vocabulary for naming a risk actually pays off, because two teams describing the same risk pathway in incompatible language will end up with duplicate or inconsistent register entries.
• Measure — employs quantitative, qualitative, or mixed methods to analyse, assess, benchmark, and monitor the risk. This is the likelihood/impact scoring, and any evaluation evidence that backs it up.
• Manage — allocates risk resources to mapped and measured risks on a regular basis, as defined by Govern, through documented response and recovery plans. This is the mitigation and review-cadence fields doing their job over time, not just at register creation.

A useful way to think about it: the four functions are the process, and the risk register is the shared record that Map, Measure and Manage all read from and write to, under rules that Govern sets.

A starting template

For a first register, a single table with one row per risk and the following columns is enough to start operating, before adding anything more elaborate:

• Risk ID (a stable identifier, so the risk can be referenced from incident reports, model cards, or evaluation results without re-describing it each time)
• Risk description (the specific, mechanism-level statement described above)
• Category (a short tag for grouping — e.g. misuse, reliability, security, privacy, third-party — used for sorting and reporting, not as a substitute for the description)
• Likelihood (ordinal scale)
• Impact (ordinal scale)
• Owner (named individual)
• Mitigation status (in place / planned, with target date)
• Mitigation description
• Review cadence and next review date
• Escalation trigger (the specific condition — a capability threshold crossed, an incident, a new deployment context — that forces an out-of-cycle review)
• Status (open / mitigated / accepted / closed)

The escalation-trigger column is the one most starter templates skip, and it’s the one that determines whether the register is a living document or a snapshot that goes stale the month after it’s created. A risk whose likelihood depends on a model capability the organisation hasn’t reached yet should name that threshold explicitly as its trigger, rather than relying on the general review cadence to catch it in time.

A shared vocabulary for the description field

The hardest part of keeping a risk register useful across more than one team is rarely the spreadsheet mechanics — it’s getting independent teams to describe the same risk the same way, so entries can be compared, deduplicated, and rolled up. This is exactly the gap CASRAI’s NIKOLAI dictionary is built to close for frontier-AI safety specifically: a versioned, machine-readable set of definitions for the elements a safety framework, risk report, or evaluation can contain, crosswalked against how major labs and regulators actually use those terms in their published documents (NIKOLAI is currently at version nikolai-v0.2, defining 64 elements across ten tracks). NIKOLAI is not an evaluator or a regulator, and it doesn’t run assessments itself — it’s a reference vocabulary, which is a different and narrower job than the register or the framework does.

Two parts of NIKOLAI map onto the register fields above with unusual directness. Its threat models and risk framing track defines the structured fields — who could cause harm, through what mechanism, and why that threat was prioritised — that a good risk description needs to answer; using that structure when writing the description field is a reasonable way to avoid the “privacy risk” category-label problem described above. And its capability-threshold element defines, and crosswalks across major published frameworks, exactly the kind of condition that belongs in a register’s escalation-trigger column: a stated level of model capability at which specified additional safeguards or decisions become required. Reusing that definition, rather than inventing a looser one per team, is what lets an escalation trigger in one team’s register mean the same thing as the equivalent trigger in another team’s.

FAQ

How is a risk register different from a risk assessment?

A risk assessment is the activity of identifying and scoring risks. The risk register is the artefact that stores the results and keeps them current after the assessment is over. One assessment can update many entries in an existing register; a register that’s never updated after its first assessment isn’t functioning as a register.

Who should own the AI risk register itself, as distinct from owning individual risks?

This should be assigned explicitly under the Govern function, before individual risk owners are assigned. In practice it’s usually whichever role or committee already has authority to approve or block a deployment decision, since the register needs to be authoritative enough that people actually check it before that decision.

Do we need a separate register for every AI system, or one shared register across the organisation?

Both patterns are common. A single shared register with a system/product column scales better for organisations running many similar systems, because it makes cross-system risks (a shared vendor dependency, a shared model family) visible in one place. Per-system registers work better when systems differ enough in risk profile that a shared likelihood/impact scale would be misleading across them.

How often should the register be reviewed?

There should be two triggers, not one: a scheduled cadence (set per risk, not uniformly — see the review-cadence field above) and event-based escalation triggers that force an out-of-cycle review regardless of schedule. A register that relies only on scheduled review will consistently be out of date at the moment it matters most, which is right after something changes.