An AI governance framework is the set of roles, policies, processes and evidence an organisation uses to decide which AI systems it runs, what each one may do, and how it proves those systems did what was approved. In 2026 most organisations are building one against two reference points: ISO/IEC 42001, the certifiable management-system standard for AI, and the NIST AI Risk Management Framework, the most widely used practical guide to AI risk.
The two fit together better than they first appear, but most published guidance explains each on its own and leaves the mapping to you. This guide does the mapping. It sets out what each framework asks for, how they line up, and gives a template that maps ISO/IEC 42001 controls and NIST AI RMF subcategories to the practical action and the evidence an auditor will ask for. It is written for the security and risk teams who end up holding the evidence.
What is an AI governance framework?
Researchers have tried to pin the term down, because "AI governance" is used for everything from ethics principles to model monitoring. Mäntymäki and colleagues, writing in AI and Ethics, define organisational AI governance as the system of rules, practices, processes and technological tools that ensures an organisation's use of AI aligns with its strategies, objectives and values, fulfils legal requirements and meets the principles of ethical AI the organisation follows. They also position it next to corporate, IT and data governance rather than as a separate island.
A systematic review of the field in Internet Research found the central gaps were a limited understanding of how AI governance is implemented and insufficient operationalisation of its processes. Put plainly, organisations have principles and struggle to turn them into controls someone can test. That is the gap a framework mapping closes.
In practice a working framework answers five questions for every AI system in scope: what is it, who owns it, what may it do, what could go wrong, and how would we know. The last question is where most frameworks are thinnest, and where security teams carry the load.
Which AI governance frameworks matter in 2026?
| Framework | What it is | Binding? | Best used for |
|---|---|---|---|
| ISO/IEC 42001:2023 | Management-system standard for AI, with requirements in clauses 4 to 10 and 38 reference controls in Annex A | Voluntary; certifiable by accredited bodies | The skeleton an auditor will test, and a certificate customers recognise |
| NIST AI RMF 1.0 | Risk framework built on four functions: Govern, Map, Measure and Manage, each broken into categories and subcategories | Voluntary | The working checklist for identifying and treating AI risk |
| NIST AI 600-1 | Generative AI Profile of the AI RMF | Voluntary | Risks specific to generative models and agents |
| EU AI Act | Regulation (EU) 2024/1689, a risk-based law with obligations applied in phases | Law, for systems placed on the EU market or used in the EU | Deciding whether a system is prohibited, high-risk or general purpose |
| ETSI TS 104 223 | Baseline cyber security requirements for AI models and systems, built from the UK's AI Cyber Security Code of Practice | Voluntary | Security controls across the AI lifecycle, in 13 principles |
| NCSC and partners' secure AI development guidelines | Guidance for secure design, development, deployment and operation of AI systems | Voluntary | Engineering practice for teams that build or integrate AI |
| ENISA multilayer framework | Good cyber security practice for AI, layered from general ICT security to AI-specific and sector-specific controls | Voluntary | Placing AI controls inside an existing security programme |
For most UK and EU organisations the practical choice is ISO/IEC 42001 as the structure, NIST AI RMF as the risk method, and the EU AI Act as the legal overlay where it applies. ETSI TS 104 223 fills the security-specific gaps in all three.
How do ISO 42001 and NIST AI RMF fit together?
They answer different questions. ISO/IEC 42001 says what management system you must run: a policy, defined roles, risk and impact assessment, operational controls, monitoring, internal audit, management review and improvement. It is written to be audited and certified, in the same shape as ISO/IEC 27001, so an organisation that already runs an information security management system can extend it.
NIST AI RMF says how to think about and treat AI risk. Govern sets up the culture and accountability. Map establishes the context of each system and its risks. Measure assesses and tracks them. Manage prioritises and acts on them. It is not certifiable, but its subcategories are specific enough to work from.
NIST publishes an official crosswalk between the AI RMF and ISO/IEC 42001. Use it as the authority. The template below is a working version for security and risk teams: it groups the controls into the areas where evidence is actually produced, and adds the action and the evidence for each.
The ISO 42001 and NIST AI RMF mapping template
Copy this into your risk register or GRC tool. The ISO/IEC 42001 references are to Annex A controls and, where noted, to the main clauses. The NIST references are AI RMF 1.0 subcategories. The ETSI column gives the closest principle in ETSI TS 104 223, which is our judgement rather than an official mapping.
| Area | ISO/IEC 42001 | NIST AI RMF | ETSI TS 104 223 | What to do | Evidence an auditor will ask for |
|---|---|---|---|---|---|
| Policy | Clause 5.2; A.2.2 AI policy; A.2.3 alignment with other policies; A.2.4 review | GOVERN 1.1, 1.2 | Principle 1 | Write one AI policy that sets scope, risk appetite and prohibited uses, linked to security, data and procurement policy | Approved policy, review date, board or executive sign-off |
| Roles and accountability | Clause 5.3; A.3.2 AI roles and responsibilities | GOVERN 2.1, 2.3 | Principle 4 | Name an owner for every AI system and an executive accountable for AI risk overall | RACI per system; minutes showing executive decisions on AI risk |
| Reporting concerns | A.3.3 reporting of concerns | GOVERN 4.3 | Principle 10 | Give staff a route to report AI misuse or failure, and track reports to closure | Reporting channel, log of reports and outcomes |
| AI inventory | A.4.2 resource documentation; A.4.3 to A.4.5 data, tooling and computing resources | GOVERN 1.6 | Principle 5 | Keep a named list of AI apps, agents and tools in the estate, sanctioned or not, with owner, access and approval state | Current inventory, discovery method, refresh date, list of unapproved systems found |
| Impact assessment | Clause 6.1.4; A.5.2 to A.5.5 | MAP 1.1, 5.1 | Principle 3 | Assess each system's impact on individuals, groups and society before deployment and after significant change | Completed impact assessments, dated, per system |
| Risk assessment and treatment | Clauses 6.1.2, 6.1.3, 8.2, 8.3 | MAP 4.1; MANAGE 1.3 | Principle 3 | Assess risk per system, including third-party components, and record the treatment chosen | Risk register entries with treatment and owner |
| Data | A.7.2 to A.7.6 data for AI systems, quality and provenance | MAP 4.1; MEASURE 2.1 | Principle 8 | Record where training, grounding and prompt data comes from and what it may contain | Data provenance records; test-set documentation |
| Human oversight and authority | A.9.2 processes for responsible use; A.9.4 intended use | GOVERN 3.2; MAP 3.5 | Principle 4 | For each agent or automated workflow, state what it may do unattended and where a person decides | Per-system authority statement; tool and permission scopes for agents |
| Testing and security | A.6.2.4 verification and validation | MEASURE 1.1, 2.7 | Principle 9 | Test security and resilience before release and after change, including prompt injection | Test plans, results, open findings |
| Logging and monitoring | A.6.2.6 operation and monitoring; A.6.2.8 recording of event logs | MEASURE 3.1; MANAGE 4.1 | Principle 12 | Log what each AI system and agent did, with which identity, against which system, and monitor for drift and misuse | Event logs that link AI action to identity, tool and target system; monitoring alerts |
| Deactivation and reversal | A.6.2.6 operation and monitoring | MANAGE 2.4 | Principle 4 | Be able to disable an AI system or revoke an agent's access quickly, and reverse what it changed | Tested kill-switch or revocation procedure; record of a drill |
| Suppliers and third parties | A.10.2 allocating responsibilities; A.10.3 suppliers | GOVERN 6.1; MANAGE 3.1 | Principle 7 | Assess AI suppliers and model providers, and set out who is responsible for what in contract | Supplier assessments; contract clauses on AI responsibilities |
| Incidents | A.8.4 communication of incidents | GOVERN 4.3; MANAGE 2.3, 4.3 | Principle 10 | Treat AI failures and misuse as incidents, with a playbook, and tell affected parties | AI incident playbook; incident records and communications |
| Audit and review | Clauses 9.2 internal audit, 9.3 management review, 10 improvement | GOVERN 1.5 | Principle 11 | Audit the framework itself on a schedule and act on what the audit finds | Audit reports; management review minutes; corrective actions |
How to put the template to work:
- Start with the inventory row. You cannot govern a system you have not found, and most organisations find more AI in use than they expected.
- Name an owner for every system on the inventory before writing any further policy.
- Run impact and risk assessments for the systems that can act, not only those that advise: agents with tool access and write permissions come first.
- Write the authority statement for each agent: what it may do unattended, and where a person decides.
- Check the logging row against reality. Pick one AI action from last week and try to reconstruct it end to end.
- Run a revocation drill for one agent and record how long it took.
- Schedule the internal audit and management review, and put the first dates in the diary.
What does an AI governance framework need from the security team?
Most of the evidence in the template's right-hand column is security evidence. Policy and impact assessment sit with risk, legal and the business. Inventory, logging, oversight, testing, deactivation and incidents are security operations work, and they are where audits fail.
Three things make this harder with AI agents than with earlier AI.
Agents are identities. An agent that can read data, call tools and change systems is a privileged account. It needs an owner, least privilege and a reviewed scope, the same as any service account.
The evidence is spread across systems. A single agent action can involve a model provider's audit log, an identity provider's sign-in, a tool call, a network connection and a change in a target system. Each provider audits its own part well. None of them joins the chain. Raji and colleagues' work on internal algorithmic auditing makes the same point about AI generally: once a system is deployed, emergent issues can be difficult or impossible to trace back to their source. Their answer is an internal audit process that produces documentation throughout development, so the record exists before it is needed.
Data can carry instructions. Agents that read email, documents or web pages can be steered by text planted in them, a risk shown in research on indirect prompt injection and ranked first in the OWASP Top 10 for LLM applications. The testing row of the template has to include it.
MITRE's ATLAS knowledge base catalogues attack techniques against AI systems and is a useful input to the risk assessment row.
Where SenseOn fits, and where it does not
SenseOn does not write your AI policy, run your impact assessments or certify you against ISO/IEC 42001. Those belong to your risk, legal and compliance owners and your certification body.
SenseOn supplies evidence for the security-heavy rows of the template:
- AI inventory (GOVERN 1.6; A.4.2). The 7-day AI inventory produces a named, human-reviewed list of the AI apps, agents and tools found in your estate: who owns them, what they can reach, and which actions lack an approval gate.
- Logging and monitoring (A.6.2.8; MANAGE 4.1). Security for AI connects provider, identity, tool, network and target-system evidence into one chain, so you can reconstruct what an AI workflow did.
- Deactivation and reversal (MANAGE 2.4). The same chain shows what access to contain and whether a change was reversed.
- Governance of SenseOn's own agents. Every AI and analyst action in SenseOn writes to Decision Trace, an append-only record with 100% coverage by design. SenseOn is certified to ISO/IEC 27001 by BSI.
Related reading: agentic AI security covers the controls for AI agents in more depth, the board AI risk assessment sets out the decisions a board has to own, shadow AI covers the unsanctioned tools your inventory will find, and the agentic SOC guide applies the same principles to AI inside security operations.
Frequently asked questions
What is an AI governance framework?
An AI governance framework is the set of roles, policies, processes and evidence an organisation uses to decide which AI systems it runs, what each may do, and how it proves they behaved as approved. Most organisations now build one on ISO/IEC 42001 for structure and the NIST AI Risk Management Framework for risk method, with the EU AI Act as a legal overlay where it applies.
What is the difference between ISO 42001 and NIST AI RMF?
ISO/IEC 42001 is a certifiable management-system standard: it sets requirements an auditor tests, in the same shape as ISO/IEC 27001, plus 38 reference controls in Annex A. The NIST AI RMF is a voluntary risk framework organised into Govern, Map, Measure and Manage. ISO tells you what system to run; NIST tells you how to assess and treat the risks inside it. NIST publishes an official crosswalk between them.
Is ISO 42001 certification mandatory?
No. ISO/IEC 42001 is voluntary. Organisations pursue certification because customers, regulators and procurement teams increasingly ask for evidence of AI governance, and a certificate from an accredited body is a recognised way to show it.
Does ISO 42001 help with EU AI Act compliance?
It helps, but it is not the same thing. The EU AI Act sets legal obligations that depend on each system's risk category, and ISO/IEC 42001 does not on its own demonstrate conformity with them. A working ISO/IEC 42001 management system does give you much of the structure the Act expects, such as risk management, documentation, logging and human oversight, so the evidence can be reused.
What should an AI governance framework include?
At minimum: an AI policy, named owners for every system, an inventory of AI in use, impact and risk assessments, data provenance records, a statement of what each system may do unattended, security testing, logs that link AI actions to identities and target systems, a way to disable and reverse, supplier controls, an incident process, and scheduled audit and review. The mapping template in this guide covers each one.
Sources
- Mäntymäki, M. et al. (2022). Defining organizational AI governance. AI and Ethics.
- Birkstedt, T. et al. (2023). AI governance: themes, knowledge gaps and future agendas. Internet Research.
- Raji, I. D. et al. (2020). Closing the AI accountability gap: defining an end-to-end framework for internal algorithmic auditing. ACM FAT* 2020.
- Greshake, K. et al. (2023). Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. ACM AISec Workshop.
- ISO/IEC 42001:2023. Artificial intelligence: Management system.
- NIST (2023). AI RMF 1.0, NIST AI 100-1, and the AI RMF crosswalks.
- NIST (2024). Generative AI Profile, NIST AI 600-1.
- ETSI (2025). TS 104 223 V1.1.1: Baseline Cyber Security Requirements for AI Models and Systems.
- UK DSIT (2025). AI Cyber Security Code of Practice.
- NCSC (2023). Guidelines for secure AI system development.
- ENISA (2023). Multilayer Framework for Good Cybersecurity Practices for AI.
- European Union. Regulation (EU) 2024/1689 (AI Act).
How SenseOn writes, checks and corrects its content: editorial standards.
