What goes in an AI risk register — and what does not

The generic-IT-register failure is what happens when an organisation tries to handle AI risk inside an existing GRC tool. The tool is configured for enterprise risk categories — operational, financial, regulatory, vendor — and AI is added as a sub-category. The risks that show up are the generic enterprise concerns with an AI flavour: “regulatory exposure due to evolving AI legislation”, “reputational damage from AI-related incidents”, “vendor concentration on AI providers”. These are not wrong; they are just at the wrong level. They are portfolio-level concerns, not risks against a specific assessed system, and they do not drive any control action.

The threat-list failure happens at the opposite end. A security architect or AI governance lead has done the right thing — anchored the register to a public framework — but stopped at category labels. Each row says “Prompt Injection” or “Memory Poisoning” with a paragraph of generic description cribbed from the framework, and the rest of the row is empty. The register looks comprehensive; it does no work.

Both failures share the same root cause: the register is being treated as a document that exists for compliance optics, rather than as an artefact that drives the control plan and feeds into the residual risk acceptance. When a register actually does that work, its structure changes — it gets specific, it gets shorter (because irrelevant categories drop out), and it acquires fields that the generic version never needed.

Across assessments where the register has actually held up under audit review, the same five fields show up. They are not arbitrary. Each one answers a question the register has to answer if it is going to be useful, and each one is the field most likely to be missing in the generic version.

1. Risk ID and category — anchored to a public framework.
2. Attack path — the specific sequence of steps for this system, not a generic description.
3. Inherent risk — likelihood and severity before any control is applied, on a defined scale.
4. Controls applied — reference IDs from the control plan, not restated control descriptions.
5. Residual risk — post-control rating, plus a named acceptor with conditions, or a target date and owner for further treatment.

A register with these five fields populated, per row, against the actual threats that apply to the system, will do its job. A register missing any one of them will not. The rest of this piece walks through each field, explains the failure mode when it is missing, and shows what a fully populated row looks like in practice.

Every entry needs a short stable identifier (R-01,R-02, …) so it can be cited from other artefacts — the control plan references it, the disposition memo references it, the evidence pack references it, a procurement reviewer can cite it back to you. Without a stable ID, the only way to refer to a risk is by its description, which means the description gets cut and pasted around and starts to drift.

More important is the category — and where you get it from. The strongest AI risk registers we have reviewed anchor their categories to a public framework. The candidates are:

• OWASP LLM Top 10. For systems whose primary risk surface is the LLM itself — prompt injection, training data poisoning, model denial of service.
• OWASP Agentic Top 10. For agentic systems — memory poisoning, tool misuse, agent identity spoofing, goal manipulation.
• MAESTRO. For agentic systems where threats need to be mapped across multi-layered architecture (foundation, deployment, orchestration, agent).
• MITRE ATLAS. For tactic/technique decomposition where attack-path detail matters for incident response readiness.
• NIST AI RMF. For organisational alignment with the Map, Measure, Manage, Govern functions and for traceability to regulatory expectations.
• ISO/IEC 42001. For systems being prepared for an AI management system audit, where the register supports evidence for the standard's risk management requirements.

Bespoke taxonomies are the wrong move here. We have seen organisations invent their own categories — “cognitive risk”, “model trust risk”, “AI ethics risk” — that turn out to be hard to map back to any external standard. The moment a regulator, a customer's procurement reviewer, or an internal auditor reads the register, they have to decode the taxonomy before they can read the content. That decoding is friction the register does not need to add. Borrow from the established frameworks even if the fit is imperfect, and note the framework citation in the row.

This is the field most registers skip, and it is the field that most determines whether the register is useful. The category name is a label; the attack path is the specific sequence of steps an attacker would take against this system. Until that path is written down, the entry is not actionable, because no one can tell whether a proposed control closes the threat or merely sounds like it should.

Memory poisoning is the classic example. The category appears in nearly every agentic system register we have read. The category by itself tells you almost nothing about what to do. The attack path tells you everything. For a procurement agent with a long-term memory store, the path might read:

Attacker submits a supplier document whose body contains adversarial instructions phrased as system commands. The agent ingests the document, extracts a summary, and writes the summary to long-term memory under the supplier's entity record. On a subsequent session — perhaps weeks later — retrieval surfaces the poisoned memory while the agent is handling a different request from the same supplier. The agent treats the embedded instructions as authoritative context and attempts to invoke the email-send tool with attacker-controlled content.

Read that paragraph, and the controls write themselves. A memory write filter that rejects instruction-shaped content. A retrieval-time validator that distinguishes authoritative context from cached document content. A human approval boundary at the email-send tool. A quarterly memory store audit. Each control closes a specific step in the attack path. Without the path, the same controls would be a wish list — “input sanitisation”, “output validation”, “human in the loop” — that nobody can tell whether is sufficient.

A good attack path is concrete about the system in question. It names the interface that accepts the malicious input, the data store or memory location that gets corrupted, the retrieval mechanism that surfaces the corruption, and the tool or action whose invocation is the impactful consequence. Concrete, in this context, means “your engineering team recognises every component named in the path”. If the path could apply to any system in the same category, it is too generic to drive a control plan.

Inherent risk is the risk rating before any control is applied. It is a combination of likelihood and severity, both on a defined scale. The defined-scale part is non-negotiable. We have read registers where the likelihood column contains values like “moderate-ish”, “possible”, “hard to say”. None of these mean anything. They are placeholders that let the register be filled in without thinking.

Use the same four-point scale every row: low, medium, high, critical. Define each level once, in a methodology note attached to the register, and use the same definitions everywhere. The definitions should be specific enough that two analysts presented with the same evidence would land on the same rating most of the time. Generic definitions — “medium means it could happen sometimes” — do not produce that consistency.

The pre-control rating is what most matters. Many registers conflate inherent risk with residual risk, which means the rating shifts every time a control is added and nobody can tell what the rating used to be. Capture the pre-control rating once, when the entry is first written, and leave it unchanged unless the attack path itself changes. Then capture the post-control rating separately, in field five. The difference between the two is the work the control plan is doing, and if you cannot articulate that difference for any entry, you cannot defend the controls.

This field is where most registers do the wrong thing. The wrong thing is to restate the control description inside the register, alongside the risk entry. Now the same control description lives in two places — the control plan and the register — and they immediately start to drift. The control plan gets updated; the register doesn't. Or vice versa. Six months later, nobody can tell which is current.

The right thing is to put control reference IDs in the register and nothing else. C-01, C-07, C-09. The control descriptions live in the control plan, which is where they are owned, versioned, and updated. The register references the control plan; it does not duplicate it.

The pay-off from this discipline is that the register stays readable. Each row of a fully populated register fits in a screen, because the controls are referenced rather than expanded. A reader who wants the detail clicks through to the control plan. A reader who wants the risk profile reads the register straight through. Two different reading modes, one source of truth per artefact, no drift.

The cost of getting this wrong is more than just clutter. A register that restates control descriptions invites updates in two places. When a control is modified — its scope changes, its owner changes, its verification method changes — only one of the two copies tends to get updated. Auditors who spot the divergence ask which is canonical. The honest answer is “we intended the control plan to be canonical”, which is a slow way of saying the register has been left behind. Avoid the problem entirely by referencing rather than restating.

Residual risk is the rating after the listed controls are in place. It uses the same scale as inherent risk — low, medium, high, critical — and is captured in a separate column so the difference between pre- and post-control is visible at a glance. The point of having the two ratings is that a control that does not change the rating is a control that is not closing the risk in a meaningful way, which is a question worth asking while the register is still being finalised.

Residual risk on its own is not enough. The entry needs either a named acceptor — a role, with rationale and conditions — or a target date and owner for further treatment. Without one of these, the residual rating sits in the register with no decision attached. Has the residual risk been accepted? By whom? Under what conditions? Or is further treatment planned? By whom? By when? Those questions need answers before the register is handed to a committee.

The named acceptor follows the same pattern as the residual risk acceptance in the evidence pack: a role (not a name), a rationale (two or three sentences explaining why this residual is acceptable given the controls and the lifecycle gate), and conditions (the qualifiers without which the acceptance falls away). The conditions should map to a re-assessment trigger — when condition X changes, this acceptance is invalidated and re-review is required. That mapping is what makes the register part of a living governance posture rather than a one-shot artefact.

The worked example above shows what all five fields look like when populated. Each field does its work; nothing is duplicated; the entry references the control plan and the trigger register rather than restating them. The row is dense but readable, and an auditor reading it can verify each claim by following the references.

The other half of the discipline is knowing what to keep out. We have seen AI risk registers swell to fifty or a hundred rows, most of which should have been in a different document. Each of these patterns is a sign the register is being misused as a general-purpose worry list.

• Business risks.“Market may not adopt AI-enabled product line.” “Competitive pressure may erode pricing.” These are portfolio concerns. They belong in the business risk register, owned by the Business Owner or the CFO function. Putting them in the AI risk register dilutes its purpose and assigns them to a role (the Security Architect, typically) with no authority to address them.
• Generic IT risks unless AI-specific.“Cloud provider outage may affect availability.” If this risk applies equally to your ERP, your CRM, and your AI system, it belongs in the IT risk register. Include it in the AI register only when there is something AI-specific about the manifestation — a model that fails silently on stale data, a retrieval pipeline that degrades to hallucination under degraded connectivity, an agent that takes destructive actions when its tool endpoint is unreachable.
• Marketing language.“The system might cause reputational damage.” “AI may evolve in unexpected ways.” These are not risks; they are anxiety. A risk is something specific with an attack path and a treatment plan. Anxiety belongs in a strategy memo.
• Un-actionable items.“The regulatory landscape may change.” True, but unless there is a specific anticipated change with a treatment plan (“EU AI Act Article 9 enforcement begins date X — see readiness plan”), the row is a placeholder. The regulatory landscape belongs in a horizon-scanning function or a board-level briefing, not a per-system register.
• Risks against systems not in scope.“Our other AI systems also have prompt injection exposure.” Possibly true; this register is for one system. The other systems need their own registers. Cross-system patterns belong in the organisational AI risk register, which is a separate layer.

Each of these belongs somewhere — a business risk register, an IT risk register, a strategy memo, a horizon-scanning brief, another system's register. The AI risk register is one specific artefact, scoped to one specific system, with a specific job. Keeping it on-scope is what makes it legible.

AI risk registers are per-system. This is the single most useful structural decision the discipline makes. One system, one register. The threat surface is system-specific; the controls are system-specific; the residual risk is system-specific; the acceptors are role-named but the rationale is system-specific. Trying to maintain one register that covers all of an organisation's AI systems collapses the specificity that makes each register useful.

There is, however, a separate artefact that does cover the portfolio: the organisational AI risk register. It captures risks that exist above the level of any single system — concentration risks, governance gaps, skills gaps, vendor exposure across the AI portfolio. These are real risks. They just are not the same risks the per-system register captures, and conflating them does damage to both.

The organisational register typically includes entries like:

• Skills gap. The organisation lacks practitioners trained in AI red-teaming for the volume of systems entering production.
• Governance gap. The AI Committee meets quarterly while new systems are entering pilot weekly. The clearance throughput does not match the demand.
• Vendor concentration. A material proportion of the organisation's AI systems share a single foundation-model provider. A material incident at that provider would cascade.
• Sub-processor fan-out. The organisation has lost track of how many sub-processors are involved across the AI portfolio. The DPO cannot answer the question on demand.
• Re-assessment backlog. Re-assessment triggers fire faster than the assessment team can respond. The portfolio is drifting into a state where some clearances are stale.

None of these belong in a per-system register, because none of them are risks against any single system. All of them are real, and an organisation operating AI at any scale needs an artefact to capture them. That artefact is the organisational AI risk register, and it sits at the portfolio governance layer — owned by the AI Governance function or the CISO, depending on the organisation's structure.

Per-system registers do specific work against specific systems. Organisational registers do portfolio work across the AI estate. The failure mode is one register trying to do both — at which point neither job gets done well.

The relationship between the two layers is one of escalation. A pattern that shows up in multiple per-system registers — for example, repeated findings about retrieval pipelines being inadequately scoped — is the signal that an organisational-level treatment is needed. The per-system register documents the system-specific instance; the organisational register documents the pattern and the portfolio-level response. Each layer feeds the other; neither replaces the other.

If your organisation is currently maintaining one register that mixes system-specific entries with portfolio-level concerns, the most useful refactor is to split it into two artefacts. The per-system entries become per-system registers, one per assessed system. The portfolio entries become the organisational register. The two artefacts cross-reference each other but are owned by different roles, read by different audiences, and updated on different cadences. After the split, each register is shorter, more specific, and easier to defend — and the portfolio view becomes visible for the first time, because it is no longer buried under system-specific detail.