Key takeaways
- ISO/IEC 42001 is the international standard for an AI Management System at the organization level. It is not, on its own, a compliance pathway for the EU AI Act.
- The AI Act regulates AI systems (products). ISO 42001 certifies your organization. These are different objects of conformity governed by different legal frameworks.
- The harmonised standards that will provide actual presumption of conformity, prEN 18286 (QMS), prEN 18228 (risk management), prEN 18282 (cybersecurity), and a handful of others, are being finalised by CEN-CENELEC JTC 21, with publication targeted for late 2026.
- Getting ISO 42001 certified is still worthwhile. It builds the governance scaffolding that the EU stack will plug into, and it is recognised internationally as the de facto AIMS reference.
- The operational gap that no consultancy paper addresses is how to translate the standards stack into evidence, audit-ready artifacts, and product-level controls. That is where most programs stall.
What ISO/IEC 42001 actually is, and what it isn’t
ISO/IEC 42001:2023 specifies requirements to establish, implement, maintain, and continually improve an Artificial Intelligence Management System within an organization. It follows the same high-level structure as ISO/IEC 27001 (information security), ISO 9001 (quality), and other Annex SL management standards: a set of generic management clauses numbered 4 through 10, supplemented by a reference set of controls in Annex A.
The management clauses cover organizational context, leadership, planning, support, operation, performance evaluation, and improvement. The same logic that applies to information security applies here. You define a scope, identify interested parties, set a policy, run a risk assessment, treat the risks, monitor the outcomes, and run a management review cycle.
Annex A contains 38 controls grouped under nine control objectives, covering AI policy, internal organization, resources, impact assessment, system life cycle, data, information for interested parties, use of AI systems, and third-party relationships. Annex B provides implementation guidance for each control. Annex C lists AI-specific risk sources. Annex D maps the management system to other ISO standards.
Certification follows a familiar two-stage audit run by an accredited certification body. Stage 1 is a documentation review, typically two days, that confirms the AIMS is designed and documented. Stage 2 evaluates how the system actually operates: are policies executed, are risks reviewed on cadence, is evidence produced, is the management review functioning. After Stage 2 the certification body issues the certificate, valid for three years with annual surveillance audits.
What the certificate proves is bounded. It proves that your organization has a working AI management system, audited against the ISO 42001 requirements, at a point in time. It does not certify any specific AI system. It does not assess whether a particular product meets a specific regulator’s requirements. It does not, by itself, satisfy any element of the EU AI Act.
Why ISO 42001 alone does not equal EU AI Act compliance
The AI Act is product-safety legislation. Its conformity assessment regime applies to AI systems classified as high-risk under Annex III or Annex I. Article 3(20) of the Regulation defines a conformity assessment as “the process of demonstrating whether the requirements set out in Chapter III, Section 2 relating to a high-risk AI system have been fulfilled.” The object of conformity is the system, not the organization.
This is the architectural mismatch that determines everything else. ISO 42001 is built on Annex SL, which is organization-centric: the AIMS scope is the organization, the policy is set by top management, the controls are organizational practices. The AI Act’s Article 17 quality management system requirement is product-centric: the QMS must produce evidence, per AI system, that each of thirteen specific elements is in place.
Those thirteen elements include, among others, a regulatory compliance strategy, design control techniques, development and quality control, testing and validation procedures, technical specifications, data management systems, the risk management system referenced in Article 9, post-market monitoring, incident reporting, communication with national authorities, accountability frameworks, resource management, and an internal audit programme. Each is required to be implemented and documented at the AI system level.
An organization can hold an ISO 42001 certificate and still field a non-conformant high-risk AI system. The certificate says the organization runs an AIMS. It does not say each system within that AIMS has been individually conformity-assessed against the AI Act’s Chapter III, Section 2 requirements. Article 11 makes this explicit: technical documentation must be drawn up for each high-risk AI system before placement on the market, in the form set out in Annex IV, and kept up to date.
The legal mechanism that translates a standard into compliance assurance is the presumption of conformity in Article 40. Where a harmonised standard, or parts of one, is referenced in the Official Journal of the European Union, providers who apply it are presumed to comply with the corresponding AI Act requirements. ISO 42001 is not on that list. It is an international ISO/IEC standard, not a European harmonised one, and it was not developed against the AI Act’s requirements. Even after the European standards bodies endorse parts of it, the presumption mechanism attaches to the European harmonised version, not to the ISO certificate.
The standards stack you actually need for AI Act compliance
In October 2025 the European Commission consolidated its standardisation strategy for the AI Act, requesting CEN and CENELEC to develop harmonised standards across ten areas: risk management, governance and quality of datasets, record keeping, transparency, human oversight, accuracy, robustness, cybersecurity, quality management, and conformity assessment. CEN-CENELEC Joint Technical Committee 21 is doing the work. Several drafts are now in public enquiry or close to it.
Four pieces are already taking shape. They are designed to slot together. ISO 42001 will sit alongside them, not in place of them.
Quality management system: prEN 18286 (Article 17)
On 30 October 2025, prEN 18286, “Artificial Intelligence, Quality Management System for EU AI Act Regulatory Purposes,” became the first harmonised AI standard to enter public enquiry. The European Commission’s published timeline targets formal publication in the fourth quarter of 2026.
Unlike ISO 42001, prEN 18286 is built directly around the product-oriented obligations of Article 17. Its clauses are organised so that each element of the Article 17 QMS list maps to a specific section of the standard. This is what “product-oriented” means in practice: the auditable evidence is per AI system, the documentation traces conformity at the system level, and the certification body assesses each system against the article’s checklist.
This architectural choice is consistent with the New Legislative Framework’s product-safety logic. It is also what gives prEN 18286 the legal effect that ISO 42001 lacks. Once published in the Official Journal, applying it triggers the Article 40 presumption.
Risk management: prEN 18228 (Article 9)
prEN 18228 is the harmonised standard for the risk management system that Article 9 of the AI Act requires every provider of a high-risk AI system to maintain. It is the first horizontal AI risk management standard anywhere drafted with a product-safety focus, rather than a generic enterprise risk management lens.
The standard specifies terminology, principles, and a process for identifying hazards, estimating and evaluating risks, implementing controls, and monitoring the effectiveness of those controls across the AI lifecycle. The risks in scope are those to health, safety, and fundamental rights, the same triad that drives the AI Act’s high-risk classification.
prEN 18228 is explicitly designed to integrate with prEN 18286. Article 17(1)(g) mandates that the QMS must include the risk management system referenced in Article 9. The two standards together provide a coherent answer to “how do I run an AI Act compliant program for a high-risk system.”
On the international side, ISO/IEC 23894:2023 covers similar ground, providing AI-specific risk management guidance as a companion to ISO 31000. It is published and immediately usable, but does not carry the European presumption of conformity. Most programs will adopt ISO/IEC 23894 today and migrate to prEN 18228 once it is published.
Cybersecurity: prEN 18282 (Article 15(5))
Article 15 of the AI Act requires high-risk AI systems to achieve an appropriate level of accuracy, robustness, and cybersecurity. Article 15(5) specifically requires technical solutions to address AI-specific vulnerabilities. prEN 18282 is the harmonised standard being developed to cover those requirements.
Its scope includes the AI-specific threat surface: data poisoning, model poisoning, adversarial examples, model evasion, confidentiality attacks against training data or model parameters, and model flaws that create exploitable behaviours. The standard is also aligned with the corresponding requirements of the Cyber Resilience Act, so providers placing AI-embedded products on the market should be able to use a single body of evidence to satisfy both regimes.
As of early 2026, prEN 18282 is a working draft and has not yet entered the public enquiry phase. It lags prEN 18286 and prEN 18228 by roughly one cycle.
Bias, data quality, transparency, and the rest of the stack
The other harmonised standards under development cover bias and discrimination management (prEN 18283), data quality and governance (prEN 18284), record keeping, transparency, human oversight, accuracy, and robustness. The European AI Office and the JRC are publishing periodic progress notes; the ai-act-standards.com map maintained by Adam Leon Smith is a useful current view of the JTC 21 work programme.
For transparency obligations under Article 50 of the AI Act, the European Commission opened a public consultation on draft guidelines in May 2026. Those guidelines are not standards but they will define the implementation expectations.
AIMS audit and impact assessment: ISO/IEC 42006:2025 and 42005:2025
Two international standards published in 2025 fill gaps the European stack does not directly address. ISO/IEC 42006:2025 specifies requirements for the bodies that audit and certify AIMS implementations against ISO 42001. It builds on ISO/IEC 17021-1, the umbrella standard for management system certification bodies, and adds AI-specific competence requirements: auditors must understand AI lifecycles, data handling, model training, and continuous learning mechanisms before they can credibly assess an AIMS.
ISO/IEC 42005:2025 specifies an AI impact assessment process, a structured analysis of how an AI system’s outputs and outcomes affect individuals, groups, and society across the lifecycle. The AI Act references the concept indirectly through Article 27’s fundamental rights impact assessment obligation for certain deployers, and the operational practices in ISO/IEC 42005 are a sensible starting point for that requirement.
Neither standard is harmonised under the AI Act. Both are useful inputs to a compliance program.
What ISO 42001 still buys you, the case to certify anyway
With the European stack on the horizon, it would be tempting to skip ISO 42001 and wait. We think that is the wrong call for most providers.
First, ISO 42001 and prEN 18286 share the Annex SL high-level structure. Clauses 4 through 10 are the same shape in both standards. An organization that has implemented ISO 42001 has already done most of the work that prEN 18286’s organizational layer requires. The migration is incremental, not greenfield.
Second, ISO 42001 certification is the strongest signal currently available that an organization runs an AI management system. Procurement teams, enterprise buyers, regulators in non-EU jurisdictions, and partners conducting due diligence all read it as such. For 2026 commercial conversations, that signal is worth something concrete.
Third, the certification process surfaces operational gaps that paper compliance hides. An organization that has been through a Stage 2 audit knows where its policy-versus-practice gaps are. It knows which controls are mature, which are documented but not running, which are running but not documented. That diagnostic value is independent of the AI Act.
Fourth, for providers operating outside the EU, ISO 42001 remains the international reference. The United States NIST AI Risk Management Framework is voluntary and complementary; the United Kingdom is signalling a principles-based regulatory approach that will recognise international standards; jurisdictions including Singapore, Canada, and Australia reference ISO 42001 in their guidance.
The practical answer is to treat ISO 42001 as a foundation, not a finish line. Certify the organization. Then, for each high-risk AI system you place on the EU market, build the product-level evidence the AI Act demands, using prEN 18228 / 18282 / 18286 as they publish, and ISO/IEC 23894 / 42005 as immediate stand-ins.
Timing: the Digital Omnibus and when each requirement bites
On 19 November 2025 the European Commission published its Digital Omnibus, a package of measures aligned to the digital rulebook. Among other things, it proposed linking the entry into application of the AI Act’s high-risk provisions to the availability of support tools, including harmonised standards.
Under the proposed timeline, the latest dates by which the high-risk obligations would become applicable are 2 December 2027 for systems covered in Annex III, and 2 August 2028 for AI systems integrated into products covered under existing Union harmonisation legislation in Annex I. Earlier application is possible: if standards are available earlier, the Commission can decide to bring the rules into force earlier.
This matters for planning. It means 2026 is the implementation window. Providers placing high-risk AI systems on the EU market should target a complete, audit-ready compliance program by mid-2027 if they want margin. That program should already include the ISO 42001 scaffolding; the prEN-aligned per-system evidence is what they should build during 2026 against the published drafts, refining as final standards land.
Mapping ISO 42001 Annex A controls to AI Act Article 17 requirements
A practical exercise that almost no current article performs: map the 38 ISO 42001 Annex A controls to the 13 Article 17(1) elements, and find both the matches and the gaps. The exercise tells you what you already cover by doing ISO 42001 well, and what you still need to add.
Strong matches include the following. ISO 42001 A.2 policies for AI map cleanly to Article 17(1)(a), a strategy for regulatory compliance. A.3 internal organization aligns with Article 17(1)(c), an accountability framework. A.4 resources lines up with Article 17(1)(b), techniques, procedures, and systematic actions for design, design control, and verification. A.6 impact assessment maps to Article 17(1)(g), the risk management system, when implemented in concert with ISO/IEC 23894. A.8 information for interested parties supports Article 17(1)(i), the technical specifications, including standards to be applied. A.10 third-party and customer relationships covers Article 17(1)(j), systems and procedures for data management.
There are also real gaps. Article 17(1)(l) explicitly requires a post-market monitoring system, defined in Article 72. ISO 42001 touches the same idea through general performance evaluation in Clause 9, but the Article 72 requirements are more specific, particularly around incident logging, the serious incident reporting obligation in Article 73, and corrective action triggers. You will not satisfy them by running an ISO 42001 management review on its own.
Similarly, Article 17(1)(h)’s communication procedures with notified bodies, competent authorities, customers and other operators are AI-Act-specific and do not have a direct ISO 42001 analogue. The technical documentation per Annex IV that Article 17 supports has no equivalent in ISO 42001, which deliberately stays away from product-level documentation.
The practical recommendation: use ISO 42001 as scaffolding, then add a focused Article 17 implementation track that fills the gaps. Track each Annex A control, mark it as “covers Article 17(1)(x)” or “contributes to Article 17(1)(x)” or “AI-Act-specific gap.” When prEN 18286 publishes, the gap-fillers convert to a presumption-of-conformity pathway. Until then, you document what you do and why.
Operational implementation: what AI Sigil recommends today
For an organization building an EU AI Act program in 2026, our practical recommendation is a five-step sequence.
Step one: inventory your AI systems and classify them by risk tier. Run through Annex III and Article 6 of the AI Act for each AI system in scope. For every system, capture purpose, deployer, provider, data inputs, model class, and risk tier. This inventory is the spine of every later artifact. Without it, every subsequent control is incomplete.
Step two: run a baseline ISO 42001 readiness audit at the organization level. The audit produces a gap analysis: what the AIMS already covers, what is policy-only, what is missing. Treat it as scaffolding to build on, not a target to hit. The output feeds your management review cadence and your Statement of Applicability for the certification audit.
Step three: for each high-risk system, build a per-system technical file matching Annex IV. The Annex IV elements are the technical documentation that Article 11 requires. Each system gets its own file, owned by a single accountable role inside the provider organization, refreshed against versioning and post-market events.
Step four: establish a risk management system per Article 9. Do not wait for prEN 18228. Use ISO/IEC 23894 as a working template and structure the program so that the move to prEN 18228 is a swap, not a rewrite. The process must run continuously across the AI system lifecycle and must be auditable.
Step five: stand up a post-market monitoring loop per Article 72. This is the operational obligation most programs underestimate. Article 72 requires providers to actively collect, document and analyse data on the performance of high-risk AI systems throughout their lifecycle. Tie it to incident reporting per Article 73, and to the corrective action triggers in your QMS.
Every step in this sequence produces specific evidence types: an AI system register, a Statement of Applicability, a per-system technical file, risk treatment records, a monitoring dashboard with logged incidents. The compliance is in the evidence, not in the policy.
This is where most programs stall, and where AI Sigil’s platform plugs into the standards stack. We treat the AI system register and the per-system technical file as first-class objects, link controls and evidence to specific Annex A entries, and surface gaps against Article 17’s thirteen elements as a live operational dashboard rather than an annual paper exercise.
Frequently asked questions
Is ISO 42001 mandatory under the EU AI Act?
No. No standard is mandatory under the AI Act. Standards are voluntary tools that, when harmonised and referenced in the Official Journal, provide presumption of conformity with specific articles. Providers can choose to demonstrate compliance through other means, but the burden of proof shifts to them.
What is the difference between ISO 42001 and prEN 18286?
ISO 42001 is an international AI management system standard, organization-level, published by ISO/IEC. prEN 18286 is a European harmonised standard, product-oriented, built directly around Article 17 of the EU AI Act and designed to provide presumption of conformity once published. They share the Annex SL clause structure but address different objects of conformity.
Can I get certified to prEN 18286 today?
Not yet. As of early 2026 prEN 18286 is in the public enquiry phase, with publication targeted for Q4 2026. Certification schemes will follow publication. You can prepare against the draft, but a formal certificate is not available.
How long does ISO 42001 certification take?
For an organization that already has a mature management system program, typically six to nine months from kickoff to certificate, including the readiness work, Stage 1, and Stage 2 audits. For organizations starting from a low baseline, twelve to eighteen months is more realistic. The variable is not the audit itself; it is closing the policy-versus-evidence gaps the readiness work surfaces.
Will ISO 42001 satisfy non-EU AI regulations?
Partially. The Colorado AI Act, the New York City automated employment decision tool law, and several other US state laws focus on specific high-risk use cases and have their own assessment regimes. ISO 42001 provides governance scaffolding that supports those programs but does not, on its own, satisfy any of them. The United Kingdom’s principles-based approach is more accommodating of international standards; the United States NIST AI Risk Management Framework is voluntary and complementary.
What is the relationship between ISO 42001 and ISO 27001?
Both follow the Annex SL high-level structure, share Clauses 4 through 10, and use Statement of Applicability mechanics. The integration is straightforward: organizations already certified to ISO 27001 can extend their AIMS scope through ISO 42001 with a shared management review, shared risk methodology, and many shared controls. ISO 42001 Annex A adds AI-specific controls that ISO 27001 does not address, particularly around impact assessment, AI system lifecycle, and third-party AI relationships.
From paper to product
ISO 42001 builds the management system. The harmonised European stack, prEN 18286 for the QMS, prEN 18228 for risk, prEN 18282 for cybersecurity, and the cohort following them, will build the product-level conformity assessment regime that the AI Act actually requires. ISO/IEC 23894 and 42005 fill the immediate gaps until the European versions publish.
No single certificate will make a high-risk AI system AI-Act-compliant. Compliance is an operational practice, sustained at the system level, producing the evidence that Article 11 and Article 17 demand. The standards stack is the scaffold. The work is in the implementation.
If you are building that implementation, AI Sigil turns the stack into operational controls, evidence, and audit-ready artifacts. Start with the inventory, build the per-system technical files, and run the post-market monitoring loop. That is how paper becomes product.