# AI risk register template.

URL: https://levystreet.com/resources/ai-risk-register-template/
Updated: 2026-10-19

AI risk register template mapped to NIST AI RMF, the OWASP 2026 LLM Top 10 and ISO/IEC 42001, with scoring scales and 12 starter risks for NZ organisations.

## Short answer

An AI risk register is a living table of what could go wrong with each AI system, how likely and how serious it is, who owns it and which controls reduce it. This template scores risks on 5-point scales, maps each one to the NIST AI Risk Management Framework, the OWASP Top 10 for LLM Applications 2026 and ISO/IEC 42001, and includes 12 starter risks.

- Write each risk as cause, event and impact for a named system.
- Score likelihood and impact from 1 to 5; 15 or more needs a control before go-live.
- Map risks to NIST AI RMF functions and OWASP 2026 IDs so others can check coverage.
- A control is something that happens, not an intention.

A risk register earns its keep when it is specific to a system and reviewed on a schedule. Use one register for all your AI systems, with one row per risk per system. Start with the 12 starter risks below, delete the ones that do not apply, and add your own.

## The risk register template

| Column | What to record |
|---|---|
| ID | R1, R2 and so on |
| System | The specific AI system or tool, with its version or model |
| Risk statement | Cause, event and impact: "Because X, Y may happen, leading to Z" |
| Category | MBIE's risk areas: cybersecurity, privacy, human rights, workplace culture, environment, intellectual property, physical safety |
| Framework references | NIST AI RMF function; OWASP 2026 or agentic ID; NIST generative AI risk |
| Likelihood (L) | 1 to 5, from the scale below |
| Impact (I) | 1 to 5, from the scale below |
| Inherent score | L × I before controls |
| Controls | What actually happens to reduce the risk, and who does it |
| Residual score | L × I with controls working |
| Owner | One named person |
| Review date | When it is next checked |
| Status | Open, controlled, accepted or closed |

The categories come from MBIE's [Responsible AI Guidance for Businesses](https://www.mbie.govt.nz/assets/responsible-ai-guidance-for-businesses.pdf), which asks businesses to consider risks to cybersecurity, privacy, human rights, workplace culture, the environment, intellectual property and creators, and physical safety.

## Scoring scales

| Score | Likelihood | Impact |
|---|---|---|
| 1 | Rare: not expected in the next year | Minor: fixed in minutes, nobody outside affected |
| 2 | Unlikely: could happen once a year | Limited: internal rework, small cost |
| 3 | Possible: a few times a year | Moderate: a customer affected, complaint likely |
| 4 | Likely: monthly | Major: several customers, significant cost, possible privacy breach |
| 5 | Almost certain: weekly or more | Severe: harm to people, notifiable privacy breach, regulator involvement |

| Score (L × I) | Rating | Rule |
|---|---|---|
| 15–25 | High | Control in place and signed off by the sponsor before go-live |
| 8–14 | Medium | Control within 30 days; owner reviews monthly |
| 1–7 | Low | Monitor; review quarterly |

## Twelve starter risks

OWASP IDs are from the [OWASP Top 10 for LLM Applications 2026](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/) (LLM) and the [OWASP Top 10 for Agentic Applications for 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) (ASI). NIST risks are from the [Generative AI Profile](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf).

| ID | Risk | OWASP | NIST GenAI risk | Typical control |
|---|---|---|---|---|
| R1 | Staff enter personal information into a tool that uses it for its own purposes | LLM02 Sensitive Information Disclosure | Data Privacy | Business plan with training off; data rules in policy |
| R2 | A confident wrong answer is used in advice or a decision | LLM07 Misinformation | Confabulation | Source citations; human review before use |
| R3 | Instructions hidden in an inbound email or document redirect an assistant | LLM01 Prompt Injection; ASI01 Agent Goal Hijack | Information Security | Treat inbound content as data; restrict tools; test |
| R4 | An agent with broad permissions takes an unintended action | LLM03 Excessive Agency; ASI02 Tool Misuse and Exploitation | Information Security | Least privilege; approval for high-impact actions |
| R5 | Hidden instructions, internal notes or other users' data appear in answers | LLM08 Hidden Context Exposure | Data Privacy | Keep secrets out of prompts; per-user access checks |
| R6 | A loop or misuse runs up model costs | LLM06 Unbounded Consumption | n/a | Spending caps; rate limits; alerts |
| R7 | The vendor changes or retires a model and quality drops | LLM04 Supply Chain; ASI04 Agentic Supply Chain Vulnerabilities | Value Chain and Component Integration | Pinned versions; regression tests before switching |
| R8 | Outputs treat people differently on a prohibited ground | n/a | Harmful Bias or Homogenization | No automated decisions about people; bias checks |
| R9 | Outdated or tampered documents in the knowledge base produce wrong answers | LLM05 Data and Model Poisoning; LLM09 Vector and Embedding Weaknesses | Information Integrity | Document owners; review dates; restricted upload |
| R10 | AI output passed unchecked into another system | LLM10 Improper Output Handling | Information Security | Validate structured outputs before use |
| R11 | Generated content closely resembles someone else's work | n/a | Intellectual Property | Similarity check before publishing |
| R12 | Staff over-rely on AI, or feel constantly monitored by it | n/a | Human-AI Configuration | Training; consultation; review sampling |

R12 is not only a quality risk. WorkSafe's psychosocial guidance lists over-reliance on technology and constant digital monitoring among workplace hazards ([WorkSafe](https://www.worksafe.govt.nz/topic-and-industry/work-related-health/mental-health/managing-psychosocial-risks-at-work/)).

## How the register maps to NIST, OWASP and ISO/IEC 42001

The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) organises risk work into four functions: govern, map, measure and manage. In this register, the risk statement and category are **map**, the scores and test results are **measure**, the controls and residual score are **manage**, and the owner, review date and sign-off rule are **govern**. ISO/IEC 42001 is the international standard for an AI management system; certification is voluntary and done by independent bodies ([ISO](https://www.iso.org/standard/42001)). A maintained register with owners and review dates is the kind of evidence such a system relies on.

## How to use it


1. **List your AI systems.** Include subscription tools, AI features inside other software and anything you have built.
2. **Copy the starter risks for each system.** Delete what does not apply; add what is specific to that system.
3. **Score inherent risk.** Score as if no controls existed.
4. **Write controls as actions.** "Agent cannot send email without approval" is a control; "staff will be careful" is not.
5. **Re-score with controls.** Anything still 15 or above needs the sponsor's sign-off or a different design.
6. **Review on schedule and after incidents.** Link each incident in your [AI incident log](/resources/ai-incident-log-template/) to the risk it relates to.


## Filled-in example row

Illustrative example: a Wellington retailer's customer support assistant reads inbound emails and drafts replies.

| Field | Entry |
|---|---|
| ID, system | R3, support reply assistant (drafts only) |
| Risk statement | Because the assistant reads customer emails, hidden instructions in an email may make it include order details for another customer, leading to a privacy breach |
| Framework references | Map and Manage; LLM01, ASI01; Information Security |
| Inherent | L3 × I4 = 12 (medium) |
| Controls | Assistant can only draft, never send; it can look up only the order linked to the sender's email address; monthly injection tests based on our [prompt injection testing](/engineering/prompt-injection-testing/) guide |
| Residual | L2 × I2 = 4 (low) |
| Owner, review | Customer service lead; 1 February |

## Common mistakes

- **Generic risks.** "AI might be wrong" without a system cannot be controlled. Name the system and the harm.
- **Scoring once.** Risks change when models, data or permissions change.
- **Controls nobody performs.** If a control has no owner and no evidence, score as if it does not exist.
- **Ignoring agent permissions.** Five Eyes guidance co-authored by NCSC New Zealand says agentic AI should never get broad or unrestricted access, and high-impact actions need human approval ([NCSC](https://www.ncsc.govt.nz/protect-your-organisation/careful-adoption-of-agentic-ai-services/)). See [agent permissions and approvals](/engineering/agent-permissions-and-approvals/).

## Next step

Make sure your [AI use policy](/resources/ai-use-policy-template-for-nz-smbs/) contains the controls the register depends on. For an independent review of high-scoring risks, see our [AI security reviews](/services/ai-security-review/) and [AI governance advisory](/services/ai-governance/).

## Questions people ask

### How do you do an AI risk assessment?

List each AI system and what it can see and do. For each, write down what could go wrong as a cause, event and impact, then score likelihood and impact from 1 to 5. Add the controls that reduce each risk, re-score the residual risk, and give every risk an owner and a review date. Repeat whenever the system, model or data changes.

### Which AI risk frameworks should a New Zealand business use?

There is no single mandatory one. The NIST AI Risk Management Framework is a free, voluntary structure built on four functions: govern, map, measure and manage. The OWASP Top 10 lists the main security risks for LLM applications and agents. ISO/IEC 42001 is the international management system standard. MBIE's Responsible AI Guidance for Businesses lists the risk areas New Zealand businesses should consider.

### What are the biggest risks of using generative AI in a business?

Common ones are personal or confidential information going where it should not, confident wrong answers being relied on, prompt injection through emails or documents, AI agents with more access than they need, and dependence on a supplier who changes or retires models. The starter risks on this page cover each, with typical controls.

### Do we need ISO/IEC 42001 certification?

Usually not, unless clients or tenders ask for it. ISO/IEC 42001 sets requirements for an AI management system, and certification is voluntary and done by independent certification bodies, not ISO itself. A well-kept risk register, policy and incident log give you most of the practical benefit and a head start if certification is needed later.


## Sources

- [AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)
- [Generative Artificial Intelligence Profile (NIST AI 600-1)](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf)
- [OWASP Top 10 for LLM Applications 2026](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/)
- [OWASP Top 10 for Agentic Applications for 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/)
- [ISO/IEC 42001:2023 Artificial intelligence management system](https://www.iso.org/standard/42001)
- [Responsible AI Guidance for Businesses](https://www.mbie.govt.nz/assets/responsible-ai-guidance-for-businesses.pdf)
- [Careful Adoption of Agentic AI Services](https://www.ncsc.govt.nz/protect-your-organisation/careful-adoption-of-agentic-ai-services/)
- [Managing psychosocial risks at work](https://www.worksafe.govt.nz/topic-and-industry/work-related-health/mental-health/managing-psychosocial-risks-at-work/)

Published by Levy Street (https://levystreet.com), Wellington, New Zealand.