AI Governance · Guide
AI controls: one control set for ISO 42001, NIST AI RMF and the EU AI Act
AI controls: one control set for ISO 42001, NIST AI RMF and the EU AI Act
Key takeaways
AI controls are the policies, technical measures and checks that keep an AI system within its purpose, risk appetite and legal duties. Build one set: extend your ISO 27001 controls, add AI-specific controls by lifecycle stage, give each one owner and one evidence source, map it once to ISO/IEC 42001, the NIST AI RMF and the EU AI Act, and test it once.
- NIST AI RMF functions
- The AI RMF Core has four functions: Govern, Map, Measure and Manage. NIST describes Govern as cross-cutting and says the framework's actions do not constitute a checklist.
- Deployer duties
- Under EU AI Act Article 26, deployers of high-risk systems follow the instructions for use, assign competent human oversight, monitor operation and keep logs for at least six months.
- High-risk timing
- Regulation (EU) 2026/1744 applies the high-risk requirements, including Articles 8 to 15, from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems.
- Generative AI Profile
- NIST AI 600-1 is a companion resource to the AI RMF. It defines risks novel to or made worse by generative AI and suggests actions for each function.
An enterprise customer's security questionnaire now has an AI section, and one question stops the reply: "Which controls govern your use of AI?" Your ISO 42001 plan asks the same thing in different words, and an EU customer's contract wants you to confirm your EU AI Act duties. This guide shows how to build one set of AI controls that answers all three.
It is written for founders, CTOs and compliance leads at UK tech firms of 25 to 250 people that build AI features or rely on third-party models. You will leave with a six-step method, the control families by name, what each framework expects, and a worked example of one control mapped three ways.
What are AI controls?
AI controls are the policies, technical measures and checks that keep an AI system within its intended purpose, your risk appetite and your legal duties. The efficient approach is one control set, extended from the ISO 27001 controls you already run and mapped once to ISO/IEC 42001 Annex A, the NIST AI RMF and the EU AI Act.
The phrase has a second meaning. In AI safety research, "AI control" refers to keeping advanced models from acting against their developers' intent; this guide covers the governance meaning only.
AI controls sit inside a wider operating model of roles, decision rights and reporting. Our guide to the AI governance framework covers that model. This page covers the controls layer underneath it: what you run, who owns it and how you prove it ran.
Why do separate framework programmes duplicate work?
Separate programmes duplicate work because ISO/IEC 42001, the NIST AI RMF and the EU AI Act ask about largely the same safeguards in different vocabularies. Run three programmes and you get three registers, three owners for one activity and three evidence requests for the same log. The customer, the certification auditor and the regulator are looking at the same control.
The frameworks also differ in what they are. ISO/IEC 42001 is a certifiable management system standard. The NIST AI RMF is voluntary guidance, and NIST says its actions "do not constitute a checklist". The EU AI Act is law, with duties that depend on whether you are a provider or a deployer.
Three frameworks do not mean three control sets.
NIST keeps a list of crosswalk documents that map the AI RMF to other frameworks, including ISO/IEC 42001. Most are submitted by the user community, and NIST notes that inclusion does not imply endorsement. Use them to check your own mapping, not to replace it.
How do you build one set of AI controls?
Build one set of AI controls in six steps: scope from your AI inventory, reuse your ISO 27001 controls, add AI-specific controls by lifecycle stage, give each control one owner and one evidence source, map each control once to every framework, and test each control once. The order matters, because each step narrows the work for the next.
- Scope from the AI inventory. List every AI system in use: features you build, models you call through an API, and AI embedded in the software you buy. Record for each one its purpose, its data and whether you are the provider or the deployer. Without the inventory, every later step guesses.
- Reuse your ISO 27001 controls. Access control, supplier management, logging, change management and incident response already exist in your ISMS. Extend their scope to AI systems instead of writing parallel versions. Your ISO 27001 Statement of Applicability is the starting list.
- Add AI-specific controls by lifecycle stage. Walk each in-scope system from design through development, deployment and operation to retirement, and add only the controls ISO 27001 does not already give you. The NCSC splits its secure AI development guidelines into secure design, development, deployment, and operation and maintenance. The UK government's AI Cyber Security Code of Practice adds secure end of life.
- Give each control one owner and one evidence source. Name a role, not a team. Name the system where the record lives, such as the ticketing tool, the model provider's console or the HR training record.
- Map each control once. Record against each control the ISO/IEC 42001 Annex A objective it supports, the NIST AI RMF function it serves and the EU AI Act article it helps meet, if any. One row per control, not one spreadsheet per framework.
- Test each control once. Design a single test whose result answers all three mappings. Our guide to control testing covers how to design that test for design and operating effectiveness.
Which control families does an AI control set need?
An AI control set needs eight families: AI policy and roles, AI system inventory and impact assessment, data quality and provenance, third-party and model supplier controls, human oversight, logging and record-keeping, monitoring and incident handling, and transparency to users. Most firms already run part of each family through ISO 27001.
| Control family | What it covers | Typical owner | Where the evidence usually lives |
|---|---|---|---|
| AI policy and roles | Approved uses, prohibited uses, accountability for each AI system | CEO or COO | Approved policy, roles register |
| AI system inventory and impact assessment | What AI you run, why, and its effect on people and the business | Compliance lead | Inventory, impact assessment records |
| Data quality and provenance | Where training, fine-tuning and input data comes from, and whether it is fit for purpose | Data or engineering lead | Data sheets, supplier terms, quality checks |
| Third-party and model supplier controls | Due diligence and contract terms for model providers and AI-enabled software | Procurement or security lead | Supplier register, assessments, contracts |
| Human oversight | Who can review, override or stop an AI output, and their competence | Product or operations lead | Review records, training records |
| Logging and record-keeping | Event logs from AI systems and how long they are kept | Engineering lead | Log platform, retention settings |
| Monitoring and incident handling | Performance drift, misuse and AI-specific incidents | Security or operations lead | Monitoring alerts, incident tickets |
| Transparency to users | Telling customers and staff when they are dealing with AI, and its limits | Product lead | Product copy, customer documentation |
These are families, not controls. Each one holds as few or as many controls as your inventory and risk assessment justify. Production monitoring in detail is a separate discipline from the control set, and so are permissions and guardrails for autonomous agents.
A control without an evidence source is an intention.
What does each framework expect from your AI controls?
Each framework asks a different question of the same controls. ISO/IEC 42001 asks whether you selected and justified them. The NIST AI RMF asks whether they serve its four functions. The EU AI Act asks whether you meet the duties of your role. A single mapping column per framework answers all three.
What does ISO/IEC 42001:2023 Annex A expect?
ISO/IEC 42001:2023 Annex A is a reference set of control objectives and controls, much as ISO 27001 Annex A is a reference set of controls. You choose controls through AI risk treatment and justify each inclusion or exclusion in a Statement of Applicability. Annex B gives implementation guidance.
At objective level, Annex A covers AI policy, internal organisation, the resources AI systems depend on, assessing impacts, the AI system life cycle, data, information for interested parties, use of AI systems, and third-party and customer relationships. The impact assessment is the clearest addition for an ISO 27001 holder, because ISO 27001 risk assessment looks at information security, not at an AI system's effects on people. Our ISO/IEC 42001 overview covers the standard itself.
How do the NIST AI RMF and the Generative AI Profile shape the set?
The NIST AI RMF organises AI risk management into four functions: Govern, Map, Measure and Manage. Govern is cross-cutting and informs the other three. Map each control to the function it serves, and the gaps show quickly. A set extended from ISO 27001 tends to lean on Govern, so check Map and Measure first.
The framework is voluntary, and NIST describes it as usable by organisations "of all sizes and in all sectors". The NIST AI RMF overview covers the functions in more depth.
If you build on or deploy generative AI, add the Generative AI Profile (NIST AI 600-1). NIST calls it a "companion resource" to the AI RMF. It defines risks that are novel to or made worse by generative AI and gives suggested actions for each function. Treat those actions as a menu to test your set against, not a list to adopt whole.
Which EU AI Act duties fall on a provider and which on a deployer?
Providers of high-risk AI systems carry the requirements in Articles 8 to 15. Deployers, who use an AI system under their own authority, carry the narrower duties in Article 26. The Act reaches UK firms where their AI system's output is used in the EU. Most systems a UK tech firm runs are not high-risk.
Articles 8 to 15 set the requirements a provider must build in: a risk management system, data governance, technical documentation, record-keeping, transparency to deployers, human oversight, and accuracy, robustness and cybersecurity. Under the AI Act's Article 26, a deployer of a high-risk system must:
- use the system in line with the provider's instructions for use;
- assign human oversight to people with the necessary competence, training and authority;
- make sure input data it controls is relevant and sufficiently representative;
- monitor the system's operation and inform the provider where needed;
- keep the logs the system generates, where they are under its control, for at least six months unless other law says otherwise.
Timing changed in 2026. Regulation (EU) 2026/1744, the Digital Omnibus on AI, sets 2 December 2027 as the date from which Chapter III Sections 1 to 3, including Articles 8 to 15 and the deployer duties in Article 26, apply to high-risk systems listed in Annex III. For high-risk systems covered by Annex I product legislation, the date is 2 August 2028.
One duty applies now. Article 4, as amended, requires providers and deployers to take measures to support the development of AI literacy among their staff. Our EU AI Act overview covers the risk tiers and roles.
How many AI controls does a 25 to 250-person firm need?
A 25 to 250-person firm needs fewer AI controls than a framework list suggests. Start from the AI inventory and risk assessment, keep every ISO 27001 control that already covers AI, and add only the AI-specific controls your actual systems need. A firm with no high-risk systems usually needs a short list per family.
Three tests keep the set proportionate:
- Does a risk on the register need it? If no assessed risk calls for the control, leave it out and record why in the Statement of Applicability.
- Is it already covered? If an ISO 27001 control does the job once its scope includes AI systems, extend the scope instead of adding a control.
- Can you evidence it without new tooling? Prefer controls whose record already exists in a system you run. A control that needs a new platform to prove it is usually the wrong control for this size of firm.
The goal is a set small enough that every control has a real owner and runs on a real schedule. Ten controls that run are worth more than forty that are documented.
What does one AI control mapped to all three frameworks look like?
One AI control mapped to all three frameworks is a single row: the control, its owner, its evidence source, one mapping per framework and one test. The example below is a human oversight control for a SaaS firm that uses a third-party model to draft decisions a person then approves.
| Field | Worked example |
|---|---|
| Control | Every AI-drafted decision in the in-scope workflow is reviewed and approved by a named, trained person who can change or reject it |
| Owner | Head of Operations |
| Evidence source | Approval records in the case management system, plus training records for each reviewer |
| ISO/IEC 42001 Annex A | The use of AI systems objective area: using AI systems responsibly and in line with your AI policy |
| NIST AI RMF | Govern (roles and responsibilities for human oversight) and Map (defining the human oversight process) |
| EU AI Act | Article 26 assignment of human oversight, if the system is high-risk; Article 4 AI literacy for the reviewers in any case |
| Test | Each quarter, sample approved decisions and confirm each one has a named reviewer, a recorded outcome and a current training record |
One test now answers three questions. The ISO 42001 certification auditor sees an operating control. The customer's NIST-based questionnaire gets a named owner and evidence. The EU customer sees how you would meet a deployer duty.
The mapping cells describe objectives in our own words. Take control references from your purchased copy of ISO/IEC 42001, never from a reproduced list.
What are the common mistakes when building AI controls?
The common mistakes are duplication, borrowed lists, shallow mapping, the wrong role and waiting for the deadline. Each one makes the control set bigger or later without making it stronger, and each one shows up the first time a customer, a certification auditor or a regulator asks for evidence.
- Building a second control set beside ISO 27001. Two registers drift apart, and every evidence request doubles. Extend the scope of existing controls first.
- Adopting a published control list wholesale. Lists written for large enterprises or for providers of high-risk systems bring controls you cannot evidence. Some lists also carry licence terms that forbid adapting them.
- Mapping at framework level only. "Covers the EU AI Act" is not a mapping. Name the article or objective each control supports.
- Writing provider controls when you are a deployer. If you call a third-party model, your duties sit mainly with supplier due diligence, oversight, logs and literacy.
- Waiting for December 2027. Article 4 already applies, and enterprise customers are asking now.
A mapping nobody tests is a claim.
Frequently asked questions
No. Guardrails are technical limits applied at run time, such as filters on what a model can output or which actions an agent can take. They are one kind of AI control. The control set also covers policy, ownership, supplier terms, oversight and evidence.
Yes. An AI feature inside a bought tool belongs in the inventory like any other AI system, and you are usually its deployer. The controls sit mostly in supplier due diligence, contract terms, settings that limit what data the feature can see, and guidance for the staff who use it.
Yes. Keep one register and record each control's mapping to both standards. Each standard still needs its own Statement of Applicability, because each one justifies controls against its own Annex A.
They can. The Act applies to providers and deployers outside the EU where the output of their AI system is used in the EU. A UK firm whose AI feature serves EU customers should work out its role for each system before deciding which controls it needs.
Domain engine
AI Governance reference directory.
Every guide in this domain, grouped by level — fundamentals, intermediate and advanced. Open any entry for its core practices, implementation steps and the evidence it produces.
01Fundamentals4 guides
02Intermediate4 guides
AI literacy: what the EU AI Act now asks of your firm, and a proportionate programme to meet itHuman in the loop: designing human oversight you can evidenceAI register: how to inventory every AI system your firm builds, buys or switches onAI risk assessment: how to assess one AI use case for ISO 42001, the EU AI Act and UK GDPR
AI Governance Accelerator
Ready to adopt AI with confidence?
Work with a Trust Architect to inventory your AI use, assess the risks and put controls in place that your board and your enterprise customers can rely on.