AI Governance Best Practices: ISO 42001, ISO 27001, NIST AI RMF + EU AI Act

What ISO 42001 covers

The standard uses the familiar ISO high-level structure (Clauses 4–10), requiring organisations to establish context, define leadership accountability, plan for AI-specific risks and opportunities, operate the management system, evaluate performance, and drive continual improvement. Annex A provides 38 controls across 9 control domains including AI policy, internal organisation, AI risk management, data for AI systems, AI system lifecycle, and human oversight.

Annex B provides normative guidance on AI impact assessment — a structured process for evaluating the consequences of AI systems on individuals, groups, and society. This is distinct from a cybersecurity risk assessment; it examines outcomes of AI decisions themselves.

What ISO 42001 does not cover

ISO 42001 does not replace information security management. The standard explicitly acknowledges that AI systems are built on data and that data security is a precondition for trustworthy AI — but the security controls themselves live in ISO 27001. ISO 42001 also does not specify legal compliance obligations; that is the role of regulations such as the EU AI Act. It governs the management system, not the regulatory position.

Standard Reference

ISO/IEC 42001:2023 Clause 6.1.2 defines AI risk assessment as a process that must consider the organisation's context, the purpose and intended use of AI systems, potential negative impacts on individuals and society, and the adequacy of existing controls — all of which must be documented. This is the auditable spine of the entire management system.

Why ISO 27001 is foundational to AI governance

AI systems are, at their core, data processing systems. Compromised training data produces compromised models. Insecure inference endpoints expose proprietary outputs. Uncontrolled access to model weights creates intellectual property and liability risks. ISO 27001's Annex A controls — particularly A.8 (Technological controls covering data masking, data leakage prevention, monitoring activities, and configuration management) — apply directly to the infrastructure layer beneath every AI system in production.

ISO 27001:2022 updates relevant to AI

The 2022 revision added 11 new controls that map directly to AI deployment concerns: threat intelligence (A.5.7), information security for use of cloud services (A.5.23), ICT readiness for business continuity (A.5.30), web filtering (A.8.23), secure coding (A.8.28), and data masking (A.8.11). Organisations still operating on the 2013 version of the standard are missing controls designed for exactly the kinds of threats AI systems introduce.

The four core functions explained

GOVERN is the only function that spans the entire organisation — it establishes accountability, defines policies, cultivates an AI risk culture, and makes MAP, MEASURE, and MANAGE repeatable. Without GOVERN, the other three functions are ad hoc exercises, not a management system.

MAP is the scoping function. It frames the context in which a specific AI system will operate, identifies stakeholders and potential impacts, and produces the risk inventory that feeds MEASURE and MANAGE. MAP outputs must be revisited whenever the system, context, or user base changes.

MEASURE analyses and tracks identified risks using qualitative and quantitative methods — including fairness and bias evaluation (MEASURE 2.11), testing and evaluation of AI systems (MEASURE 2.5), and performance monitoring against defined metrics. This is where technical AI safety work connects to governance.

MANAGE implements the risk treatment decisions: residual risk plans, incident response, decommissioning procedures, and post-deployment monitoring. MANAGE 4.1 specifically requires appeal and override mechanisms and documented change management — two areas most AI deployments get wrong.

NIST AI RMF vs. ISO 42001: complementary, not competing

NIST AI RMF is voluntary US guidance; ISO 42001 is an internationally certifiable standard. The two frameworks are designed to be complementary. Many organisations use NIST AI RMF as their operational risk management model — providing the detailed subcategory actions — inside an ISO 42001 AI Management System, which provides the governance architecture and audit trail. In July 2024, NIST also published the Generative AI Profile (NIST AI 600-1), which maps GenAI-specific risks including confabulation, data privacy, and harmful bias onto the four core functions.

Enforcement timeline

Prohibited AI systems were banned from February 2025. GPAI model obligations took effect in August 2025. High-risk AI system obligations for providers and deployers become fully enforceable from August 2026. Organisations procuring or deploying AI in EU markets — or offering AI systems to EU users from outside the EU — need to be compliance-ready now, not in 2026.

How ISO 42001 connects to EU AI Act compliance

ISO 42001 certification is not an automatic EU AI Act compliance certificate — but the two align closely. ISO 42001's AI impact assessment requirements (Annex B), human oversight controls (A.9), and post-deployment monitoring requirements (Clause 9.1) directly address the technical documentation, human oversight, accuracy, and transparency obligations in Articles 9–15 of the EU AI Act for high-risk systems. Organisations implementing ISO 42001 are building the governance infrastructure that EU AI Act compliance requires.

Critical Gap

The EU AI Act imposes fines of up to €35 million or 7% of global annual turnover for violations involving prohibited AI practices. High-risk AI violations attract fines up to €15 million or 3% of turnover. These penalties apply to any organisation — including non-EU companies — whose AI systems affect EU individuals.

What the policy must address

The AI policy must be aligned with other organisational policies — quality, security, privacy, ethics — under A.2.3. Where conflicts exist, the AI policy must either resolve them or document how they will be managed. A.2.4 requires a designated management role to own the review process, with reviews triggered by changes in legal requirements, business context, or technical environment — not just calendar dates.

In NIST AI RMF terms, the AI policy is the output of GOVERN 1.2 (integrating trustworthiness characteristics into organisational policies) and GOVERN 1.4 (establishing risk management outcomes through transparent policies). Without a formal policy, the GOVERN function is incomplete and all downstream MAP, MEASURE, and MANAGE activities lack authoritative direction.

Auditor Lens

Auditors check three things about the AI policy: (1) that it is actually signed by top management, not delegated to a function head; (2) that affected personnel can articulate what it requires of them; (3) that there is evidence of at least one review since the original approval. Policies that have never been reviewed signal that the management system is paper-only.

AI risk assessment vs. AI impact assessment

The AI risk assessment asks: what can go wrong with this AI system, and what is the likelihood and impact on the organisation? It feeds the risk treatment plan and the Statement of Applicability (SoA) for Annex A controls. This process should be integrated with the information security risk assessment required under ISO 27001 Clause 6.1.2 to avoid duplication.

The AI impact assessment asks: what are the intended and unintended consequences of this AI system's outputs on the people it affects? It considers bias, fairness, dignity, rights, and systemic effects — and must be revisited whenever the AI system is significantly updated or deployed in a new context. This maps to NIST AI RMF MAP 5.1 (documenting likelihood and magnitude of impacts) and MAP 5.2 (identifying practices that address impacts).

Practitioner Note

In my experience, the AI impact assessment is the assessment organisations are least prepared for. Teams with strong risk management culture can produce a credible AI risk assessment relatively quickly. The AI impact assessment requires engaging with affected communities, examining distributional effects on protected characteristics, and documenting decisions about acceptable harm trade-offs — none of which fit neatly into existing risk registers.

What good accountability structure looks like

Effective AI governance assigns accountability at three levels: strategic (executive or board-level accountability for AI risk appetite and policy), operational (cross-functional AI governance committee or AI ethics board with authority to approve and reject AI system deployments), and technical (named owners for each AI system in production, responsible for monitoring and incident reporting). NIST AI RMF GOVERN 2.2 adds that personnel must receive AI risk management training enabling them to perform their duties consistently with related policies.

For EU AI Act compliance, Article 26 requires deployers of high-risk AI systems to designate a human oversight role with the authority, knowledge, and capacity to intervene. This is a specific, named individual — not a team, not a function.

What meaningful oversight requires in practice

Meaningful human oversight has four components: human reviewers must have actual authority to reverse AI decisions (not just flag them for escalation); they must have the information needed to make an informed judgment (not just the AI output, but the inputs and the model's confidence level); they must have the time to review properly (AI systems that generate decisions faster than humans can assess them undermine oversight by design); and there must be a documented channel for personnel to raise concerns about AI output quality.

The EU AI Act Articles 14 and 26 make this explicit for high-risk AI systems: oversight measures must be specified in the technical documentation, and deployers must ensure human oversight is operationally possible — not merely theoretically available. NIST AI RMF MANAGE 4.1 specifies that appeal and override mechanisms must be documented post-deployment.

ISO 42001 data controls: quality and provenance

A.7 requires organisations to document how data for AI systems is acquired, processed, and validated for quality and representativeness. This includes training data, validation data, and test data. Where data is sourced from third parties, the provenance and any limitations must be documented — auditors check whether organisations know where their training data came from and whether they assessed it for bias before use.

ISO 27001 data controls: security and access

ISO 27001 A.8 controls address who can access training datasets, how they are stored and encrypted, how access is logged, and how data masking is applied when training data contains personal information. A.8.11 (Data masking) and A.8.12 (Data leakage prevention) are particularly relevant to AI systems that process or are trained on personal data under GDPR, PDPL (Saudi Arabia), UAE Federal Decree-Law No. 45/2021, or equivalent data protection legislation in the jurisdiction of deployment.

Transparency as an architecture decision

Explainability is not a feature added after development — it is an architecture decision made at design time. Choosing a model type that is inherently interpretable (decision trees, linear models) over one that is more accurate but opaque (deep neural networks) is a governance trade-off that must be documented. For high-risk applications — credit scoring, medical diagnosis support, judicial risk assessment — the EU AI Act and ISO 42001 together require that this trade-off be explicitly justified, not simply assumed.

NIST AI RMF MEASURE 2.6 specifically addresses explainability and interpretability of AI systems, requiring that explanations are accurate, meaningful to the intended audience, and do not create false confidence in the system's reliability. Different audiences need different explanations: technical documentation for auditors, meaningful outcome explanations for individuals whose data is being processed, and summary disclosures for the public where required by regulation.

Bias sources across the AI lifecycle

Bias enters AI systems at multiple points: training data that underrepresents certain populations, labelling processes that reflect human prejudice, model architectures that weight certain features over others, deployment contexts that differ from the training distribution, and feedback loops that amplify existing disparities. ISO 42001 Annex B's AI impact assessment process requires organisations to consider how their AI systems will affect individuals across different demographic groups — which requires examining bias at each of these entry points, not just in the final model output.

For high-risk AI applications under the EU AI Act — including recruitment, credit scoring, education, and law enforcement — bias testing must be documented in the technical file and repeated whenever the model is retrained on new data. Governance frameworks that conduct bias testing once at initial deployment and never repeat it do not satisfy either the EU AI Act or ISO 42001 requirements.

What AI supply chain governance covers

Most organisations deploying AI today are not building models from scratch — they are using foundation models, third-party APIs, or AI-embedded SaaS products. Each of these creates supply chain risk: the provider may not disclose training data provenance, the model may behave differently in the deployment context than in the provider's testing environment, and the provider's incident notification obligations may not align with the deployer's regulatory requirements.

ISO 27001 A.5.19 through A.5.22 (supplier security controls) apply directly to AI vendors. Contracts with AI providers should address: data processing agreements, model change notification obligations, incident disclosure timelines, audit rights, and what happens to organisation data if the provider discontinues the service or is acquired. The EU AI Act Article 25 specifies that where a provider does not cooperate, the deployer bears the compliance obligation — making due diligence of AI providers a legal necessity, not a procurement preference.

What monitoring and audit must cover

Effective monitoring covers three dimensions simultaneously. Technical performance monitoring tracks model accuracy, precision, recall, and distributional shift — identifying when the model's inputs have changed enough that its outputs can no longer be trusted. Governance compliance monitoring verifies that control activities (bias reviews, human oversight processes, documentation updates) are actually being executed. Incident and near-miss monitoring captures AI system failures and unexpected outputs, feeding into the corrective action process required by ISO 42001 Clause 10.1.

NIST AI RMF MANAGE 4.1 requires post-deployment monitoring, appeal and override mechanisms, decommissioning procedures, and change management documentation. Internal audits under ISO 42001 Clause 9.2 must assess whether the AIMS conforms to the organisation's own requirements and to the standard — separate from the external certification audit conducted by an accredited certification body.

Auditor Lens

The most common audit finding in AI governance programmes is not missing controls — it is controls that exist on paper but have no evidence of execution. Monitoring plans without monitoring records. Audit schedules without audit reports. Human oversight processes without the logs showing that oversight actually happened. Every control requires evidence. If it is not documented, auditors treat it as not done.

Competence vs. awareness: a practical distinction

ISO 42001 uses two separate terms deliberately. Competence (Clause 7.2) applies to people who perform activities that affect AI system performance — data scientists, ML engineers, product managers owning AI systems, internal auditors. Competence must be demonstrated and documented, not assumed from job title. Awareness (Clause 7.3) applies to all personnel — they must understand what the AI policy requires of them and why it matters.

The EU AI Act introduces an explicit AI literacy obligation in Article 4, requiring providers and deployers to ensure their staff and others involved in AI system operation have sufficient AI literacy. This applies across the organisation — not just technical teams. Organisations pursuing ISO 42001 certification that simultaneously document their AI literacy programme satisfy both requirements with one set of evidence.