The Compliance Atlas

How the Annex A controls fit together

A.6 (AI System Life Cycle) is the largest and most-novel. Seven controls covering the full AI system lifecycle — design, development, verification, deployment, operation, monitoring, retirement. Most organizations don't yet have lifecycle processes mature enough to evidence each stage. Models are deployed without formal verification gates; monitoring is ad hoc; retirement plans don't exist. A.6 is where most early 42001 implementations spend disproportionate time building from scratch.

A.7 (Data for AI Systems) is where data governance becomes AI governance. Five controls — data acquisition, quality, provenance, preparation, plus general data governance. The data lineage requirements are stricter than under traditional information governance. You must be able to demonstrate where training data came from, how it was processed, what biases it carries, and how it's been validated for the AI system's intended use. ISO/IEC 5259 series is the companion standard for data quality requirements.

A.8 (Information for Interested Parties) is the transparency category. Four controls covering what users, customers, affected parties, and external stakeholders are told about AI systems — capabilities, limitations, risks, and how to report issues. Maps closely to EU AI Act Article 50 transparency obligations and to common AI ethics framework principles. The Information for Users requirement is where most organizations realize they don't have user-facing model cards or risk communications.

A.10 (Third-Party and Customer Relationships) handles the supply chain. Three controls covering supplier management, customer relationships, and third-party AI components. This is uniquely difficult when the third party is OpenAI, Anthropic, or Google — providers whose terms and documentation continue to evolve. As more model providers achieve their own 42001 certification, due diligence on them becomes more standardized.

The Annex C objectives drive the SoA. Unlike ISO 27001 where organizations select Annex A controls based on risk assessment alone, ISO 42001 expects organizations to also consider Annex C's organizational AI objectives — accountability, expertise, availability, fairness, maintainability, privacy, robustness, safety, security, transparency. A health-tech company prioritizes safety and fairness highly; a financial services firm prioritizes accountability and transparency. The SoA must reflect those prioritizations, with Annex A controls justified against them.

Where 42001 evidence work goes wrong

Generic AIIAs that could apply to any system. The most common Stage 2 finding will be AIIAs that are too abstract — describing risks like "potential bias" or "potential security issues" without specifics. A real AIIA references the actual training data, the actual affected populations, the actual evaluation results, the actual mitigations. Auditors test specificity by asking "show me the data behind this fairness claim" or "show me the red-team result that closed this risk."

AI system inventory missing or incomplete. Most organizations don't have a single source of truth for their AI systems. Models live in product team repos, data science notebooks, third-party APIs, embedded in vendor products, in shadow IT. AIMS scope cannot be defined without inventory. Stage 1 audits will repeatedly surface "we found three more systems after we drafted the SoA." Build the inventory first; everything else follows.

Third-party AI evaluation that's just terms-of-service review. A.10 controls require risk evaluation of third-party AI components — and "we read OpenAI's terms" is not evaluation. Real evaluation includes the model's documentation (cards, evals), the provider's own security/privacy posture (their SOC 2 if available, their 42001 if applicable), and your own testing of the model against your use case. As more model providers achieve 42001 cert, this evaluation step gets easier — but it doesn't go away.

Model documentation as afterthought. Model cards and datasheets created retroactively, six months after a model went into production, often miss the original training context, don't reflect current performance, and read as PR rather than documentation. CBs will compare model documentation against actual model behavior — discrepancies surface as findings. The discipline is to write model cards during model development, treat them as living documents, version-control them alongside the model.

Internal audit of AI is hard because AI auditors are scarce. Cl. 9.2 requires competent, objective auditors. For AIMS, that competence includes AI domain knowledge — model evaluation, fairness analysis, AI risk concepts. Most organizations don't have this internal. External AIMS internal auditors are emerging as a service offering through 2025-2026, but supply is limited. Pre-Stage 2 organizations should plan to use a hybrid (information-security-trained internal auditor partnered with AI domain expert).

How 42001 fits with everything else

42001 is the management system layer; AI RMF is the methodology layer; EU AI Act is the regulatory layer. They're not competitors. A mature AI governance program implements 42001's management system, references AI RMF for methodology (especially MEASURE and MANAGE practices), and uses both as the foundation for EU AI Act compliance for high-risk systems. The crosswalk above shows the natural ordering: 42001's clauses and Annex A controls absorb AI RMF's GOVERN/MAP/MEASURE/MANAGE practices and satisfy EU AI Act Article 9 (risk management system) and Article 17 (quality management system).

27001 + 42001 is the dual-cert pattern emerging. Most organizations pursuing 42001 already have ISO 27001. The standards share Cl. 4–10 structure (the Harmonized Structure means policies, leadership, planning, support, operation, performance evaluation, improvement clauses are essentially identical). Internal audit and management review are unified. Risk methodology cascades from 27001's risk approach to 42001's AI-specific risk extensions. The marginal cost of adding 42001 to an existing 27001 program is significantly less than starting 42001 alone.

EU AI Act Article 27 (FRIA) maps closely to 42001's AIIA. Both require structured assessment of fundamental rights / human rights impacts before deploying high-risk AI. Organizations that build mature AIIA processes for 42001 satisfy most of the FRIA documentation expectation. Conversely, FRIA-driven assessments work as 42001 AIIAs with minor formatting changes. As EU AI Act enforcement begins August 2, 2026, expect convergence between the two frameworks' assessment artifacts.

The first 42001 certifications publicized through 2024–2026 — Anthropic, Microsoft, AWS, others — represent the industry's first attempt at formalizing AI governance at scale. These early certifications are doing the work of establishing what evidence looks like for AI lifecycle management, third-party model evaluation, AIIA documentation, and AI-specific incident response. Each early cert published makes the next one easier. Practitioners moving into AI governance have a narrow window to be early-mover credentialed in this space.