AI Risk Register Template: Column Structure and Article 9 Compliance

Every provider of a high-risk AI system must run a risk management system under Article 9 of Regulation (EU) 2024/1689. The risk register is the operational artifact that system produces — the structured, version-controlled document in which you identify every material risk, score it, control it, and record the decision that the residual exposure is acceptable.

This page focuses on the template itself: what columns it must contain, what each column is for, and how a completed register feeds into the broader compliance architecture. For a conceptual grounding in the Article 9 obligation and the register's role in the compliance lifecycle, see the AI risk register guide. For worked entries across realistic deployment scenarios — CV screening, credit drift, prompt injection, oversight gaps — see AI risk register examples.

---

Why the Column Set Matters

The EU AI Act specifies what a risk management system must capture — identified risks, estimated likelihood and severity, mitigation measures, residual risk, post-market monitoring — but it does not prescribe column headers. That flexibility creates a trap. Teams that design their register ad hoc tend to omit the two fields that matter most to an auditor: the acceptability decision and the linked Article. A register with seventeen risks and no sign-off on whether residual exposure is acceptable is not a compliant Article 9 document; it is a list.

The column set below is designed to close that gap while remaining compact enough to maintain in practice.

---

The Register Columns

Primary identification

Risk ID — a unique, stable reference such as RSK-009. Stability matters: the ID appears in the Article 11 technical file, in incident reports, and in audit logs. When you close or supersede a risk, retire the ID rather than reuse it.

AI system — the system name plus version string (e.g., "LoanScorer v3.1.0"). One register entry applies to one system at one version. A new release with materially changed functionality generates a new entry linked to its predecessor, not an overwrite.

Risk category — a controlled vocabulary makes the register queryable and comparable across systems. Recommended categories: Bias / Discrimination; Robustness / Accuracy; Security (including prompt injection and adversarial inputs); Data / Privacy; Transparency; Drift; Oversight Failure. A single risk can span multiple categories — record the primary and secondary.

Risk characterisation

Description — the most important free-text field. Write a concrete, specific statement: the mechanism, the affected population, and the likely harm. "Demographic bias" is not a description. "Model assigns systematically lower credit scores to applicants from lower-income postcodes due to proxy correlation in the training data, creating potential discrimination under Article 21 of the EU Charter" is a description. Specificity is what makes the register defensible under scrutiny.

Affected persons / rights — name the people or groups who could be harmed: job applicants over 55, patients in rural areas, customers without a formal credit history. Where the risk touches fundamental rights — non-discrimination, privacy, access to services — make that explicit. Article 9(2)(a) specifically requires analysis of risks to health, safety, and fundamental rights.

EU AI Act article touched — map each risk to the obligation it engages. Typical mappings:

• Bias / Discrimination → Art 9 (risk management), Art 10(2) (data governance including bias detection)
• Robustness / Accuracy / Security → Art 15
• Transparency / Explainability → Art 13 (information to deployers), Art 14 (human oversight)
• Oversight Failure → Art 14
• Drift / Post-market → Art 72
• Data / Privacy → Art 10(3) (personal data in training), cross-reference GDPR Art 35

This column converts the register from a risk inventory into a compliance map. An auditor can trace from Article to evidence in a single step.

Scoring

Likelihood — a 1–5 scale with anchors defined before scoring begins. Example: 1 = theoretical, no evidence in similar systems; 3 = observed in comparable deployments or in pre-deployment testing; 5 = observed in this system's production data. Anchor to evidence, not intuition. Scores without defined anchors cannot be consistently applied across assessors or reviewed by a third party.

Severity — independent of likelihood; measures the magnitude of harm if the risk materialises. 1 = minor inconvenience with no lasting effect; 3 = material harm, reversible; 5 = severe, potentially irreversible harm (denial of employment, wrongful refusal of essential services, physical injury). For fundamental-rights harms, the floor is typically 4.

Inherent risk score — likelihood × severity, before any controls. This pre-mitigation score is what gets compared to the residual score. Without it, you cannot demonstrate that your controls actually reduce risk.

Controls

Mitigation / control — describe the specific, implementable action: not "improve data quality" but "add a mandatory fairness audit comparing approval rates across age, gender, and nationality cohorts to the training-data baseline before each model release." Each entry may contain multiple controls; number them for traceability.

Control owner — the named individual or role accountable for implementing and maintaining the control. Collective ownership produces collective inaction. The control owner is also the person responsible for providing evidence of implementation.

Control status — Planned / In Progress / Implemented / Verified. An implemented control without evidence of verification does not satisfy Article 9's requirement that mitigation measures be tested for effectiveness before market placement.

Residual risk and acceptance

Residual risk score — likelihood × severity after controls. Calculated the same way as inherent risk, using post-mitigation estimates. Document the logic: "retraining reduced likelihood from 4 to 2; severity unchanged at 4; residual = 8."

Acceptance decision and owner — this is the field most often omitted and the most auditorially significant. Article 9(5) requires that residual risks judged acceptable are explicitly documented. "Acceptable" is a decision, not an absence of objection. Record: the decision (Accepted / Under Review / Unacceptable — action required), the name and role of the person making it, and the date. For high-severity residual risks, the sign-off should be at executive level.

Maintenance

Review date — the date by which this entry must be re-evaluated, regardless of whether a trigger event has occurred. Set it to a maximum of twelve months out for most entries; quarterly for high-severity residual risks. When a review happens, record the outcome and reset the date.

Status — Open / In Progress / Mitigated / Accepted / Closed. "Closed" means the risk has been fully eliminated or the system has been decommissioned; "Accepted" means the residual risk is documented as tolerable and is being monitored.

---

Worked Example — Three Entries

The table below shows the column set populated for three distinct risk types: a bias risk in a recruitment tool, a security risk in an agentic internal assistant, and a drift risk in a credit-scoring model.

---

The Register Is Version-Controlled, Not a Snapshot

A register created once at the point of conformity assessment and never updated does not satisfy Article 9. The Act requires the risk management system to be continuous. In practice that means two things.

First, the register must be versioned by release. When you ship a new version of the AI system — particularly any change that alters model weights, training data, or scope of deployment — you create a new register version tied to that release. The prior version is retained, not overwritten. Article 11 technical documentation must reflect the risk management system at the version placed on the market.

Second, post-market monitoring data under Article 72 feeds back into the register. Providers must operate a monitoring system that actively collects and analyses data from deployed systems and uses it to update the risk management system. When monitoring reveals a new risk, a new entry opens. When it confirms a mitigation is working, the status and residual score update. The review date in each entry enforces this: if the date passes without an action, that is a documented compliance gap.

---

How the Register Feeds Downstream Obligations

Article 11 technical file. Annex IV, section 2(d) requires the technical documentation to include "a description of the risk management system and its results." The register is that description. A formatted export of the register — showing the column set, all current entries, their residual risk scores, and acceptance decisions — is submitted as a section of the Annex IV package. Keep the register and the technical file in the same system to prevent them drifting apart.

Article 72 post-market monitoring. The post-market monitoring plan references the register's review dates and thresholds. When monitoring data arrives, the register is the instrument for recording its effect on existing risk scores and opening new entries. The feedback loop is not optional — it is what "continuous" means in Article 9(3).

Article 73 incident reporting. When a serious incident occurs, the relevant register entry updates immediately with the discovery date, initial severity assessment, and interim control. If the incident meets the Article 3(49) definition of a serious incident, Article 73 reporting to the market-surveillance authority follows: 15 days from awareness in most cases, 10 days where a person has died, 2 days for widespread or critical-infrastructure incidents. The timestamped register entry is part of the evidence trail the authority will review.

---

How Confir Helps

Confir maintains the register as a live, linked document. When you classify an AI system — using Confir's deterministic, rule-based intake — the relevant risk categories fire automatically based on the Annex III point. Each entry links directly to the controls and Articles it engages; the same data populates both the internal register and the Article 11 / Annex IV technical documentation export. Every update is recorded in an immutable audit log with timestamps, so the version history the Act requires is maintained without manual effort.

---

Frequently Asked Questions

What is the minimum number of columns a compliant risk register must have?

The EU AI Act does not specify column names. It specifies what must be documented: identified risks, estimated likelihood and severity under realistic conditions, mitigation measures with verified effectiveness, and explicit documentation that residual risks are acceptable (Article 9(5)). A register that captures all of those elements — even in a simpler format — can satisfy Article 9. The column set above reflects the minimum needed to produce an auditable, traceable document. The two fields that are most often omitted and most consequential are the acceptance decision and the EU AI Act article reference.

Does a deployer need to maintain a risk register under Article 9?

Article 9 is a provider obligation. Deployers are not required to maintain an Article 9 risk register — but deployers under Article 26 must monitor the AI system in operation and report anomalies and incidents to the provider. Deployers of creditworthiness or life/health insurance AI systems must also run a Fundamental Rights Impact Assessment under Article 27. Where a provider has structured the instructions for use to assign specific risk management tasks to the deployer, those tasks should be documented. A deployer that substantially modifies a system or places its own name on it under Article 25 becomes a provider and inherits the Article 9 obligation in full.

How often must the register be reviewed?

Article 9 requires the risk management system to be continuous — there is no fixed statutory interval. Event-driven reviews are mandatory when monitoring data reveals a new pattern, when a serious incident occurs, when the system is substantially modified under Article 3(23), or when the deployment context changes materially. Beyond event-driven reviews, most programmes set a minimum scheduled cadence: quarterly for high-severity residual risks, annually for accepted low-residual entries. The review date field in each entry enforces accountability. A date that has passed without an update is a documented compliance gap.

What does "residual risk is acceptable" mean under Article 9(5)?

Article 9(5) requires that residual risks judged acceptable be explicitly documented. "Acceptable" is not the same as "small." A residual risk can be medium severity and still be accepted — provided the decision is made by a named person, the rationale is recorded, and the risk is being monitored. What the Act forbids is implicit acceptance: leaving a risk entry with a non-zero residual score, no acceptance decision, and no owner. If the residual risk is genuinely not acceptable — it cannot be reduced further and the harm is too significant to tolerate — that is a go/no-go signal for market placement.

Does the risk register need to be in digital form?

No specific format is required. A well-maintained spreadsheet with version control and a full edit history can satisfy Article 9. The practical concern is audit defensibility: a spreadsheet with no timestamps cannot prove that a risk was identified on a given date rather than backdated. For systems subject to regulatory scrutiny, a system that records every change with a timestamp and user identity is materially safer. EU data-residency requirements apply wherever the register is stored — confirm the hosting location matches your data-governance commitments.

How does the risk register differ from the Article 11 technical documentation?

The technical file required under Article 11 and Annex IV is the broader compliance dossier: system description, design choices, data governance documentation, validation results, and the risk management system. The register is the operational core of the risk management system — the living record of specific risks, their scores, and their controls. Article 11 / Annex IV requires the technical file to include a description of the risk management system and its results; the register is that description. The risk register should not be maintained separately from the technical file and then reconciled at audit — they should be the same source.

---

Related guides

• practical risk register examples
• AI system inventory management
• Article 49 database registration
• risk management tool comparison
• Article 9 risk management system