Most compliance officers I talk to already have a risk register. It lives in a spreadsheet or a GRC tool, it covers cybersecurity, vendors, privacy and regulatory change, and it gets reviewed every quarter. Then the business starts deploying AI, and somebody asks where the AI risks are. The usual answer is to add three rows under "Technology" and call it done.
I don't think that works, and the frameworks don't either. An AI risk register has to track things a traditional register never needed to: model drift, training data provenance, bias against specific groups of people, explainability, and the fact that a vendor can change a model underneath you without telling you. This guide gives you a template you can copy, explains each field, and shows how the register ties into ISO/IEC 42001:2023, the NIST AI Risk Management Framework and the EU AI Act, so that one document can serve all three.
What is an AI risk register?
An AI risk register is a living record of the specific ways your AI systems could cause harm to people or to your organization, how likely and how serious each one is, who owns it, what controls are in place, and what you plan to do next. The word that matters is "specific." A line that says "AI bias" is a topic. A line that says "resume-screening model ranks candidates with employment gaps lower, disproportionately affecting caregivers" is a risk.
It is different from an AI inventory, though the two depend on each other. The inventory lists what AI you have. The register lists what could go wrong with it. If you cannot name every AI system in use, including the ones embedded in vendor software and the ones employees adopted on their own, the register will have blind spots from day one. Start with the inventory if you don't have one.
Which frameworks require an AI risk register?
None of the major frameworks use the phrase "risk register" as a mandated deliverable, but each one requires the documented content a register holds. That distinction is worth knowing, because an auditor will ask for evidence of the process, and the register is the most natural place to show it.
| Framework | Where it asks for risk documentation | What it expects |
|---|---|---|
| ISO/IEC 42001:2023 | Clauses 6.1.2 (AI risk assessment), 6.1.3 (AI risk treatment), 8.2 and 8.3 (operational execution) | Defined risk criteria, documented assessment results, a risk treatment plan, and a Statement of Applicability against Annex A |
| ISO/IEC 42001:2023 | Clauses 6.1.4 and 8.4 (AI system impact assessment) | Assessment of consequences for individuals and society, kept separate from organizational risk |
| NIST AI RMF 1.0 (NIST AI 100-1, January 2023) | MAP, MEASURE and MANAGE functions, supported by GOVERN | Identified risks in context, measured against metrics, prioritized and treated, with accountability set by governance |
| EU AI Act, Regulation (EU) 2024/1689 | Article 9 (risk management system for high-risk AI systems) | A continuous, iterative process across the whole lifecycle, documented and kept up to date |
| ISO/IEC 23894:2023 | Whole standard | Guidance on applying ISO 31000 style risk management to AI |
Three details in that table are worth pausing on. ISO/IEC 42001:2023 clause 8.2 requires the AI risk assessment to be performed at planned intervals or when significant changes are proposed or occur, which means a register reviewed once a year with no change trigger will not satisfy it. Article 9 of the EU AI Act describes risk management for high-risk systems as a continuous iterative process planned and run throughout the entire lifecycle, so a point-in-time snapshot is the wrong shape. And ISO/IEC 42001 treats the AI system impact assessment as its own activity under clause 6.1.4, which is a common place for teams to get tangled, so I'll come back to it below.
If you are weighing whether to certify against ISO/IEC 42001, a gap assessment will show you how much of your current register already meets the clause requirements and how much needs rebuilding.
What fields should an AI risk register include?
Here is the template I would start from. You can build it in Excel, Airtable or whatever GRC platform you already use. The columns matter more than the tool.
| # | Field | What goes in it | Why it is there |
|---|---|---|---|
| 1 | Risk ID | Unique, stable identifier (e.g., AIR-014) | Lets audit findings, incidents and treatment actions point back to one row |
| 2 | AI system | Name and version, linked to the AI inventory | Ties the risk to something real |
| 3 | Business owner | Named person accountable for the system's use | Clause 5.3 of ISO/IEC 42001 requires assigned roles and responsibilities |
| 4 | Risk owner | Named person accountable for the risk | Often the same person, but not always |
| 5 | Lifecycle stage | Design, development, validation, deployment, operation, retirement | Risks change as the system moves through stages |
| 6 | Risk description | Cause, event, consequence in one or two sentences | Forces specificity |
| 7 | Risk category | Fairness, safety, security, privacy, transparency, reliability, third-party, legal | Lets you report across systems |
| 8 | Affected parties | Customers, employees, applicants, patients, the public | Feeds the impact assessment |
| 9 | Inherent likelihood | 1 to 5 | Before any controls |
| 10 | Inherent impact | 1 to 5 | Before any controls |
| 11 | Inherent score | Likelihood × impact | Prioritization |
| 12 | Existing controls | What is already in place, with a pointer to the evidence | Shows what you actually do |
| 13 | Residual likelihood and impact | Re-scored with controls | Shows what is left over |
| 14 | Treatment decision | Mitigate, transfer, avoid, accept | Matches the options in clause 6.1.3 |
| 15 | Annex A control reference | e.g., A.5, A.6, A.7 | Feeds the Statement of Applicability |
| 16 | Action, owner, due date | The next concrete step | Without a date it is a wish |
| 17 | Review trigger and next review date | Scheduled date plus event triggers | Satisfies the "planned intervals or significant change" language |
| 18 | Status | Open, in treatment, accepted, closed | Reporting |
| 19 | Evidence link | Test results, approval records, monitoring dashboards | What the auditor will ask for |
You do not need every column on day one. If you are starting from nothing, I would begin with fields 1 to 8, 11, 12, 14 and 16, then add the rest as the process matures. A register with ten honest columns beats one with nineteen columns that nobody fills in.
How do you score AI risks?
Use the scoring scale your organization already uses for enterprise risk, because ISO/IEC 42001 clause 6.1.2 asks you to establish AI risk criteria, and consistency with existing criteria makes the board conversation easier. A 5×5 matrix is the most common.
A simple convention that works for most teams:
| Score (L × I) | Rating | Typical response |
|---|---|---|
| 1 to 4 | Low | Accept and monitor |
| 5 to 9 | Moderate | Treat within the normal review cycle |
| 10 to 15 | High | Treatment plan with a named owner and date; report to the AI governance committee |
| 16 to 25 | Critical | Escalate to top management; consider pausing deployment |
Those thresholds are my suggestion, not something written in any standard, so adjust them to your own appetite. The point is that your criteria are written down and applied the same way every time.
Two AI-specific scoring problems deserve attention. First, impact should be scored from two directions: harm to the organization (fines, litigation, reputational damage) and harm to the people the system affects. A model can be a trivial risk to the company and a serious one to an individual applicant. ISO/IEC 42001 separates these on purpose, with organizational risk under 6.1.2 and individual and societal consequences under 6.1.4, and I would score them in separate columns if your system affects people in consequential decisions like hiring, credit, housing, insurance or healthcare.
Second, likelihood is hard to estimate for a model whose behavior you cannot fully predict. In my view the honest approach is to base likelihood on evidence you can collect, such as test results, error rates by subgroup, incident history and monitoring data, rather than a gut call. If you have no evidence, score likelihood conservatively and make "generate evidence" the treatment action.
What do real AI risk register entries look like?
Abstract templates are easy to nod at and hard to use, so here are three sample rows, simplified to fit on a page.
| Field | Entry 1 | Entry 2 | Entry 3 |
|---|---|---|---|
| Risk ID | AIR-001 | AIR-002 | AIR-003 |
| AI system | Resume-screening model (vendor-supplied) | Customer service chatbot using a large language model | Third-party fraud scoring API |
| Description | Model ranks candidates with employment gaps lower, producing disparate outcomes for caregivers and leading to discrimination claims | Chatbot states an incorrect refund or regulatory policy with confidence, and a customer relies on it | Vendor updates the model without notice, shifting false-positive rates and blocking legitimate customers |
| Category | Fairness, legal | Reliability, transparency | Third-party, reliability |
| Inherent score | 4 × 5 = 20 | 4 × 3 = 12 | 3 × 4 = 12 |
| Existing controls | Annual vendor attestation | Disclaimer text | Contract with SLA only |
| Treatment | Mitigate: subgroup testing before each release, human review of all rejections | Mitigate: restrict to approved knowledge base, human handoff for policy questions, log and sample conversations | Mitigate: contractual change-notification clause, shadow testing before adopting new versions |
| Residual score | 2 × 4 = 8 | 2 × 3 = 6 | 2 × 3 = 6 |
| Annex A area | A.5, A.6, A.9 | A.8, A.9 | A.10 |
Notice that every treatment is something somebody could do on Monday morning and prove on Friday. If a treatment reads like a value statement, such as "ensure responsible AI use," it is not ready to go in the register.
How do you build the register step by step?
I would work through it in this order.
1. Build or refresh the AI inventory. Include vendor tools with embedded AI, generative AI use by staff, and models built internally. Record purpose, data used, users and affected parties.
2. Classify each system. For the EU AI Act, that means checking whether a system is a prohibited practice under Article 5, a high-risk system under Article 6 and Annex III, or something lower. For ISO/IEC 42001, it means deciding which systems are in scope of the AI management system. Classification drives how deep the register entries need to go.
3. Run workshops by system, not by risk type. Put the product owner, data scientist, security, legal, privacy and the affected business unit in a room for each material system. Risk identification done by compliance alone produces generic entries.
4. Write risks as cause, event, consequence. "Training data underrepresents applicants over 55, so the model scores them lower, causing discriminatory outcomes" is a risk. "Bias" is a heading.
5. Score, then identify controls. Score inherent risk first so you can see what your controls are actually buying you.
6. Choose a treatment and map to Annex A. ISO/IEC 42001 clause 6.1.3 requires you to determine the controls necessary to implement your treatment options, compare them with Annex A, and produce a Statement of Applicability. Annex A contains 38 controls grouped under nine control objectives, covering areas such as AI policies, internal organization, resources, assessing impacts of AI systems, the AI system life cycle, data for AI systems, information for interested parties, use of AI systems and third-party relationships. Mapping each risk to those control areas as you go means the Statement of Applicability nearly writes itself.
7. Set review triggers. Beyond a calendar date, define events that force a re-score: a model retrain, a new data source, a change of vendor model version, a new use case, a complaint, an incident, or a regulatory change.
8. Report upward. Give top management a short view of critical and high risks, overdue actions and accepted risks. ISO/IEC 42001 clause 9.3 requires management review to consider inputs on the AI management system's performance, and the register is a natural source.
How does the register connect to the AI impact assessment?
This is where I see the most confusion. The risk register covers risks to the organization's objectives, which includes legal and reputational exposure. The AI system impact assessment under ISO/IEC 42001 clauses 6.1.4 and 8.4 looks at consequences for individuals, groups and society. Under the EU AI Act, deployers of certain high-risk systems face a related duty to assess fundamental rights impact under Article 27.
They are different documents with different questions, but they should feed each other. A serious harm identified in an impact assessment becomes a register entry with an owner and a treatment. A register risk with serious third-party consequences should trigger an impact assessment if one has not been done. If you keep them in silos, you will end up with a tidy register that misses the people actually affected.
How does this map to NIST AI RMF?
If your organization uses the NIST framework, the register is how you evidence three of its four functions. MAP is where risks are identified in context, MEASURE is where you attach metrics and test results to the likelihood and impact scores, and MANAGE is where treatment, prioritization and response live. GOVERN sits behind all of it: the policies, roles and risk tolerance that make the scores meaningful. For generative AI, NIST published the Generative AI Profile (NIST AI 600-1) in July 2024, which lists risks such as confabulation, data privacy and information integrity that are worth using as prompts when you populate entries for chatbots and content tools.
Financial services teams have one more reference point. The Federal Reserve and OCC guidance on model risk management, SR 11-7 (April 2011), predates modern AI but already expects model inventories, validation and ongoing monitoring, and examiners often apply it to machine learning models. Your register should be consistent with whatever model risk process you already run, and not duplicate it.
What mistakes make AI risk registers useless?
A few patterns come up again and again.
- Generic entries. "Model may be biased" tells nobody what to do. Name the system, the group and the mechanism.
- No link to the inventory. Shadow AI never appears, so the register describes a company that does not exist.
- Scoring without evidence. If likelihood is a guess, say so and make evidence collection the action.
- Treating the vendor as the owner. Buying a model does not transfer accountability to the vendor. ISO/IEC 42001 Annex A has a control area for third-party and customer relationships precisely because responsibility has to be allocated and verified.
- One review a year. Models change faster than annual cycles, and clause 8.2 calls for reassessment when significant changes occur.
- Accepting risk without a name. Every accepted risk should carry the name of the person with authority to accept it and a date to revisit.
- Keeping the register in compliance only. The register is most useful when the engineers who change the model can see it and update it.
Honestly, the register is only as good as the conversations behind it. I have seen very plain spreadsheets outperform expensive platforms because the people in the room told the truth about what the model did.
How often should the register be reviewed?
I would use three layers. Review the top risks monthly in an AI governance meeting, review the full register at least quarterly, and re-score any entry within a set number of days after a trigger event. The standard does not prescribe those intervals; ISO/IEC 42001 says planned intervals, and you decide what is reasonable for your risk profile. A company running a handful of low-stakes internal tools can justify a lighter cadence than one running credit decisions. Write the cadence down, follow it, and keep the meeting minutes, because that is the evidence an auditor will look for.
Where should you start this week?
If you only have a few hours, do this: list your ten most consequential AI systems, assign a named owner to each, and write one specific, scored risk for each. That gives you a register with real content you can improve, and it exposes the gaps in your inventory and ownership faster than any planning document will.
If you are building toward ISO/IEC 42001 certification and want help aligning the register, the impact assessment and the Statement of Applicability, our ISO 42001 consulting page explains how we work with compliance teams. What is the one AI system in your organization that you would least like to explain to a regulator tomorrow? Start your register there.
Last updated: 2026-11-05
Frequently Asked Questions
Is an AI risk register required by ISO/IEC 42001?
ISO/IEC 42001:2023 does not use the term, but clauses 6.1.2, 6.1.3, 8.2 and 8.3 require documented AI risk assessment results and a risk treatment plan, and a register is the most practical way to hold that evidence. Clause 6.1.3 also requires a Statement of Applicability against Annex A.
What is the difference between an AI inventory and an AI risk register?
The inventory lists the AI systems your organization builds, buys or uses, along with purpose, data and owners. The register lists the specific risks each system creates, how they are scored, what controls exist and what treatment is planned. The register depends on the inventory being complete.
How is an AI risk register different from an AI system impact assessment?
The register focuses on risks to the organization's objectives, including legal and reputational exposure. The AI system impact assessment under ISO/IEC 42001 clauses 6.1.4 and 8.4 examines consequences for individuals, groups and society. They should feed each other, but they answer different questions.
How often should an AI risk register be updated?
ISO/IEC 42001 clause 8.2 calls for AI risk assessments at planned intervals and when significant changes are proposed or occur. In practice that means a scheduled review, such as quarterly, plus re-scoring after triggers like a model retrain, new data source, vendor model change or incident.
Who should own the AI risk register?
Compliance or risk management usually maintains the register, but each risk should have a named risk owner in the business or technical team that controls the system. Top management stays accountable for risk acceptance decisions and receives summary reporting.
Jared Clark
Principal Consultant, Certify Consulting
Jared Clark is the founder of Certify Consulting, helping organizations achieve and maintain compliance with international standards and regulatory requirements.