ISO 42001 Annex A Controls: A Practical Guide for 2026

AI now sits inside products, operations, and customer journeys, and that creates governance risk regulators are no longer willing to wait for. ISO/IEC 42001 is the first international standard for AI Management Systems (AIMS, the governance structure that runs AI oversight day to day), and Annex A is the control set that turns AIMS policy into daily practice. This guide covers all nine Annex A domains, what evidence each one expects, and how to sequence implementation without over-building.

Annex A is the reference control set for an AI Management System. It translates the high-level requirements of ISO 42001's main clauses into day-to-day controls covering governance, data, model lifecycle, human oversight, and operational monitoring. Think of the AIMS as the operating system: Annex A is the set of features you run on top of it.

The standard contains 38 controls organised into nine domains, A.2 through A.10. Each domain sets out an outcome your organisation satisfies with controls matched to its own AI risk profile, use cases, and operating context. A control that's critical for a financial services firm running credit-decisioning models can sit outside scope for a team using AI only for internal document search.

The Statement of Applicability (SoA) is the cornerstone document. Under Clause 6.1.3, you produce an SoA listing every Annex A control, stating whether it applies, and giving a documented justification for each inclusion or exclusion. Auditors scrutinise the SoA closely, and an excluded control with no credible rationale becomes a finding.

ISO/IEC 42001 borrows its overall structure from ISO/IEC 27001, the information security management standard, and both share the same Annex A format. The two control sets still target entirely different risk domains.

If your organisation already holds ISO 27001 certification, the governance backbone, risk process, and internal audit cycle transfer directly. You're extending an existing management system into AI-specific territory, building on governance you've already proven works.

Annex A runs across nine domains that follow the AI lifecycle from governance and policy through to third-party relationships. Each domain addresses a distinct piece of responsible AI operation.

A.2: AI Policies (3 controls)

The foundation of the AIMS. This domain requires a documented AI policy approved by executive leadership, covering fairness, transparency, human oversight, and safety, aligned with your organisation's other policies, and reviewed at least annually or when something material changes.

Common gap: A policy that exists but doesn't drive action. If you can't trace a policy clause to a procedure, a control task, and a named owner, the policy is decorative.

Evidence: Approved AI policy with version history, an alignment record against other organisational policies, and a review log.

A.3: Internal Organisation (2 controls)

Governance structure: roles, responsibilities, and a channel for raising concerns. This domain requires clear ownership for AI-related activities across the lifecycle, plus a confidential reporting channel for staff, contractors, and external parties.

Common gap: Accountability fragmented across risk, legal, engineering, and product, with no single owner and no forum where decisions get recorded.

Evidence: A RACI for AI roles, a documented concerns-reporting process with escalation steps, and a decision log.

A.4: Resources for AI Systems (5 controls)

The broadest domain by control count: documentation of the data, tooling, computing infrastructure, and people your AI systems depend on at each lifecycle stage. Personnel need defined competency requirements and role-based training on AI ethics, bias, and oversight.

Common gap: Training pitched at generic data literacy when reviewers need AI-specific oversight skills. Reviewers who can't explain what they're reviewing can't provide meaningful oversight.

Evidence: A resource inventory covering data, tooling, and compute, a skills matrix, role-based training records, and an infrastructure security baseline.

A.5: Assessing Impacts of AI Systems (4 controls)

This domain decides how deep every other control needs to go. It requires a repeatable AI system impact assessment process covering harm to individuals, groups, and wider society, triggered by criticality, complexity, or sensitivity, with results documented and retained for audit.

Common gap: An impact assessment that happens once at design time and never gets revisited when something material changes, stopping at the individual user and never reaching societal or environmental effects.

Evidence: A documented impact assessment process, retained assessment records naming affected groups and mitigations, and a defined trigger list for reassessment.

A.6: AI System Lifecycle (9 controls)

The most operationally intensive domain, spanning design, development, verification, deployment, and operation. Controls require responsible-development objectives built into design from the start, documented requirements and version control, testing against defined acceptance thresholds, and a deployment plan with rollback criteria.

Common gap: Deployment approval that exists on paper but isn't embedded in tooling, and rollback criteria that never get rehearsed.

Evidence: A design review checklist, model card with version history, a test report against defined thresholds, deployment approval record, rollback plan, and event logs.

A.7: Data for AI Systems (5 controls)

Data governance specific to AI: quality, provenance, acquisition, and preparation. Controls require documented data sources with quality criteria, provenance records for training and production data, and defined preparation methods with a recorded rationale.

Common gap: Missing documentation for data sources and quality checks, and no agreed standard for what "good enough" data looks like before a model reaches production.

Evidence: A data lineage sheet, quality criteria and test results, acquisition records naming source and known bias, and documented preparation methods.

A.8: Information for Interested Parties (4 controls)

Documentation and transparency controls covering what users, auditors, and the public need to know. This domain requires plain-language user documentation, an external reporting channel for complaints, an incident-communication plan, and a decision on what other AI-system information gets proactively shared.

Common gap: Documentation written for engineers and never adapted for the people who actually need to act on it, plus incident-communication plans built for security events that leave AI-specific incidents uncovered.

Evidence: User-facing documentation, an external reporting log, an incident-communication plan, and a record of what's shared with regulators or the public and when.

A.9: Use of AI Systems (3 controls)

Controls governing how AI systems get used day to day: responsible-use processes, defined objectives such as fairness thresholds and human-in-the-loop requirements, and a check that the system stays within its intended purpose.

Common gap: A system built for one use case that quietly gets repurposed for another without a fresh impact assessment.

Evidence: A responsible-use SOP, documented use objectives, and a scope-control record tying deployments back to intended use.

A.10: Third-Party and Customer Relationships (3 controls)

Controls covering AI suppliers, cloud AI services, and customer obligations. Organisations need to allocate responsibility clearly across the AI supply chain and run due diligence on suppliers of AI services, data, models, and tooling.

Common gap: Third-party AI tools adopted by individual teams without governance review. Shadow AI is the most common source of undocumented risk in 2026.

Evidence: A third-party AI register, supplier due-diligence records, licence scope confirmations, and a record of customer obligations factored into deployment decisions.

The table below maps each domain to its core control area, the primary evidence auditors look for, and the EU AI Act outcomes it supports. Use it as a working reference when building or auditing your SoA.

How to use this table: confirm whether each control applies to your organisation. If it does, assign an owner and an evidence location. If it doesn't, document the rationale in your SoA, since rows with no owner or evidence location are open gaps regardless of what your policy says.

A focused organisation can reach ISO 42001 certification readiness in 90 days with the right sequencing. The four phases below follow the Plan-Do-Check-Act cycle the standard is built on.

Phase 1: Assess (Days 1-20)

Before implementing any controls, understand what you're governing.

1. Build a centralised AI inventory: every AI system your organisation develops, deploys, or uses, including third-party tools and foundation models accessed via API.
2. For each system, capture: purpose, owner, data sources, lifecycle state, and risk classification.
3. Map current practice against all nine Annex A domains to find gaps, and identify legal touchpoints to layer on top, such as EU AI Act (Regulation (EU) 2024/1689, the binding EU law on artificial intelligence) documentation fields or UK GDPR (the UK’s version of the EU’s General Data Protection Regulation) requirements.
4. Confirm which Annex A controls apply and begin drafting SoA inclusion and exclusion rationale as you go.

The inventory is the hardest part. Most organisations find considerably more AI in use than they expected once they look across procurement, IT, and individual team tools.

Phase 2: Plan (Days 21-40)

Prioritise controls by risk and business impact: high-risk AI systems first, then critical data pipelines, then governance and oversight structures. Assign owners and due dates for every control, with success measures defined upfront. Design the evidence model before implementation begins, since consistent artefact naming, version control, and tagging to control IDs prevents documentation sprawl later.

Phase 3: Implement (Days 41-70)

Update policies and procedures, linking each clause to a named control task. Build registers for AI systems, datasets, models, suppliers, risks, and incidents. Embed human-in-the-loop checkpoints into tools and workflows, and launch role-based training for developers, validators, product owners, and support teams. Activate monitoring, drift detection, and security telemetry for every production model.

H3: Phase 4: Audit and Improve (Days 71-90+)

Run an internal audit against Annex A and your crosswalk before engaging an external certification body. Track non-conformities to closure with owners, due dates, and retest evidence, then finalise the SoA with a complete inclusion and exclusion rationale for every control. But the audit only tells you what's broken; fixing it runs as a separate step with its own deadline.

ISO 42001 runs as a continuing management system once certified, with its own ongoing cadence of reviews and retests. Watch for regulatory clarifications, keep crosswalks current, and maintain a steady cadence of control health checks.

ISO 42001 gives you the control structure, evidence model, and accountability framework that makes demonstrating EU AI Act compliance considerably more tractable. The Act's own legal obligations (conformity assessment, CE marking, EU database registration) sit outside what any management-system certification covers.

The EU AI Act phases in obligations by risk tier. Following the Digital Omnibus on AI, given final approval by the Council of the EU on 29 June 2026 and awaiting Official Journal publication, the deadline for standalone high-risk systems under Annex III has moved from 2 August 2026 to 2 December 2027; high-risk systems embedded as safety components of regulated products now have until 2 August 2028. The Act's transparency obligations under Article 50 still apply from 2 August 2026 as originally scheduled. Providers of high-risk systems must maintain technical documentation, run a quality management system, complete conformity assessments, and ensure human oversight, and ISO 42001 Annex A controls map directly onto these requirements.

Where the alignment is strongest:

The Limits of ISO 42001 Certification

The Act imposes legal obligations that sit outside a management-system standard: mandatory registration in the EU AI database for certain high-risk systems, conformity assessment procedures with notified bodies, CE marking, and post-market monitoring reporting to national authorities. Those obligations belong to the Act alone, and only direct legal compliance work closes them.

The practical value: an organisation with a mature ISO 42001 AIMS already holds most of the documentation, governance, and evidence the Act requires. The incremental effort to meet the Act's specific legal obligations runs considerably lower than starting from scratch. For a full comparison of the two frameworks, see EU AI Act vs ISO 42001: what compliance leaders need to know.

Most organisations implementing ISO 42001 already operate within one or more governance frameworks. Annex A sits alongside existing management systems, extending governance you already run into AI-specific territory.

ISO 27001

The most natural integration. If you hold ISO 27001 certification, your ISMS governance structures, risk assessment process, internal audit cycle, and management review cadence all carry over. Map Annex A controls to your existing ISO 27001 control library to spot overlaps and avoid duplicate owners or artefacts. AI-specific controls (data lineage, model cards, impact assessment) are net new; governance and operational controls largely extend what you already run.

NIST AI Risk Management Framework

The NIST AI RMF (the US National Institute of Standards and Technology's voluntary AI risk framework) is built around four functions: Govern, Map, Measure, and Manage. Annex A activities map cleanly across all four. Use Annex A evidence as inputs to AI RMF profiles, and use the RMF's categorisation language to communicate AI risk posture to US-facing stakeholders. For a full comparison, see NIST AI RMF vs ISO 42001.

GDPR and UK GDPR

Where AI systems process personal data, GDPR obligations apply in parallel. Annex A.7 data governance controls align with GDPR's data quality, purpose limitation, and privacy-by-design requirements, and DPIAs for AI systems should reference Annex A evidence. The ICO (the UK's data protection regulator) sets out specific expectations that Annex A controls help satisfy.

Running ISO 42001 and ISO 27001 together is increasingly common, particularly in financial services and critical infrastructure. The overhead runs lower than two separate programmes: one governance forum, one risk process, one internal audit cycle, two Statements of Applicability. Tag each artefact to both the ISO 27001 control ID and the ISO 42001 Annex A domain it satisfies, and every audit after the first pulls from the same tagged evidence instead of a fresh collection exercise.

Most ISO 42001 implementations stall, or produce weak evidence, for the same reasons. These are the patterns that consistently surface in audits and gap assessments.

1. The AI Inventory Is Incomplete

Shadow AI is the dominant risk. Teams adopt foundation model APIs, AI-assisted coding tools, and SaaS products with embedded AI without governance review, and an inventory that only captures internally built models misses most of the AI actually in use. Scope discovery across procurement records, IT asset management, and individual team tools before starting control implementation.

2. Policies Exist But Don’t Drive Action

An AI ethics policy that can't be traced to a procedure, a control task, and a named owner stays a document; it never becomes a control. Auditors test this by asking: 'show me how this policy clause translates into what someone does on Tuesday morning.' If you can't answer that, the policy isn't implemented.

3. Human Oversight Is on Paper Only

The most common A.9 failure: intervention points that live in a document without matching enforcement in the system itself. Reviewers can override AI decisions without logging the rationale, and override logs that exist never get reviewed. Meaningful human oversight means the system surfaces the right information at the right point, with intervention built into the workflow people actually use.

4. Data Documentation Lags Model Deployment

Model cards get created at launch and never updated after retraining. Data lineage records don't capture synthetic data flags or usage constraints, and by the time a model has been through two retraining cycles, the documentation no longer reflects what's actually deployed. Treat model cards as living documents with a mandatory update trigger on every retrain.

5. Third-Party AI Is Under-Governed

Foundation model providers, cloud AI services, and AI-assisted SaaS tools all fall within A.10 scope. Most organisations haven't run due diligence on the AI components of tools they use daily. Licence scope, data retention policies, sub-processor chains, and model versioning practices all need documenting.

6. Monitoring Is an Afterthought

Drift detection, security telemetry, and performance monitoring get deferred until after deployment, and the result is models degrading in production without triggering a review. Require monitoring activation as a deployment gate that has to clear before go-live.

The pattern that unites all six: controls captured in documentation without a matching operational practice behind them. ISO 42001 auditors are trained specifically to distinguish organisations where AI governance runs from organisations where it's written down. The evidence test stays constant across all six: a working log or record beats a policy sentence describing what should happen, every time.

Nine domains. Thirty-eight controls. ISO 42001 Annex A implementation needs a centralised evidence model, consistent control ownership, and an operational cadence that survives past the initial certification push, and spreadsheets and shared drives run out of road fast at that scale.

SureCloud's AI Governance and Compliance Management capabilities give teams a single place to run the AIMS: from AI inventory and impact assessment through to control evidence, monitoring, and audit readiness.

AI Inventory and Risk Classification

A centralised register of AI systems with purpose, owner, data sources, lifecycle state, and risk classification, plus configurable risk scoring aligned to your AI risk appetite and EU AI Act categories.

Control Evidence and SoA Management

An evidence library with artefacts tagged to Annex A domain, control ID, and EU AI Act article; a Statement of Applicability with documented inclusion and exclusion rationale per control; and version history and snapshots for audit packs.

Compliance Management

A pre-built ISO 42001 framework with Annex A control mapping, a 75% reduction in audit prep time, and a 50 to 65% reduction in manual evidence collection. Continuous Controls Monitoring replaces point-in-time checks with ongoing assurance.

Gracie AI Agents with Personas and Skills perform compliance activities across the AIMS: drafting evidence summaries, flagging control gaps against Annex A obligations, and keeping the evidence library current between audit cycles. Every action stays immutably logged and human-reviewable.