Free AI Risk Register Template (Copy-Paste) + How to Use It

Here's a free AI risk register template you can copy straight into a spreadsheet, plus the example rows, scoring method and framework mapping that make it hold up in front of a board, an auditor or an enterprise buyer. An AI risk register is the single document that proves you know what your AI systems can do, what could go wrong, who owns each risk, and what you're doing about it. The table below is built to drop into Excel, Google Sheets or your GRC tool. Copy the columns, keep the example rows as a starting point, then replace them with your own systems.

What is an AI risk register?

An AI risk register is a living record of every AI-specific risk your organisation carries, scored, owned and tracked over time. It's the same idea as a classic enterprise risk register, pointed at the risks that only show up once you start building, buying or deploying AI: bias, hallucination, prompt injection, model supply chain, and the rest.

It does three jobs at once. It forces you to list your AI systems and name what could go wrong. It scores each risk so you can argue about priorities with numbers instead of opinions. And it assigns an owner and a control to every line, so a risk can't sit unaddressed because nobody was responsible for it.

One thing to be clear about. A register isn't a one-off document you write before launch and file away. It's a control you run on a cadence. More on that below.

The free AI risk register template

Copy this table. Each column maps to a field you'll keep for every AI system you run. The example rows cover the AI risk categories that come up most often, with realistic generic descriptions you can adapt. Risk score is Likelihood multiplied by Impact, each rated 1 to 5, giving a score from 1 to 25.

Risk ID	Risk category	Risk description	Likelihood (1-5)	Impact (1-5)	Risk score (LxI)	Owner	Mitigation / controls	Status	Review date
AIR-01	Data privacy	Personal data entered into a third-party LLM prompt is retained or used for training without a lawful basis	4	5	20	DPO	No-PII prompt policy, enterprise tier with no-training contract terms, input filtering, DPIA on file	In progress	2026-09-30
AIR-02	Bias / fairness	Model produces systematically worse outcomes for a protected group in a hiring or credit decision	3	5	15	Head of Data Science	Pre-deployment fairness testing across affected groups, human review of decisions, post-launch drift monitoring	In progress	2026-08-31
AIR-03	Security (prompt injection)	Malicious instructions hidden in user input or retrieved documents hijack an AI agent's behaviour	4	4	16	CISO	Input and output validation, least-privilege tool access, agent action allow-lists, red-team testing	Open	2026-08-15
AIR-04	Security (data exfiltration)	An AI assistant with broad data access leaks confidential records through its responses	3	5	15	CISO	Role-based access scoping, output filtering, logging and anomaly detection on AI queries	In progress	2026-09-15
AIR-05	Accuracy / hallucination	Model states false information as fact in a customer-facing or decision-support context	4	4	16	Product Owner	Retrieval grounding, confidence thresholds, human-in-the-loop for high-stakes outputs, accuracy monitoring	In progress	2026-08-31
AIR-06	Model / third-party supply chain	A foundation model or vendor changes behaviour, pricing or terms with little notice, breaking a dependent workflow	3	4	12	Procurement	Vendor due diligence, model version pinning, fallback provider, contractual change-notice terms	Open	2026-10-31
AIR-07	Regulatory / compliance	A deployed system meets the EU AI Act high-risk criteria but lacks the required documentation and oversight	3	5	15	Head of Legal	System inventory with risk classification, technical documentation, conformity assessment plan	In progress	2026-09-30
AIR-08	Operational / over-reliance	Staff act on AI output without checking it, and skills to do the task manually erode over time	4	3	12	Operations Director	Human oversight policy, periodic manual spot-checks, training on AI limitations	Open	2026-09-30
AIR-09	Transparency / explainability	The organisation can't explain how a model reached a decision when a customer or regulator asks	3	4	12	Head of Data Science	Model and decision documentation, explainability tooling, clear audit trail for each decision	Open	2026-10-15
AIR-10	Reputational	A public AI failure (offensive output, visible error) damages brand trust and triggers media coverage	2	5	10	Head of Comms	Content filtering, staged rollout, incident response plan, holding statements prepared	Monitor	2026-11-30
AIR-11	IP / copyright	Generated content reproduces copyrighted material, or proprietary code is leaked into a model	3	4	12	Head of Legal	Usage policy, output screening, indemnity terms with vendors, no-secrets-in-prompts rule	Open	2026-09-30
AIR-12	Accountability / governance	No named owner exists for an AI system, so risks go unmanaged and changes ship without sign-off	3	4	12	Chief Risk Officer	Mandatory ownership per system, change approval workflow, governance reporting to the board	In progress	2026-08-31

The dates above are illustrative placeholders. Set your own review dates when you adapt the template.

How do you use an AI risk register?

The mechanics are simple. The discipline is what makes it work.

Score with likelihood times impact. Rate how likely the risk is on a 1 to 5 scale, rate how bad it'd be if it happened on the same scale, and multiply. That gives every risk a number from 1 to 25, so you can rank them against each other without arguing about feelings.

A workable scale:

• Likelihood: 1 rare, 2 unlikely, 3 possible, 4 likely, 5 almost certain
• Impact: 1 negligible, 2 minor, 3 moderate, 4 major, 5 severe (regulatory, legal or safety consequences)

Sort into priority bands (RAG). Group the scores so the register tells you where to act first:

• 1 to 6, green, monitor
• 7 to 12, amber, mitigate on a planned timeline
• 13 to 19, red, prioritise now
• 20 to 25, critical, immediate action and board visibility

Give every risk one named owner. Not a department, a person. A risk owned by "the team" is owned by nobody. The owner is accountable for the mitigation and for reporting status at each review.

Run it on a cadence. Review the whole register quarterly at minimum, monthly for anything in the red or critical bands, and immediately after any incident or major system change. AI systems drift, vendors change models, and new attack methods appear, so a register that's six months stale is fiction.

Who owns the register itself? The Chief Risk Officer or equivalent owns the register as a whole and reports it upward. Individual risk owners own their lines. The board sees the top of the stack, the red and critical risks, at every meeting.

How does it map to NIST, ISO 42001 and the EU AI Act?

A register isn't a framework on its own. It's the working artefact that lets you satisfy several frameworks at once. Here's how the columns connect to the three that matter most.

NIST AI Risk Management Framework (AI RMF 1.0). The framework is built around four functions: GOVERN, MAP, MEASURE and MANAGE, split across 19 categories (NIST AI RMF Core). Your register is where MAP (naming the risks and context), MEASURE (scoring them) and MANAGE (assigning controls and tracking treatment) become visible. GOVERN sits underneath it: the ownership column and the review cadence are the governance that makes the rest stick. The framework is voluntary and US-published (NIST AI 100-1), but it's the reference most boards and regulators now point to.

ISO/IEC 42001:2023. This is the first international standard for an AI management system, published in December 2023 (ISO/IEC 42001:2023). It covers the full AI lifecycle and, unlike NIST, you can be certified against it by an accredited body. A maintained risk register is part of the evidence an ISO 42001 auditor expects to see, because the standard requires you to identify, assess and treat AI risks on an ongoing basis. If you're heading for certification, the register is one of the documents that proves the management system is real.

EU AI Act. The Act sorts AI systems into four risk tiers (EU AI Act high-level summary):

• Unacceptable risk: banned outright (social scoring, certain biometric surveillance, manipulative systems)
• High risk: heavy obligations including a risk management system, data governance, technical documentation and human oversight (the Annex III use cases, such as employment, credit and critical infrastructure)
• Limited risk: transparency duties (tell users they're dealing with AI, label deepfakes)
• Minimal risk: no obligations (most applications)

The register is where you record which tier each system sits in and the controls that match. For high-risk systems the Act effectively requires a risk management process, so the register stops being optional. Prohibited practices have applied since 2 February 2025 and GPAI model rules since 2 August 2025 (implementation timeline). Penalties run up to 35 million euro or 7% of total worldwide annual turnover for prohibited practices, whichever is higher, and up to 15 million euro or 3% for other breaches (Article 99). Note that as of June 2026 the timing of some high-risk obligations is under review through the EU's proposed Digital Omnibus, so check the current position before you rely on a specific date.

For a deeper walk through each framework, see our NIST AI Risk Management Framework guide and the EU AI Act compliance checklist by industry.

A register is a living control, not a one-off document

The most common mistake isn't writing a bad register. It's writing a good one and then never looking at it again. A register filed in a shared drive after launch tells an auditor you treat AI risk as a formality.

The version that earns its keep is reviewed on a schedule, updated after every incident, and reported to the board. It changes as your systems change. New model, new row. Vendor swaps their underlying model, re-score the supply chain risk. Regulator publishes guidance, revisit your classifications. The register is a habit, not a deliverable.

Frequently asked questions

What is an AI risk register?

It's a living document that lists every AI-specific risk your organisation faces, scores each one by likelihood and impact, assigns an owner, and records the controls in place. It's the working evidence that you're managing AI risk rather than hoping for the best, and it's the artefact auditors and enterprise buyers ask to see.

What should an AI risk register include?

At minimum: a risk ID, the risk category, a plain description, likelihood and impact scores, a calculated risk score, a named owner, the mitigation or controls, current status, and a review date. The categories that matter for AI are data privacy, bias and fairness, security (including prompt injection and data exfiltration), accuracy and hallucination, model supply chain, regulatory compliance, operational over-reliance, transparency, reputation and IP.

What's the difference between an AI risk register and an AI risk assessment?

A risk assessment is the analysis you run to identify and score risks at a point in time. The register is the living document that holds the output and tracks it over time. You do an assessment, the results land in the register, then the register keeps moving as you treat risks, add systems and re-score. The assessment is an event; the register is the ongoing record. See our AI agent risk assessment framework for the assessment side.

Is this free AI risk register template good enough for compliance?

The template gives you the structure that NIST AI RMF, ISO/IEC 42001 and the EU AI Act all expect: identification, scoring, ownership and treatment. That's the right backbone. What makes it compliant is the work you put around it: real risk analysis on your own systems, honest scoring, named owners who act, and a genuine review cadence. The table is the start, not the finish.

How often should you review an AI risk register?

Quarterly at minimum for the whole register, monthly for anything in the red or critical bands, and immediately after any incident or major change to a system, model or vendor. AI moves faster than annual risk cycles, so a register reviewed once a year is out of date by the time anyone reads it.

The bottom line

Most organisations deploying AI don't have a real risk register. They have a slide that says they take risk seriously. The gap between those two is exactly what trips them up when a regulator, a buyer or an incident comes calling.

Start with the table above. Replace the example rows with your own systems, score them honestly, give every line an owner, and put a recurring review in the calendar. That single habit puts you ahead of most of the market, and it gives you something concrete to hand to a board or an auditor.

The harder part is doing the risk analysis well, scoring without flattering yourself, and keeping the thing alive once the launch buzz fades. That's where a register stops being a spreadsheet and starts being a control. If you want the analysis behind the template done properly, mapped to the frameworks that apply to you, that's the work we do. For the wider picture, read our AI compliance audit guide.

More free templates and tools

All free, no sign-up:

• AI DPIA template
• AI Use Policy template
• AI Vendor Assessment checklist
• EU AI Act Readiness check (interactive)

This is the kind of work our AI compliance advisory handles.