DISC InfoSec blogCompliance Event vs. Compliance Capability: Why ISO 42001 is How You Actually Meet the EU AI Act

Jul 02 2026

Compliance Event vs. Compliance Capability: Why ISO 42001 is How You Actually Meet the EU AI Act

Category: ISO 42001 — disc7 @ 9:50 am

How they relate

The cleanest way to frame it: the EU AI Act defines outcomes; ISO 42001 supplies the machinery to produce them repeatedly. The Act (Regulation (EU) 2024/1689) is enforceable law with fines up to €35M or 7% of global turnover for prohibited practices. ISO 42001 is a voluntary, certifiable management system standard published December 2023. One can’t substitute for the other — an ISO 42001 certificate is not a legal safe harbor, and Act compliance without a management system is a snapshot that decays the moment your AI systems, vendors, or models change.

How they complement each other. The Act tells you a high-risk system needs a risk management system (Art. 9), data governance (Art. 10), technical documentation (Art. 11), logging (Art. 12), human oversight (Art. 14), and — critically — a full quality management system with 13 required components (Art. 17). It doesn’t tell you how to build, document, audit, or continually improve any of that. ISO 42001’s Clause 4–10 PDCA structure and 38 Annex A controls are exactly that operational layer: the AISIA process, the AI system register, the SoA, supplier assessments, internal audit, management review. The Act’s own cross-framework guidance recognizes that ISO 42001 certification can support demonstration of Art. 17 QMS compliance, and the SoA process adapts naturally into an AI Act conformity mapping.

How they depend on each other. The dependency is mostly one-directional. The Act doesn’t need ISO 42001 to exist — but a 42001 AIMS must ingest the Act. Clause 4 (context of the organisation) requires you to identify legal obligations as interested-party requirements, so for any organisation touching the EU market, the AI Act becomes a mandatory input to your AIMS scope, risk assessment, and SoA justifications. Practically: the Act feeds requirements into the AIMS; the AIMS feeds evidence back out for conformity assessment (Arts. 43–48), the EU Declaration of Conformity (Art. 47, retained 10 years), and post-market obligations.

Shared control mapping

EU AI Act	Requirement	ISO 42001	Shared control objective
Art. 9	Risk management system (lifecycle-spanning)	Clause 6.1.2 + A.5.2–A.5.5	Continuous AI risk + impact assessment (AISIA) informing control selection
Art. 10	Data governance, bias detection, representative datasets	A.7.2–A.7.6	Data lifecycle governance: acquisition, quality, provenance, preparation
Art. 11	Technical documentation (Annex IV)	A.6.2.3, A.6.2.7	Documented design decisions, specifications, limitations, failure modes
Art. 12	Record-keeping / automatic logging	A.6.2.8	Event logs sufficient for incident investigation and audit
Art. 13	Transparency + instructions for use to deployers	A.8.2, A.9.4	Intended-purpose documentation and user-facing system information
Art. 14	Human oversight (override, intervene, disregard)	A.9.2, A.6.1.3	Human review of AI outputs, escalation and override procedures
Art. 15	Accuracy, robustness, cybersecurity	A.6.2.4, A.6.2.6	Pre-deployment V&V (bias/adversarial testing) + production drift monitoring
Art. 17	Quality management system (13 components)	Clauses 4–10 (entire AIMS)	The management system itself — policy, roles, competence, audit, improvement
Art. 26	Deployer obligations (competence, monitoring, logs)	A.4.6, A.9.2–A.9.3	Staff competence, responsible-use processes, use monitoring
Art. 50	Transparency (chatbots, synthetic media)	A.8.5	Informing interested parties they’re interacting with AI
Art. 72	Post-market monitoring plan	Clause 9.1, A.6.2.6	Ongoing performance evaluation with defined thresholds
Art. 73	Serious incident reporting	A.8.4, Clause 10.2	Incident classification, escalation, regulatory notification, corrective action

Third-party AI in the supply chain is the one area the Act handles thinly relative to 42001 — A.10.2/A.10.3 (responsibility allocation, supplier due diligence with contractual AI clauses) go further than the Act’s provider/deployer split, and they’re what actually protects a deployer who inherits risk from a GPAI vendor.

Where to start

Start with three Act-driven steps that take days, not months, then build the 42001 system underneath:

Role and inventory first. Determine whether you’re a provider or deployer under Art. 3 (most companies are both), and build the AI system register — 42001’s most commonly missed artifact, and the input everything else depends on. Shadow AI and SaaS-embedded AI features count.
Prohibited-practices screen (Art. 5). The 8 original prohibitions have applied since February 2025, and the 9th (nudification/CSAM) lands 2 December 2026. This is the only tier carrying 7%-of-turnover exposure, so screen it before anything else.
Risk-tier classification (Art. 6). Sort your register into prohibited / high-risk / limited / minimal. This tells you how much of the mapping table above actually applies to you.
Then build the AIMS. With classification done, implement ISO 42001 as the delivery vehicle: scope (4.3), AI policy (5.2), AISIA and risk assessment (6.1.2), SoA — with each applicable Annex A control’s justification column citing the AI Act article it discharges. That single move turns your SoA into a living conformity map.

The AI Omnibus (May 2026) extended the Annex III high-risk deadline to 2 December 2027, which changes the calculus in one specific way: you now have time to do this via a management system rather than a panic project. GPAI obligations and Art. 50 transparency deadlines did not move, so those bite first.

My perspective

If I had to compress it: the EU AI Act is a compliance event; ISO 42001 is a compliance capability. Organizations that chase the Act article-by-article end up with a binder of point-in-time evidence that’s stale by the next model update. Organizations that build the AIMS first get Act conformity as a byproduct — plus reusable coverage for NIST AI RMF, Colorado’s AI Act, and whatever jurisdiction regulates next, because the artifacts (register, AISIA, SoA, supplier assessments, incident process) are framework-agnostic at their core.

The honest caveats: 42001 certification is not presumption of conformity — the Art. 40 harmonised standards that would grant that are still in development, and a certificate won’t save a provider whose system fails Art. 15 accuracy requirements in practice. And the Act is scoped to the EU market while 42001 is scoped to your organization, so a pure-42001 approach can under-invest in the Act’s market-facing mechanics: CE marking, EU database registration, the Declaration of Conformity.

So my recommendation is deliberately asymmetric: classify under the Act first (cheap, fast, identifies your real exposure), then invest the bulk of your effort in the 42001 AIMS, wiring every SoA justification to an Act article. The deadline extension to December 2027 is exactly enough runway to do it properly — a Stage 1/Stage 2 certification cycle typically runs 6–12 months, which means starting in 2026 gets you certified with a full surveillance cycle of operating evidence before enforcement begins. Waiting turns a management-system build into a fire drill.

If it’s useful, I can turn this into a blog post and hero image in the DISC brand system, or build out the full Act-to-Annex-A crosswalk as a downloadable gap-assessment worksheet.

AI Attack Surface ScoreCard

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative