Documented AI safety incidents climbed from 149 in 2023 to 233 in 2024 a 56% jump in a single year, according to the Stanford HAI 2025 AI Index Report. The pace is accelerating in 2025, while the EU AI Act’s risk management obligations are now in force and ISO/IEC 42001 certification is becoming a procurement gate for enterprise software contracts. The single artifact that decides whether your AI governance program can survive contact with an auditor is the AI risk register. This guide covers what belongs in one, how to score and treat the entries, how to map a single register across ISO 42001, the EU AI Act, and the NIST AI Risk Management Framework, and how to keep it useful after launch.
What an AI Risk Register Actually Is (and Why a Spreadsheet Isn’t Enough)
An AI risk register is a living inventory of identified risks across an organisation’s AI systems capturing each risk’s likelihood, impact, owner, controls, treatment plan, and residual exposure used to evidence compliance under ISO/IEC 42001, the EU AI Act, and the NIST AI Risk Management Framework. It is the operational backbone of an AI management system (AIMS). Every governance commitment fairness, transparency, human oversight eventually has to land here as a row.
Most teams already maintain an operational or IT risk register, and the temptation is to bolt AI risks onto it. That works for about a quarter, then breaks. AI risks behave differently. They are dynamic in ways traditional software risks are not: a model that passed fairness testing in March can fail it in October because the input distribution shifted, not because anyone changed the code. They are socio-technical, meaning impact assessment has to consider individuals and society, not just the organisation. And they are often inherited when you embed a foundation model API, you accept whatever risks the upstream provider hasn’t disclosed.
The other reason a generic spreadsheet stops working: by the second or third audit cycle, you need version history per row, evidence links per control, mapping to multiple framework references, and the ability to filter by risk owner, system class, or regulatory exposure. Spreadsheets do none of this well.
Traditional Risk Register vs. AI Risk Register
| Element | Traditional Risk Register | AI Risk Register |
|---|---|---|
| Risk source | Process, system, vendor | Model, data, system, vendor, prompt |
| Risk character | Static: re-scored quarterly | Dynamic: drift, retraining, prompt evolution |
| Impact dimension | Financial, operational, legal | Financial, operational, legal, fairness, safety, societal |
| Required mapping | Internal policy | ISO 42001, EU AI Act, NIST AI RMF, sectoral rules |
| Evidence types | Policy, control attestation | Model cards, AIIA, test results, monitoring telemetry |
| Refresh trigger | Annual review | Incident, drift threshold, regulatory change, data update |
Why You Need One Now: ISO 42001, the EU AI Act, and NIST AI RMF
Three frameworks now expect the register to exist, even if none of them uses that exact phrase. Understanding what each requires is what lets you build one register instead of three.
ISO/IEC 42001:2023.
Clauses 6.1.2 through 6.1.4 require a documented AI risk assessment process, an AI risk treatment process, and a separate AI system impact assessment focused on individuals and society. Clause 8.2 requires operational implementation of the resulting controls. Clauses 9 and 10 require ongoing monitoring and continual improvement. The register is how you evidence all of it. ISO/IEC 42005, published in 2025, gives more detailed guidance on the impact assessment piece. The standard does not prescribe a register format it prescribes outcomes that, in practice, only a register can satisfy.
EU AI Act (Regulation (EU) 2024/1689).
Article 9 requires providers of high-risk AI systems to “establish, implement, document and maintain a risk management system” running across the entire AI lifecycle. The article specifies risk identification, estimation and evaluation, treatment of residual risk, and testing. Each of those is a column or process step in a register. For organisations using general-purpose AI (GPAI) models, transparency and governance obligations begin earlier than the heavy high-risk duties meaning your register needs a third-party model dimension from day one.
NIST AI Risk Management Framework.
The NIST AI RMF organises AI risk work into four functions: GOVERN, MAP, MEASURE, MANAGE. MAP outcomes assume an inventory of AI systems and their risks. MEASURE outcomes assume scoring and metrics per risk. MANAGE outcomes assume treatment decisions, monitoring, and incident response. The framework is voluntary, but US federal agencies and regulators reference it heavily, and NIST guidance treats the register as an integration point with existing enterprise risk processes.
Adoption is no longer experimental. A Cloud Security Alliance 2025 compliance benchmark found that 76% of organisations plan to pursue ISO 42001 or aligned frameworks. [VERIFY] Procurement teams in regulated industries are starting to require the register itself as part of vendor onboarding not just an attestation that one exists.
What Belongs in an AI Risk Register: The Fields That Actually Matter
A register is only as useful as the questions it can answer under audit pressure. The fields below are what auditors and risk committees actually ask about. Skip any of them and the register becomes a document, not an instrument.
| Field | Purpose | Example Value |
|---|---|---|
| Risk ID | Stable reference for cross-linking | AIR-2026-014 |
| Linked AI system | Connects risk to inventory entry | SUP-CHAT-01 (customer support chatbot) |
| Risk description | Specific, testable risk statement | Chatbot generates non-compliant pricing claims for EU customers |
| Risk category | Taxonomy reference | Hallucination / regulatory exposure |
| Lifecycle stage | Where the risk arises | Deployment / inference |
| Likelihood | Scored against documented criteria | L3 (Likely, observed in pre-launch testing) |
| Impact | Multi-dimensional severity | I4 (Major regulatory fine + customer harm) |
| Inherent risk score | Likelihood × Impact pre-control | 12 (High) |
| Existing controls | Mapped to ISO 42001 Annex A and internal | A.6.2.4 input validation; A.7.4 human oversight |
| Residual risk score | Post-control | 6 (Medium) |
| Treatment | Accept / avoid / transfer / mitigate | Mitigate add jurisdiction-specific output filter |
| Owner | Named individual with budget authority | Head of Customer Operations |
| Review date | Next mandatory review | 2026-07-15 |
| Evidence links | URLs to test results, AIIA, model card | Model card v2.3; pre-launch eval report; incident #INC-1108 |
| Framework references | ISO 42001 / EU AI Act / NIST | ISO 42001 Cl. 6.1.3; EU AI Act Art. 9; NIST AI RMF MANAGE 2.3 |
Two fields cause the most argument in implementation: “Risk description” and “Owner.” Vague descriptions like “model bias” cannot be tested, treated, or closed they survive audit cycles indefinitely as low-effort placeholders. A testable description names the system, the failure mode, the affected population, and the consequence. Ownership is the second weak point: assigning a risk to someone without budget authority is a near-guarantee that the treatment will not be implemented. The owner field should sit with the person who can spend money to fix it, not the person who first reported it.
The framework references column is what makes a single register defensible across multiple audits. Done well, it lets you produce ISO 42001 evidence, EU AI Act technical documentation, and NIST AI RMF reporting from the same dataset.
Building Your First AI Risk Register: A Practical Sequence
There is a correct order for this work, and most teams who get stuck got the order wrong. The sequence below assumes you have nothing no inventory, no scoring methodology, no formal AIMS. If you already have some pieces, start at the step that matches your maturity.
- Build the AI inventory first. You cannot register risks for systems you cannot name. Capture system name, owner, business purpose, data inputs, decision impact, model provider, deployment stage, and a preliminary EU AI Act risk class. Without this, the register is just a list of fears.
- Run a shadow AI discovery pass. Most enterprise environments contain three to five times more AI systems than central IT believes. DLP scans for OpenAI and Anthropic API calls, expense reports for AI tool subscriptions, and SaaS audit logs are the fastest discovery vectors. Add what you find to the inventory before scoring anything.
- Define risk criteria and risk appetite in writing before scoring. If “high impact” is undefined, every score is arbitrary, and your register fails its first internal audit. The criteria should fit on one page. Approve them at the AI governance committee level.
- Identify risks per system using a fixed taxonomy. The categories in the next section give you a starting taxonomy. Apply it consistently auditors look for a method, not a long list.
- Score inherent risk before considering controls. Resist the urge to credit existing controls in the first scoring pass. The inherent score is the audit’s reference point for whether your treatment is proportionate.
- Map existing controls to ISO 42001 Annex A. Many AI risks are already partially treated by existing information security, data protection, or change management controls. Mapping them avoids inventing new controls that duplicate what your ISO 27001 program already does.
- Score residual risk and decide treatment. Four options: accept, avoid, transfer, mitigate. The treatment decision must be recorded with a rationale, not just a verb.
- Assign owners with budget authority. This is the difference between a register that drives action and one that catalogues regret.
- Set review cadence per risk class. Critical risks reviewed quarterly. High risks half-yearly. Medium and low annually unless triggered by an incident or threshold breach.
- Link evidence on the way in, not at audit time. Model cards, AIIA outputs, test results, monitoring dashboards. If the link does not exist when the entry is created, it usually never gets added.
The first pass typically takes a focused team between four and eight weeks for an organisation with ten to thirty AI systems. The figure stretches significantly if shadow AI discovery surfaces a long tail of unsanctioned tools which it almost always does.
Identifying AI-Specific Risks (the Categories That Don’t Exist in Your Old Register)
Six risk categories show up in nearly every mature AI risk register. They map cleanly to ISO 42001 Annex A and the NIST AI RMF, and they cover most of what the EU AI Act expects providers to address.
Model drift and degradation
Performance decays over time as input distributions shift, user behaviour changes, or upstream APIs update. A fraud detection model trained on 2024 transaction patterns starts missing 2026 patterns. Drift is not a failure of the model it is a failure to monitor for it. Register entries for drift risk should specify the system, the degradation type (accuracy, bias, latency), the monitoring metric, and the threshold that triggers retraining or rollback.
Bias and fairness failures
Disparate impact across protected characteristics, training data skew, and feedback loops that reinforce historical patterns. Generic entries here (“model bias”) fail audits. Useful entries name the protected attribute, the affected population, the metric used (demographic parity, equalised odds, calibration), and the testing schedule.
Hallucination and factual integrity
Specific to generative systems. The risk is that the model produces plausible content that is wrong, unattributed, or fabricated. The register entry should distinguish low-stakes hallucination (a marketing email rewrite) from high-stakes hallucination (a clinical summary, a legal citation, a financial figure). The treatments differ: retrieval-augmented generation, mandatory human review, output validation, and refusal patterns.
Data risks
Poisoning, leakage, IP contamination, training data provenance gaps. If you cannot prove what data trained your model, you cannot defend it under copyright challenges, GDPR data subject requests, or EU AI Act technical documentation requirements. Register entries should reference your AI bill of materials (AI-BOM) and any data lineage documentation.
Third-party and GPAI dependency risk
When you embed a foundation model from OpenAI, Anthropic, Google, or Meta, you inherit risks you cannot directly control: undisclosed training data, silent model updates, content moderation changes, and cross-tenant exposure. The Schellman analysis of ISO 42001 risk treatment describes a practitioner case where cross-tenant residual risk was formally accepted because the organisation had no commercial leverage to negotiate single-tenancy. That is a defensible decision when documented; it is a finding when it is not.
Adversarial and security risks
Prompt injection, model extraction, jailbreaks, and adversarial inputs. The threat-modelling techniques referenced in ISO 42001 implementation guidance STRIDE, LINDDUN, OWASP for ML give a structured way to enumerate these. Register entries here often overlap with the existing infosec risk register; the rule of thumb is that if the risk is uniquely AI-shaped (only meaningful because the system is a model), it sits in the AI register with a cross-reference.
Scoring and Treating AI Risks Without Faking the Math
Risk scoring is where most registers lose credibility. “High / Medium / Low” without thresholds is a colour code, not an assessment. The scoring methodology has to be defensible in writing, applied consistently, and reviewed by someone who did not assign the original score.
Likelihood scales need concrete trigger conditions.
Avoid “unlikely” and “likely” without anchors. Useful scales attach a probability range, an observed-incidence threshold, or a defined precondition. For example: L1 (Rare no occurrences in industry-comparable systems in 24 months); L3 (Likely observed in our pre-launch testing); L5 (Almost certain has occurred in production within the last 90 days).
Impact must be multi-dimensional.
Traditional registers score impact along financial and operational axes. AI risk demands more. The EU AI Act explicitly expects assessment of impact on health, safety, and fundamental rights. ISO/IEC 42005 expects impact assessment to consider individuals and groups affected by the AI system. Practical impact dimensions for an AI register: financial, operational, legal/regulatory, reputational, and individual/societal harm. The composite impact score is the highest score across the dimensions, not the average.
Inherent versus residual.
Inherent score assumes no controls. Residual score is post-control. The gap between them is your evidence that the treatment is doing something. If inherent and residual are identical, either the controls are absent or the scoring is performative.
Treatment options, with AI-specific examples.
- Accept used for residual risks below appetite. Document the rationale and the review trigger. Example: cross-tenant residual risk on a major foundation model API where commercial leverage to require single-tenancy is absent.
- Avoid do not deploy the system, or do not deploy it in a specific jurisdiction or use case. Example: declining to deploy a generative recommendation model for under-18 users in jurisdictions with strict youth protection rules.
- Transfer through vendor SLA, indemnification, or insurance. Be specific: AI-specific cyber insurance is still a developing market, and many policies exclude generative AI claims.
- Mitigate apply controls. ISO 42001 Annex A is the canonical reference, covering policy, organisation, AI lifecycle, data, information for stakeholders, third-party relationships, and use of AI systems.
Residual risk above appetite must be approved at the level your governance policy specifies typically the AI governance committee or executive risk owner. The register should record who approved the residual position and when. Silent acceptance is the failure mode auditors look for first.
Mapping Your Register Across ISO 42001, the EU AI Act, and NIST AI RMF
You do not need three registers. You need one register with three reference columns. The crosswalk below shows how a single risk entry maps to obligations under each framework. Keeping these mappings explicit is what lets you produce framework-specific reports without rebuilding the underlying data.
| Register Element | ISO 42001 | EU AI Act | NIST AI RMF |
|---|---|---|---|
| Risk identification | Clause 6.1.2 | Article 9(2)(a) | MAP 1, MAP 2, MAP 3 |
| Risk analysis (likelihood × impact) | Clause 6.1.2 | Article 9(2)(b) | MEASURE 1, MEASURE 2 |
| Impact on individuals / society | Clause 6.1.4 + ISO 42005 | Article 9(2)(c) + Article 27 (FRIA) | MAP 5, MEASURE 3 |
| Risk treatment | Clause 6.1.3, Annex A | Article 9(2)(d), Article 9(5) | MANAGE 1, MANAGE 2 |
| Testing of controls | Clause 8.2, Annex A | Article 9(6)–(8) | MEASURE 1, MEASURE 4 |
| Operational monitoring | Clause 9.1 | Article 9(2)(e), Article 72 | MANAGE 4 |
| Incident handling | Clause 10.1 | Article 73 (serious incidents) | MANAGE 4 |
| Management review | Clause 9.3 | Article 9(2) (continuous, iterative) | GOVERN 1, GOVERN 5 |
Worked example: take the chatbot pricing-claim risk from the field table earlier. The same single row supports an ISO 42001 audit (evidence under Clauses 6.1.2 to 8.2), an EU AI Act technical file (Article 9 risk management documentation), and a NIST AI RMF profile reporting view (MAP/MEASURE/MANAGE outcomes). The reference columns are what make this possible.
Maintaining the cross-framework mappings manually is where teams typically lose two to three weeks per audit cycle. This is the work platforms like Govern365.ai’s AI model registry automate each register entry is mapped to the relevant ISO 42001 Annex A control, EU AI Act article, and NIST AI RMF subcategory simultaneously, with the evidence trail attached.
Keeping the Register Useful: Maintenance, Cadence, and Drift
A register that is built once and reviewed annually is a register that is wrong eight months a year. AI systems change continuously, and the maintenance pattern has to match. Different fields have different correct refresh cadences.
| Field type | Cadence | Trigger |
|---|---|---|
| AI inventory entries | Monthly + change-driven | New system deployed; vendor change; significant model update |
| Risk descriptions | Quarterly review | Incident; near-miss; new failure mode observed |
| Likelihood / impact scores | On trigger | Drift threshold breach; incident; regulatory change |
| Existing controls | Quarterly | Control failure; framework update; audit finding |
| Residual risk and treatment | Quarterly for High; half-yearly for Medium | Score change; control change |
| Owner assignments | Annually | Role changes; reorganisation |
| Framework references | On framework update | ISO/EU/NIST publishes new version or guidance |
Two practical rules separate registers that get used from registers that get archived. First, drift triggers must be defined per system class, not globally. A 2% accuracy drop matters in a clinical decision support tool and is noise in a marketing personalisation engine. Document the threshold against the system, not the policy. Second, tie register reviews to existing forums the architecture review board, the change advisory board, the existing risk committee rather than creating a new monthly meeting nobody attends.
Every AI incident must close with a register update. The link between incident management and the register is what makes both mature. If an incident did not surface a register entry that should have existed, the register has a coverage gap. ISO 42001 Clause 9.3 requires management review at planned intervals, and the register is the input incomplete maintenance shows up immediately.
Where Most AI Risk Registers Fail
Six failure modes account for most of the implementation problems we see. They are recoverable, but they get expensive once an audit cycle has run with them in place.
Treating it as a one-time deliverable
Built for the certification audit, then frozen. Twelve months later, the inventory is wrong, scores are stale, and treatment plans reference controls that no longer exist. The register is a continuous artifact design it as one from the start.
Owners assigned without budget authority
A risk owned by someone who cannot fund the treatment will not be treated. Push ownership up until you reach a level that controls budget for the affected system, then document a deputy who runs the day-to-day work.
Generic risk descriptions that cannot be tested
“Model bias” survives audit cycles indefinitely. “Recommendation model produces 14% lower approval rate for applicants in postcode group X under threshold Y” is testable, treatable, and closeable. The latter takes longer to write. Write the latter.
Missing the link between entries and evidence
If an auditor cannot click from a register entry to the test results, model card, or AIIA that supports it, the entry does not satisfy the documentation expectation. Build the linking habit on entry creation; retroactive linking is the most common reason audit prep takes weeks.
Skipping the third-party / GPAI layer
Most early registers cover internally developed models well and external models almost not at all. Foundation model usage is the fastest-growing risk surface in most enterprises. Inventory the GPAI providers, the systems that use them, the contractual terms, and the residual risk separately.
Scoring drift over time
“High” in March no longer means what “High” meant the previous March because the criteria were never written down. Document the scoring scales. Re-validate them annually. Make changes traceable so historic scores remain interpretable.
The Infosys Knowledge Institute Responsible Enterprise AI study reported that 95% of enterprises had at least one AI-related incident, while only 2% met responsible AI “gold standards.” [VERIFY] The gap between those two numbers is largely about whether organisations have a register that is actually being used.
Frequently Asked Questions
What is an AI risk register?
An AI risk register is a structured inventory of identified risks across your AI systems, capturing each risk’s description, likelihood, impact, owner, controls, treatment, and residual exposure. It is the central artifact through which an organisation evidences AI risk management under ISO/IEC 42001, the EU AI Act, and the NIST AI Risk Management Framework. Unlike a generic risk register, it tracks model-specific risks like drift, hallucination, and bias.
How is an AI risk register different from a traditional risk register?
AI risks are dynamic, socio-technical, and often inherited from third-party model providers. A traditional register usually treats risk as static and re-scores quarterly. An AI register has to handle drift, fairness impacts, model updates, and GPAI dependencies. It also requires multi-framework mapping (ISO 42001, EU AI Act, NIST AI RMF) and links to specialised evidence types like model cards, AI impact assessments, and monitoring telemetry.
Is an AI risk register required for ISO 42001 certification?
ISO/IEC 42001 does not name the register as a required artifact, but Clauses 6.1.2 through 6.1.4 require documented risk assessment, risk treatment, and AI impact assessment processes — and Clause 8.2 requires their operational implementation. In practice, only a register satisfies all four. Auditors expect to see one. Organisations that arrive at certification audits without one typically receive non-conformities under Clauses 6 and 8.
What fields should an AI risk register include?
At minimum: Risk ID, linked AI system, risk description, risk category, lifecycle stage, likelihood, impact, inherent score, existing controls, residual score, treatment, owner, review date, evidence links, and framework references. The framework references column lets the same register support ISO 42001, EU AI Act, and NIST AI RMF reporting without duplication.
Who should own the AI risk register?
Overall ownership typically sits with the head of AI governance, the CISO, the chief risk officer, or general counsel whichever role has cross-functional authority in your organisation. Individual entries should be owned by the person with budget authority over the affected AI system, supported by a deputy who runs the day-to-day treatment work. Avoid assigning entries solely to risk analysts or compliance staff who lack remediation budget.
How often should an AI risk register be updated?
Different fields have different cadences. Inventory monthly. Risk descriptions quarterly. Likelihood and impact scores on trigger (incident, drift threshold, regulatory change). Owners annually or on role change. Framework references when the underlying standard publishes an update. The register should also be updated immediately after any AI incident or near-miss as part of incident closure.
Do I need separate registers for ISO 42001, the EU AI Act, and NIST AI RMF?
No. One register with explicit cross-references to each framework is more efficient and more auditable than three parallel registers. The frameworks ask similar questions in different language: identification, analysis, treatment, monitoring. A single register with mapping columns to ISO 42001 clauses, EU AI Act articles, and NIST AI RMF subcategories supports all three audiences and avoids version drift between copies.
Conclusion
An AI risk register is where governance promises become operational evidence. Specific, scored, owned, mapped, and maintained or it is not a register, it is a checklist that fails its first audit. The frameworks differ in language, but they ask the same underlying question: can you show, for every AI system you operate, what could go wrong, who owns it, and what you are doing about it?
The practical first step is the AI inventory. You cannot register risks for systems you cannot name, and most organisations discover during inventory that they have far more AI in production than central IT believed.Govern365.ai, by the Global AI Certification Council, gives compliance and AI governance teams a single platform for the AI model registry, risk assessment, control mapping across ISO 42001, the EU AI Act, and NIST AI RMF, and audit evidence management. Start your 14-day free trial and turn your register into something that holds up under audit pressure
