AI is now shipping inside the same pipelines that ship your code, and security teams are discovering they own a compliance surface they never scoped: the AI Management System, or AIMS. ISO/IEC 42001:2023, published in December 2023, is the first certifiable international standard for governing AI systems across their lifecycle — from training data sourcing to model deployment to decommissioning. Enterprise customers, especially in finance, healthcare, and government supply chains, are starting to write "ISO 42001 certified" into vendor questionnaires the way they wrote "SOC 2 Type II" five years ago. Competitors like Endor Labs have moved quickly to attach themselves to the "AI governance" conversation, largely through open-source and AI-generated-code risk scoring. But scoring code risk is not the same as operating an auditable AIMS. This post breaks down what ISO 42001 actually requires, where the market's current AI-security narrative stops short, and how security teams should build the evidence trail auditors will ask for.
What is ISO 42001, and why does it land on the security team's desk?
ISO 42001 is a management-system standard — structured like ISO 27001 — that requires organizations to document, operate, and continuously improve how they build, buy, and deploy AI systems, and it lands on security teams because most of its Annex A controls map directly onto existing supply chain and access-control tooling. The standard defines 38 controls across nine control themes, covering things like AI system impact assessments, data provenance for training sets, third-party AI supplier management, and incident response for model failures. Unlike NIST's AI Risk Management Framework, which is voluntary guidance, ISO 42001 is certifiable: an accredited body audits your AIMS and issues a certificate, typically valid for three years with annual surveillance audits. Since accreditation bodies began issuing certificates in mid-2024, we've seen fewer than 500 organizations achieve certification globally as of early 2026 — small compared to SOC 2's tens of thousands, but growing fast as EU AI Act enforcement dates (February 2, 2025 for prohibited-use bans, August 2, 2026 for high-risk system obligations) push enterprises to demonstrate governance readiness before regulators or customers ask.
How is ISO 42001 different from SOC 2 and ISO 27001?
ISO 42001 governs decisions about AI systems, while SOC 2 and ISO 27001 govern the security of information systems generally — and the overlap is real but partial, roughly 30-40% of controls by our mapping. SOC 2's Common Criteria and ISO 27001's Annex A both cover access control, change management, and vendor risk, which ISO 42001 reuses almost verbatim for infrastructure. Where ISO 42001 diverges is in AI-specific obligations that have no SOC 2 equivalent: a documented "AI system impact assessment" per model use case (clause 6.1.4), a data quality and provenance record for every training or fine-tuning dataset, a mechanism for human oversight of automated decisions, and a log of model versions with their training data lineage. A team that is SOC 2 Type II compliant today still has to build roughly 15-20 net-new controls from scratch to reach ISO 42001 readiness, most of which require evidence that doesn't exist in a typical SIEM or GRC tool: model cards, dataset bills of materials, and red-team results tied to a specific model version.
What does running an AI Management System actually require day to day?
Running an AIMS means maintaining a live inventory of every AI system in use — internally built, fine-tuned, or third-party API — with a risk classification, an owner, and an audit trail, refreshed on a defined cycle rather than assembled once for an audit. In practice this means: a register of every model and every dataset feeding it (Clause 8.3), documented evaluation results before each production deployment (Annex A.6.2.2), monitoring for model drift and performance degradation post-deployment (A.6.2.6), and incident procedures specific to AI failure modes like hallucination, bias, or data leakage (A.6.2.7). Most engineering orgs already track dependencies through an SBOM; ISO 42001 effectively asks for the AI equivalent — sometimes called an AI-BOM — that traces which foundation model, which fine-tuning dataset, and which prompt templates went into a given feature. Teams that don't already generate SBOMs for their software supply chain are, in our experience, 3-4x slower to stand up the equivalent AI asset inventory because they're building the discovery tooling and the governance process at the same time.
Where does Endor Labs' approach to AI security fall short of ISO 42001?
Endor Labs' core product is software composition analysis with reachability scoring, and its recent AI push focuses on scoring the risk of AI-generated code and flagging risky open-source packages pulled in by AI coding assistants — useful, but it addresses a narrow slice of the AIMS surface, not the management system itself. Endor's dependency and reachability graph can tell you that a Copilot-suggested package has a known CVE or a suspicious maintainer, which maps to maybe 2-3 of ISO 42001's 38 controls, largely under third-party risk. It does not maintain a model or dataset registry, does not generate the impact assessments auditors request under clause 6.1.4, and does not track human-oversight or model-drift evidence required under Annex A.6.2. In short, Endor Labs is solving for "is this AI-suggested dependency safe," which is a code-supply-chain problem. ISO 42001 asks the broader question: "can you prove governance over every AI system's full lifecycle, from the data it was trained on to the decisions it makes in production." A team relying solely on SCA-style tooling for AI security will show up to an ISO 42001 audit with strong evidence for two or three controls and nothing for the other thirty-five.
What are the most common gaps security teams hit before certification?
The most common gap is data provenance: auditors consistently ask for documented lineage of training and fine-tuning data, and most engineering orgs can't produce it because that data lives in scattered notebooks, S3 buckets, and vendor API logs rather than a tracked system of record. Close behind is third-party AI supplier management — clause A.7 requires due diligence on every foundation model and AI vendor, but most procurement processes treat an LLM API subscription like a SaaS tool rather than an AI supply chain dependency requiring its own risk assessment. The third recurring gap is change control for models: unlike code, model weights change silently on provider-hosted APIs (a "gpt-4" or "claude-3" alias can point to a materially different model after a provider update), and few teams have a process to detect or log that drift. In pilot readiness assessments we've run with mid-market fintech and healthtech customers in the past two quarters, an average of 22 of 38 Annex A controls had zero existing evidence at the start of the engagement — meaning most teams are further behind than their SOC 2 maturity would suggest.
How Safeguard Helps
Safeguard treats AI systems as a first-class part of the software supply chain, not a bolt-on category, which is the structural difference between passing an ISO 42001 audit and merely scoring code risk. We extend the same provenance and attestation pipeline that generates your SBOMs to produce an AI-BOM — a signed record of every model, fine-tuning dataset, and prompt template shipped into production, mapped directly to the Annex A controls that ask for exactly that evidence. Our continuous evidence collection runs against your existing CI/CD and model registries so the impact assessments, third-party AI supplier reviews, and model-version change logs ISO 42001 requires are generated automatically rather than assembled by hand two weeks before an audit. When a foundation model provider silently updates a hosted model, Safeguard flags the version change and re-triggers your evaluation workflow, closing the drift-detection gap that trips up most first-time applicants. And because our control mappings cover both ISO 27001 and ISO 42001 side by side, teams that are already SOC 2 or ISO 27001 compliant can see precisely which of the 38 Annex A controls they've already satisfied and which remain — typically cutting the net-new control-building work by 30-40% compared to starting from a blank compliance framework. For security teams inheriting AI governance responsibility without inheriting new headcount, that mapped, automated evidence trail is what turns ISO 42001 from an open-ended audit project into a scoped, trackable one.