ISO 42001 vs EU AI Act: how they relate

Does ISO 42001 certification satisfy the EU AI Act?

No, ISO 42001 certification does not by itself satisfy the EU AI Act. ISO/IEC 42001 is a voluntary management system standard, and it does not meet the Article 17 quality management system that providers of high-risk AI systems must document. The European Commission says ISO/IEC 42001 helps set up an AI management system but does not match the objectives and definitions of the AI Act's quality management system, which is why it requested a new standard for that purpose. A customer or board asking whether the certificate covers the Act should hear that the certificate is useful evidence for part of the job, not a substitute for the regulatory obligations.

The answer then depends on two questions the organization must settle for itself. The first is its role under the Act: a provider that develops or places an AI system on the market carries different obligations from a deployer that uses one, and other operators have their own duties. The second is whether each system is high-risk, which determines whether Article 17 and the Chapter III requirements apply at all. Confirm both with counsel or your regulatory team before you describe the certificate to a customer as AI Act coverage. Also confirm the application dates for each obligation, since the Digital Omnibus changed them: Article 113 as amended sets 2 December 2027 for Annex III systems and 2 August 2028 for systems under Annex I product legislation.

Practically, map each high-risk system to the Article 17 aspects and to the harmonised standard that covers them. Ask whether a certification body or internal team can show where the ISO 42001 evidence supports a given Article 17 aspect and where a gap remains. The first harmonised standard cited under the Act, EN 18286:2026, was cited in the Official Journal on 14 October 2026, so check the Commission's standardisation page for the current list before you plan against it. Ask any consultant or certification body to state in writing which AI Act obligations its scope does and does not cover.

What Article 17 asks for that ISO 42001 does not cover directly

Article 17 of the EU AI Act requires providers of high-risk AI systems to run a documented quality management system covering 13 aspects. ISO/IEC 42001 overlaps with several of them, but the Commission has said its objectives and definitions do not match the AI Act's quality management system. The cards below group those aspects and show where the overlap stops.

Compliance strategy and procedures

Article 17 expects a written strategy for complying with the AI Act, covering the conformity assessment procedure and how changes to a high-risk system are managed. ISO/IEC 42001 gives you an AI policy, roles and document control, so much of the scaffolding exists. The gap is the AI Act-specific content: which Annex III or Annex I obligations apply to each system and who signs the conformity decision. Check that your statement of applicability maps to those obligations, not only to the Annex A controls.

Testing and validation procedures

The regulation asks for examination, testing and validation procedures run before, during and after development, with defined criteria for each. ISO/IEC 42001 requires verification and validation under its life cycle controls, so the process overlap is real. Where it falls short is in the acceptance criteria tied to health, safety and fundamental rights, since the JRC notes that international standards have focused more on the organization's objectives. Confirm that your test criteria address those risks explicitly.

Data management for training and testing

Article 17 requires documented data management procedures covering collection, labeling, cleaning, aggregation and the assumptions made about data. ISO/IEC 42001 covers data for AI systems in its A.7 controls on management, acquisition, quality, provenance and preparation. The overlap is substantial, but the AI Act adds specific tests for bias and representativeness in the data sets. Ask your assessor which data quality evidence they will expect for high-risk classes of data.

Risk management system under Article 9

The quality management system must include the Article 9 risk management system as a component. ISO/IEC 42001 requires AI risk assessment and treatment, and ISO/IEC 23894 gives related guidance, so the two processes share structure. The difference lies in scope and method: Article 9 is a continuous, lifecycle process aimed at risks to health, safety and fundamental rights. Record how each Article 9 risk is linked to a residual risk decision and an owner.

Post-market monitoring and incident reporting

Article 17 requires procedures for post-market monitoring of the system after it is placed on the market, along with serious incident reporting to authorities. ISO/IEC 42001 has operational monitoring and event logging controls, plus communication controls for incidents under A.8. Those controls are not designed around the AI Act's reporting duties or timelines. Map your monitoring signals and incident triggers to the regulatory reporting obligations before you rely on the management system alone.

Documentation, record keeping and accountability

Article 17 expects the quality management system to be documented and kept under a responsible person, with records retained for the period the regulation sets. ISO/IEC 42001 requires documented information and assigned roles, which covers much of the structure. The gap is in the AI Act's specific technical documentation contents and retention periods, which are separate from ISO's documented information requirements. Check the retention and technical file contents against the regulation, not only against ISO clause 7.5.

Where EN 18286 and harmonised standards stand today

EN 18286 is the first harmonised standard under the EU AI Act. CEN and CENELEC approved it in June 2026, and Commission Implementing Decision (EU) 2026/2274 cited EN 18286:2026 in the Official Journal on 14 October 2026. It is titled *Artificial intelligence: Quality management system for EU AI Act regulatory purposes*, and it was drafted as prEN 18286 before its public enquiry on 30 October 2025.

Citation date: The standard was cited in the Official Journal on 14 October 2026, which is the date that matters for presumption of conformity.
Purpose: It addresses the quality management system that Article 17 requires of high-risk AI providers, which ISO/IEC 42001 does not match.
Approval route: CEN and CENELEC approved it in June 2026 before the Commission cited it.
Scope limit: Citation covers only the requirements the standard actually addresses, so other AI Act duties need separate evidence.
Commission reference: The official citation is the Implementing Decision itself, available through the EUR-Lex link in the sources.

Before relying on EN 18286 in a plan, confirm the current version and the Official Journal reference directly against the Implementing Decision and the CEN-CENELEC publication.

Which path fits: ISO 42001 only, ISO 42001 plus AI Act evidence, or a QMS built to EN 18286

This table compares three paths by the organization's role under the EU AI Act and what each path produces. Read the rows against your role and risk category, which legal counsel should confirm before you commit budget. The main takeaway is that ISO/IEC 42001 certification alone does not stand in for the Article 17 quality management system that high-risk providers must document.

Role or case	ISO 42001 only	ISO 42001 plus AI Act evidence	QMS built to EN 18286
Provider of a high-risk AI system (Annex III or Annex I)	Governance management system and AI policy evidence, but not the Article 17 quality management system on its own	ISO 42001 management system extended with technical documentation, Article 9 risk records, post-market monitoring and incident records mapped to Article 17	Quality management system aimed at the AI Act's own requirements, expected to support presumption of conformity where the harmonised standard covers the obligation
Deployer of a high-risk AI system	Useful for internal use governance and A.9 use controls, with limited coverage of deployer duties	Adds evidence of intended-purpose use, human oversight records and monitoring of the provider's instructions	Usually not the main path, since the QMS standard targets providers; confirm whether any deployer duty is relevant
General-purpose AI model provider or downstream user	Covers policies, third-party and customer controls and some transparency duties	Adds documentation for downstream providers and copyright and training data summaries where applicable	Not the target of EN 18286, so it does not supply the evidence these obligations need
Operator of limited-risk or minimal-risk AI	Often sufficient for customer questionnaires and voluntary governance	Adds transparency disclosures and AI literacy records as needed	Generally disproportionate unless a customer or regulator asks for it
Who it fits best	Organizations that need a certifiable AI governance system for customers or procurement	Organizations with high-risk products that want one evidence set for both customers and the AI Act	Providers preparing a conformity route that depends on the EN 18286 presumption of conformity
What it does not cover	Article 17 scope, conformity assessment, CE marking and the AI Act's own definitions	Does not itself confer presumption of conformity or replace a notified body where one is required	Does not replace certification to ISO/IEC 42001 if a customer requires it, and needs confirmation of the cited standard's scope
What to confirm with counsel	Whether any system is high-risk and which Annex applies	Application date for the system under the amended Article 113 timetable	Whether the cited EN 18286 version covers your system's obligations

Why standards bodies see AI risk differently

The JRC AI Watch note from October 2024 draws a line between two standardization priorities. It says AI Act standards must prioritize risks to health, safety and fundamental rights, while international standardization, including the AI management system work in ISO/IEC 42001, has concentrated more on protecting the objectives of the organizations that use AI. An ISO 42001 program is built around that second concern. Its AI policy, objectives under clause 6.2, risk treatment under clause 6.1 and the A.2 policy controls all start from what the organization is trying to achieve and what could stop it from achieving it. That is a sound basis for governance, but it does not by itself put people who are affected by an AI system at the center of the analysis.

For a provider of a high-risk AI system, the practical gap sits in the risk register. Before relying on an ISO 42001 scope statement, check whether the AI risk assessment and the A.5 impact assessment record harms to health, safety and fundamental rights as their own category, with named owners, severity criteria and treatment decisions, rather than folding them into business risk. Confirm that the statement of applicability justifies every A.5 and A.6 control in terms an EU market surveillance authority would recognize. Ask your certification body whether it will examine that link, because the audit scope agreed with it determines what gets tested.

Treat this difference as a planning input, not a reason to abandon the management system. Map each regulator-facing risk to the Article 9 risk management system and the Article 17 quality management system obligations, and document where an ISO 42001 record is insufficient on its own. Those gaps are the additions to scope. Review the Commission's standardisation FAQ and the EN 18286 quality management system standard before deciding which additional records, test evidence and post-market monitoring procedures your program needs.

How to map existing ISO 42001 evidence to AI Act obligations

This sequence shows how an organization that already runs an ISO/IEC 42001 management system can test its existing records against the AI Act's high-risk provider obligations, and where the gaps sit that a harmonised standard or separate quality management system would need to close.

Inventory AI systems and their roles
List every AI system the organization builds, places on the market, deploys or uses, and record for each whether the organization acts as provider, deployer, importer, distributor or another operator under the AI Act. Use the AI system register that the ISO 42001 resource and life cycle records already feed, and add the AI Act role beside each entry. The step is done when every system has a named owner and a recorded operator role that a reviewer can trace back to a specific product or internal use case.
Confirm the risk category of each system
For each inventoried system, decide whether it is prohibited, high-risk under Annex III, covered by Annex I product legislation, subject only to transparency duties, or outside the high-risk regime. Record the legal reasoning with the article reference and the date of the assessment, and have legal or compliance counsel review any borderline case. Confirm the application dates for high-risk obligations against the amended Article 113 before setting the working schedule. The output is a signed categorization record per system.
Map Annex A controls and the statement of applicability
For each system in scope, take the clause 6.1.3 statement of applicability and trace which Annex A controls and which implemented records answer each of the 13 Article 17 aspects, from the compliance strategy and design control through data management, the Article 9 risk management system, testing, post-market monitoring and incident reporting. Mark each aspect as covered, partly covered or not covered, and cite the record that supports it. The output is a crosswalk table showing Article 17 aspect, ISO control reference, evidence location and status.
Identify gaps in risk management and post-market monitoring
Review the crosswalk for aspects that the ISO records cover only loosely. Common gaps include an Article 9 risk management system that runs through the whole life cycle with documented residual risk decisions, and a post-market monitoring plan that feeds field data back into risk and quality records. Check also record keeping, human oversight and incident reporting procedures against the AI Act's own terms, because an ISO control with a similar name may not describe the same activity. The output is a gap register with an owner, a remediation action and the Article 17 aspect each gap affects.
Decide the harmonised standard or conformity route
For high-risk systems, determine whether the organization will rely on a harmonised standard once it is cited in the Official Journal, or will follow another conformity route the AI Act allows. Note that the Commission cited EN 18286:2026 on 14 October 2026 under Implementing Decision (EU) 2026/2274, while the Commission's standardisation page did not report other harmonised AI standards as cited at its last update, so confirm the current status before relying on any standard. Check the presumption of conformity under Article 40 applies only to the requirements the cited standard covers. The output is a written route decision per system, reviewed by the notified body or counsel where a third-party assessment applies.
Assign remediation and document the quality management system
Turn each gap register entry into a work item with an accountable owner, the evidence it will produce and a review checkpoint, then assemble the documented quality management system that Article 17 requires around the existing ISO records. Keep the ISO 42001 management system as the governance layer and cross-reference rather than copy its documents. The step is complete when each Article 17 aspect points to a current, owned document and the open items are tracked to closure.
Confirm the mapping with an independent reviewer
Ask an independent assessor or the certification body to review the crosswalk and gap register, and confirm with the organization's own legal counsel which conformity assessment applies. An implementation partner can prepare the crosswalk, but only an independent auditor, assessor or notified body issues assessment outcomes or certificates. The output is a dated review record that states what was checked, by whom, and which open points remain before placing the system on the market or putting it into service.

What the fines mean for planning

Article 99 sets three penalty tiers, each with a fixed amount and a turnover percentage, and the higher figure applies unless a cap says otherwise. The cards below cover each tier, the SME cap, the Digital Omnibus extension and how role and conduct shape exposure. Read them together before deciding how much ISO 42001 work the organization can justify on AI Act grounds.

Prohibited practices ceiling

The highest tier applies to prohibited practices, with a maximum of EUR 35 million or 7% of worldwide annual turnover, whichever is higher. Certification does not reduce this exposure, because the question is whether a system falls into a banned category at all. Before any AI feature reaches EU users, record a legal review that checks the use case against the prohibited list and keep that record with the system's documentation.

Most operator obligations

The middle tier covers most operator obligations, with a maximum of EUR 15 million or 3% of worldwide annual turnover, whichever is higher. It reaches provider and deployer duties for high-risk systems, which is where a quality management system and a risk management process become relevant. Map each operator duty to a named owner and an evidence source, so the organization can show which obligations it has met when an authority asks.

Misleading information exposure

The lowest tier covers supplying incorrect, incomplete or misleading information to notified bodies or national authorities, with a maximum of EUR 7.5 million or 1% of worldwide annual turnover, whichever is higher. This matters for ISO 42001 claims, because a certificate described more broadly than its scope can create exposure. Check that every AI governance statement in tenders, questionnaires and regulator replies matches the scope in the statement of applicability.

SME cap under Article 99(6)

For SMEs, including start-ups, Article 99(6) caps each AI Act fine at the lower of the fixed amount and the turnover percentage. For a smaller organization, the lower figure is the one to plan against. Confirm with counsel whether the organization qualifies as an SME and how its turnover is measured for the calculation, because the answer changes the exposure figure.

Small mid-cap extension

The Digital Omnibus extended the lower cap to small mid-cap companies for fines under paragraphs 4 and 5 of Article 99. Paragraph 4 covers the operator obligations tier and paragraph 5 covers the misleading information tier, so the prohibited practices tier is not included in the extension. Organizations between SME and large size should confirm their classification before they budget against the upper figures for these tiers.

Role and conduct set exposure

The figures are maximums. An authority sets any fine by reference to the factors Article 99 lists, including the nature and gravity of the infringement, the steps taken to mitigate it and the organization's cooperation. The organization's role as provider, deployer or other operator also determines which obligations apply. Document the role for each AI system, and record the remediation steps taken when a gap is found.

Who owns the AI Act conformity work

The organization that provides or deploys a high-risk AI system carries the obligations in the EU AI Act. It decides whether a system is in scope, classifies it, sets its intended purpose and owns the quality management system described in Article 17. Legal conclusions about classification, role (provider, deployer or other operator) and applicable deadlines also stay with the organization, usually with counsel input.

Scope and classification: Deciding which systems are high-risk, which Annex III or Annex I route applies and which application date the Digital Omnibus sets for each.
Quality management system: Owning the documented policies, procedures and accountable roles that cover the 13 aspects listed in Article 17.
Risk and data decisions: Accepting residual risk, approving datasets and setting human oversight arrangements.
Ownership of evidence: Keeping technical documentation, logs and post-market monitoring records current and retrievable.
Declarations and registrations: Signing the declaration of conformity and any registration steps where the Act requires them.

Before relying on any date or article reference, confirm it against the official text and the Commission's AI Act Service Desk with counsel.",

Common questions about ISO 42001 and the AI Act

Does the EU AI Act require ISO 42001 certification?

No. The AI Act does not require ISO/IEC 42001 certification. ISO 42001 is a voluntary management system standard that an organization chooses to adopt. The binding obligations sit in the Act itself, including the Article 17 documented quality management system that providers of high-risk AI systems must have. Whether a system is high-risk depends on its intended use and the Annex it falls under, so start by classifying each system. Demand for ISO 42001 usually comes from customers, procurement teams and contracts, not from the law. Confirm the classification and the obligations that apply to your products with legal counsel.

Does ISO 42001 help with EU AI Act compliance?

Yes, but only in part. The European Commission says ISO/IEC 42001 helps set up an AI management system, while its objectives and definitions do not match the AI Act's quality management system. An organization that already runs ISO 42001 can reuse its AI policy, defined roles, impact assessment records, internal audit and management review routines. It still has to map those records against the 13 aspects of Article 17, including the Article 9 risk management system, testing, data management, post-market monitoring and incident reporting. Treat that mapping as a separate workstream, and read the Commission's standardisation FAQ before you scope it.

Which EU AI Act dates should we plan around?

Plan around 2 December 2027 for high-risk systems under Annex III and 2 August 2028 for systems covered by Annex I product legislation. Those dates come from Article 113 as amended by the Digital Omnibus, which entered into force on 27 July 2026. The Act became generally applicable on 2 August 2026, so some obligations already apply. Check which applies to each product, since the date depends on the Annex. Work backward from the applicable date to set when your quality management system, technical documentation and evidence must be ready.

Do high-risk AI providers need EN 18286?

The Act does not name a specific standard that providers must use. EN 18286 is, however, the harmonised standard written for the Article 17 quality management system. CEN and CENELEC approved it in June 2026, and the Commission cited EN 18286:2026 in the Official Journal on 14 October 2026 under Implementing Decision (EU) 2026/2274. Under Article 40, a system that conforms to a cited harmonised standard gets a presumption of conformity for the requirements that standard covers. Providers who want that presumption for their quality management system should plan to meet EN 18286. Confirm the route with counsel and with the body that will assess conformity.

What evidence should we prepare for an AI Act quality management system?

Start with the 13 aspects in Article 17, labeled (a) to (m), and keep a current document or record for each one. Auditors and market surveillance authorities will ask to see:

A compliance strategy and the procedures that support it
Risk management records under Article 9, with decisions and residual risk
Data governance, testing and validation results for each high-risk system
Post-market monitoring plans and serious incident reporting records

Each record should show an owner, a date, the version of the system it covers and the approval that closed it.

How much internal effort does EU AI Act readiness take?

Your supplied figures do not include an effort estimate, so ask for one in writing rather than relying on a general figure. The effort depends on how many systems are high-risk, how many of them already have ISO 42001 or ISO 27001 records, and how many teams own data, testing and product decisions. Ask any partner for the named roles, the hours expected from each role, the documents to be produced and the reviews the organization must sign off. Those answers show what your own staff must do and what can be prepared externally.

Can an implementation partner handle EU AI Act readiness alone?

No. The organization owns its controls, its risk classification and the decisions to accept residual risk, and it must sign those off internally. An implementation partner can prepare systems, documentation, testing evidence and the mapping to Article 17 and EN 18286. DeployOpen plans, implements and documents systems inside the client's own infrastructure, and it prepares controls and evidence for assessments. It does not issue audit reports, attestations or certificates. Only an independent assessment or certification body issues those. Ask any partner to state this split in the written scope before work begins.

How DeployOpen prepares AI governance evidence

DeployOpen works on the evidence side of ISO 42001 vs EU AI Act: it prepares self-hosted systems, controls and documentation inside your own infrastructure. DeployOpen does not issue audit reports, attestations or certificates, and it does not decide whether your AI systems meet the EU AI Act; your organization owns those decisions, and independent assessors make the formal determinations.

How we scope

Agree in writing which AI systems, providers and internal teams fall inside the engagement before work starts.
Confirm which AI Act obligations and ISO 42001 clauses the scope addresses, and which remain with your legal and compliance teams.
Engagements are fixed-scope, so deliverables and timelines are set out in writing before any build begins.

How we build

Configure self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks to keep governance records.
Prepare documented processes that map to Article 17 quality management system aspects where your scope requires them.
Test AI systems and their supporting applications and APIs, then record findings and remediation for your assessor to review.

How we hand over

Deliver the documentation, configurations and evidence logs in a form your internal owners and external assessor can review.
Document who owns each control, so accountability stays with your organization after the engagement ends.
Confirm with your assessor and legal counsel which items they will accept as evidence before the handover is finalized.

How we support

Provide ongoing support, upgrades and continuous testing through a retainer when your AI systems or obligations change.
Update evidence and documentation as harmonised standards and the Commission's guidance on the EU AI Act develop.
Ask your certification body or legal adviser to confirm how any retained support affects independence from the assessment.

ISO 42001 vs EU AI Act