Loading
A working reference of 40 AI risk controls across eight domains — the defined, evidenceable measures behind a defensible AI governance program. Each control is mapped to ISO/IEC 42001, the NIST AI RMF functions, and where applicable the EU AI Act, so risk, compliance, and audit teams can speak one control language across frameworks.
Last reviewed: 7 June 2026 · Mappings are indicative working references, not a conformity claim
Jump to a domain
New to the discipline? Start with the AI GRC pillar guide for how these controls fit into an operating model, and the free assessment to see which domains need attention first.
The controls that make AI someone’s job. Everything else in the library depends on these existing first.
A board-endorsed policy stating what the organisation will and will not use AI for, who may approve new use cases, and the rules staff must follow. Reviewed on a defined cycle and whenever the regulatory position materially changes.
Maps to ISO 42001 A.2 · NIST AI RMF Govern · EU AI Act Art. 17
Every AI system in production has a named individual owner accountable for its performance, risk treatment, and compliance, not a team, a vendor, or “IT”.
Maps to ISO 42001 A.3 · NIST AI RMF Govern
AI appears on the board or risk-committee agenda on a defined cadence, with decision-useful reporting on the portfolio, top risks, incidents, and regulatory change.
Maps to ISO 42001 A.3 · NIST AI RMF Govern
A documented statement of the AI risk the organisation is willing to accept, by use-case category, against which proposals are triaged and escalations are judged.
Maps to ISO 42001 cl. 6 · NIST AI RMF Govern
A maintained register of every AI system, model, and material AI feature in use, including embedded vendor AI and approved staff tools, with owner, purpose, data, and risk tier recorded.
Maps to ISO 42001 A.4 · NIST AI RMF Map
Role-appropriate training: general staff on acceptable use, builders and approvers on risk and controls, and directors on enough technical substance to provide effective challenge.
Maps to ISO 42001 cl. 7 · NIST AI RMF Govern · EU AI Act Art. 4
The controls that sort the AI estate by potential for harm, so effort lands where the stakes are.
Every proposed and existing use case is classified into risk tiers using defined criteria, impact on people, decision consequence, data sensitivity, autonomy, and regulatory exposure, with controls scaled to the tier.
Maps to ISO 42001 A.5 · NIST AI RMF Map · EU AI Act Art. 6
A structured assessment for higher-tier systems covering intended use, affected parties, failure modes, and mitigations, completed before deployment and refreshed on material change.
Maps to ISO 42001 A.5 · NIST AI RMF Map · EU AI Act Art. 9
Use cases touching personal information or significantly affecting individuals trigger the applicable privacy impact assessment, and where in scope, a fundamental rights impact assessment.
Maps to ISO 42001 A.5 · EU AI Act Art. 27 · GDPR Art. 35
A named, sufficiently senior approver formally accepts residual risk before a higher-tier system goes live; the acceptance and its basis are recorded.
Maps to ISO 42001 cl. 6 · NIST AI RMF Manage · EU AI Act Art. 9
The controls over what the system learns from and what you feed it. Most AI failures trace back here.
Documented standards for the selection, sourcing, and approval of data used to train, fine-tune, ground, or prompt AI systems, with named data owners.
Maps to ISO 42001 A.7 · NIST AI RMF Map · EU AI Act Art. 10
Defined quality criteria, accuracy, completeness, currency, and representativeness for the population the system affects, checked before use and re-checked when data is refreshed.
Maps to ISO 42001 A.7 · NIST AI RMF Measure · EU AI Act Art. 10
For material systems, records of where data came from, what consents or licences attach to it, and how it was transformed, sufficient to answer a regulator or court.
Maps to ISO 42001 A.7 · NIST AI RMF Map · EU AI Act Art. 10
Personal information entering AI systems is limited to what the purpose requires, handled per the applicable privacy regime, and excluded from vendor training unless explicitly agreed.
Maps to ISO 42001 A.7 · Privacy law (GDPR / Privacy Act) · EU AI Act Art. 10
Inbound data and model licences are reviewed for restrictions on commercial use, and the IP position on AI outputs the organisation relies on is documented.
Maps to ISO 42001 A.7 · NIST AI RMF Map
The controls from design to retirement. Go-live is a milestone in the lifecycle, not the end of it.
Builds and significant configurations follow documented standards covering design decisions, assumptions, limitations, and intended operating conditions, producing the technical documentation regulators expect.
Maps to ISO 42001 A.6 · NIST AI RMF Map · EU AI Act Art. 11
Higher-tier systems pass defined acceptance tests for accuracy and reliability on realistic data, with results recorded and compared against documented thresholds before release.
Maps to ISO 42001 A.6 · NIST AI RMF Measure · EU AI Act Art. 15
Systems affecting people are tested for performance differences across relevant groups before deployment and on a defined cycle after it, with thresholds and remediation paths agreed in advance.
Maps to ISO 42001 A.6 · NIST AI RMF Measure · EU AI Act Art. 10
Higher-tier and externally exposed systems are stress-tested against adversarial and out-of-distribution inputs, including red-teaming for generative systems, before release and after material change.
Maps to ISO 42001 A.6 · NIST AI RMF Measure · EU AI Act Art. 15
Model versions, prompts, and configuration are version-controlled; material changes, including silent vendor model updates where detectable, go through change approval and regression testing.
Maps to ISO 42001 A.6 · NIST AI RMF Manage · EU AI Act Art. 11
A defined process for retiring AI systems: dependent processes identified, data handled per retention rules, and the inventory updated, so abandoned systems do not run ungoverned.
Maps to ISO 42001 A.6 · NIST AI RMF Manage
The controls for AI you buy rather than build, which, for most organisations, is now most of it.
Before signing, vendors answer a defined diligence set: training data and model provenance, security posture, data handling and retention, performance evidence, and incident history.
Maps to ISO 42001 A.10 · NIST AI RMF Govern · APRA CPS 230
Contracts for material AI services secure rights to information, audit, and notification of material model changes and incidents, plus exit and data-return provisions.
Maps to ISO 42001 A.10 · APRA CPS 230
Material AI dependencies are mapped through to the cloud hosts and foundation-model providers behind your vendors, with concentration assessed and contingency plans for the critical ones.
Maps to ISO 42001 A.10 · NIST AI RMF Map · APRA CPS 230
Material AI vendors are monitored through the relationship, service performance, control attestations, incident notifications, not only assessed at onboarding.
Maps to ISO 42001 A.10 · NIST AI RMF Manage · APRA CPS 230
The controls against attacks that target AI specifically, layered on top of conventional information security.
Higher-tier and externally exposed systems are threat-modelled for AI-specific attack paths, prompt injection, training-data poisoning, model extraction, and sensitive-data leakage through outputs.
Maps to ISO 42001 A.6 · NIST AI RMF Measure · EU AI Act Art. 15
Models, weights, training data, prompts, and AI system configuration are covered by least-privilege access control and the same joiner-mover-leaver discipline as other crown-jewel assets.
Maps to ISO/IEC 27001 · EU AI Act Art. 15 · APRA CPS 234
AI integrations are hardened: output handling that prevents injected instructions reaching downstream systems, constrained tool permissions for agents, and isolation of untrusted inputs.
Maps to ISO/IEC 27001 · EU AI Act Art. 15 · APRA CPS 234
Code produced with AI assistance passes the same review, testing, and dependency-scanning gates as human-written code, with no direct-to-production path.
Maps to NIST AI RMF Measure · APRA CPS 234
The controls that keep people informed and keep a human meaningfully in charge of consequential decisions.
People are told when they are interacting with an AI system, and AI-generated or materially AI-altered content is labelled where the law or the context requires it.
Maps to EU AI Act Art. 50 · NIST AI RMF Govern
For systems affecting people, the organisation can explain, at a level suited to the audience, what the system considers and why an individual outcome occurred.
Maps to NIST AI RMF Measure · EU AI Act Art. 13
Decisions that significantly affect people retain meaningful human involvement: overseers have the information, authority, competence, and time to intervene, not a rubber stamp.
Maps to ISO 42001 A.9 · EU AI Act Art. 14 & 26 · NIST AI RMF Govern
A working route for affected people to question an AI-influenced outcome and have it reviewed by a human with authority to change it, with timeframes and records.
Maps to ISO 42001 A.8 · NIST AI RMF Govern
Systems ship with, or vendors are required to provide, clear documentation of capabilities, limitations, intended use, and oversight requirements, and that information reaches the people operating the system.
Maps to ISO 42001 A.8 · EU AI Act Art. 13
The controls that catch degradation and failure in production, where AI risk actually materialises.
Production systems are monitored against defined performance indicators with alert thresholds, so accuracy decay and data drift are detected by instrumentation rather than by complaint.
Maps to ISO 42001 cl. 9 · NIST AI RMF Measure · EU AI Act Art. 72
For generative and decision-support systems, a defined sample of outputs is periodically reviewed by qualified humans against quality and safety criteria, with results fed back into thresholds and training.
Maps to ISO 42001 cl. 9 · NIST AI RMF Measure
Material systems keep logs sufficient to reconstruct what the system did and why, inputs, outputs, versions, and overrides, retained per regulatory and evidentiary requirements.
Maps to ISO 42001 A.6 · EU AI Act Art. 12 & 26
The organisation has defined what counts as an AI incident, who responds, how systems are contained or rolled back, and how affected parties are informed, and has tested the runbook.
Maps to ISO 42001 cl. 10 · NIST AI RMF Manage
Obligations to notify regulators of serious AI incidents are mapped by jurisdiction, with thresholds, timeframes, and ownership assigned before an incident occurs.
Maps to EU AI Act Art. 73 · NIST AI RMF Manage
Every material incident and near-miss produces a documented review, and the findings change something, a control, a threshold, a tier, or the inventory.
Maps to ISO 42001 cl. 10 · NIST AI RMF Manage
Do not start at GOV-01 and work through all forty. Start with the inventory (GOV-05) and tiering (RSK-01), because they tell you which controls each system actually needs — proportionality is the difference between a defensible program and a paper one. Then build domain by domain in the order the gaps hurt: for most vendor-heavy organisations that means third-party (TPR) and usage controls early; for builders, the model lifecycle (MDL) and data (DAT) domains carry the weight.
For implementation depth, see the ISO 42001 implementation guide, how to audit AI systems, and AI vendor due diligence. Australian financial-services readers should read the library alongside APRA’s AI expectations.
An AI control is a defined, repeatable, evidenceable measure that reduces a specific AI risk, for example, a maintained AI inventory, pre-deployment bias testing, or a human-oversight requirement for consequential decisions. Controls are the unit auditors and regulators work in: a policy states intent, a control is what you can show actually happens.
No. Proportionality is the point of risk tiering: an organisation using only vendor AI for low-stakes internal tasks needs a small subset, weighted toward governance, third-party, and usage controls, while an organisation deploying high-risk systems that affect people needs most of the library. The tiering controls (RSK-01 and RSK-02) exist precisely to tell you which of the others apply to each system.
ISO/IEC 42001 contains management-system clauses (4 to 10) and an Annex A control set organised into families covering policies, internal organisation, resources, impact assessment, the AI system life cycle, data, information for interested parties, responsible use, and third-party relationships. We map each control to the relevant clause or Annex A family. The mappings are indicative working references, not a conformity claim, certification requires assessment against the standard itself.
It depends on what you deploy and where. The EU AI Act makes specific controls binding for providers and deployers of high-risk systems, risk management, data governance, logging, human oversight, post-market monitoring, and serious-incident reporting among them, and APRA expects regulated Australian entities to apply existing prudential standards to AI. Outside those scopes, the controls are good practice that regulators, customers, and courts increasingly treat as the reasonable-steps baseline.
Each control should produce artefacts as a by-product of operating it: the inventory itself, tiering decisions, completed impact assessments, test results against recorded thresholds, signed risk acceptances, vendor diligence packs, monitoring dashboards, and incident reviews. If a control generates no artefact, it will be treated as not operating. Our guide to auditing AI systems covers how to structure that evidence.
Benchmark your organisation first, then come back to the library with a shortlist. The assessment takes minutes and maps directly onto these eight domains.
This library is general information and a working reference, not legal, financial, or compliance advice, and the framework mappings are indicative rather than a statement of conformity. Standards and regulatory requirements change and depend on your circumstances; always verify against the primary texts — ISO/IEC 42001, the NIST AI RMF, the EU AI Act, and your sector rules — and obtain advice from your own qualified counsel.
Model risk, cybersecurity, financial and legal risk, and the concrete controls that keep AI systems accountable.