Is ISO 42001 mandatory? The short answer for buyers facing a requirement
A customer questionnaire, a contract clause or a regulator's letter now points to ISO/IEC 42001, and the first question is whether you have to comply. ISO/IEC 42001:2023 is a voluntary, certifiable management system standard, and none of the sources supplied for this page make it a legal requirement on its own. The standard specifies requirements for establishing, implementing, maintaining and continually improving an AI management system, and it applies to any organization, regardless of size, type or nature, that provides or uses products or services that use AI systems.
The real answer depends on three things: the wording of the contract or request, the sector you operate in, and whether you provide AI systems, use them, or both. A customer may ask for certification, for evidence of an AI management system, or only for a description of your AI governance. Read the clause literally. Ask the requester whether they need a certificate issued by an accredited certification body, a self-declaration, or answers to specific questions. Those are different obligations with different costs, and a regulator's reference to the standard does not automatically turn it into a mandate.
Remember that ISO does not certify organizations. External certification bodies do, and their accreditation is voluntary, so a certificate's value depends on who issued it. Before committing budget, confirm the scope the customer expects, the certification body they will accept, and whether they will accept a certificate covering only part of your AI activity. Those answers determine whether certification is the right route or whether a documented, evidenced management system is enough.
Who ends up needing ISO 42001 in practice
Organizations whose core product is an AI system, or a model or service built around one, usually meet ISO/IEC 42001 first through buyers. Enterprise customers ask vendors to show how they govern model development, data sourcing, testing and monitoring, and a certificate from an independent certification body is one way to answer those questions with evidence rather than a narrative. The standard applies to any organization that provides products or services that use AI systems, so a provider falls squarely within its scope.
- Customer security reviews: Enterprise questionnaires often ask about AI governance, model documentation and incident handling before a contract is signed.
- Tender requirements: Some large buyers list an AI management system certificate as a qualification criterion, so confirm the wording in each tender.
- Model lifecycle evidence: Auditors expect records of design, verification, validation and change control for each AI system in scope.
- Supplier chains: Providers that rely on third-party models or data are asked to show how those dependencies are governed.
- Competitive positioning: Certification can shorten security reviews, but it does not replace product-level testing.
Before committing, ask the customers or the procurement team which exact clause or certificate type they require, and whether an attestation of conformance would be accepted instead.
A SaaS vendor that adds an AI assistant, a recommendation engine or automated decisions to an existing product is still in scope, even if AI is a feature rather than the product. The pressure often arrives through the existing customer base: renewal questionnaires, data processing addenda and security addenda start asking how AI features use customer data and whether outputs are controlled. Because the vendor already holds an information security certificate in many cases, the question becomes how the AI management system sits alongside it.
- Renewal and addendum questions: Customers ask whether customer data trains models, where it is processed and how outputs are checked.
- Scope creep: The AI management system covers the AI features, not the whole product, so the boundary must be drawn in writing.
- Shared controls: Policies, risk registers and internal audit can often be reused from an existing management system.
- Third-party AI services: Features built on external model APIs still require documented responsibilities and supplier oversight.
- Timing: Feature launches frequently precede governance work, which is where gaps appear.
Check which AI features are in production, which customer contracts reference AI, and whether your existing ISO 27001 scope already covers those systems.
Many organizations do not build AI at all. They use AI tools for recruitment screening, customer service, document review, code assistance or analytics. ISO/IEC 42001 applies to organizations that use AI systems as well as those that provide them, so these organizations can be in scope. The practical question is usually internal: which AI tools are in use, who approved them, what data goes into them, and who is accountable when an output causes harm. Customers and regulators may ask the same questions even when the organization is only a deployer.
- Shadow AI inventory: The first step is an accurate list of AI systems in use, including tools bought by individual teams.
- Accountability: Defined roles for approving, monitoring and retiring each tool are the kind of evidence auditors ask for.
- Data flows: Records should show what personal or confidential data reaches each AI tool.
- Vendor terms: Contracts with AI providers need review for data use, retention and audit rights.
- Use within purpose: Usage should stay inside the intended purpose documented for each system.
Before scoping, ask whether the organization is a provider, a deployer or both for each AI system, because the obligations differ.
Public sector agencies, healthcare providers, banks, insurers and other regulated buyers often set AI governance expectations for their suppliers and sometimes for themselves. ISO's FAQ says the standard is designed for organizations of any size in all industries, including public sector agencies, companies and non-profits, and applies across AI applications and contexts. For these buyers, certification is usually a procurement and supervisory signal rather than a legal requirement, and sector regulators may point to it when describing good practice.
- Supplier onboarding: Buyers may require evidence of AI governance before onboarding a vendor that processes sensitive data.
- Sector guidance: Supervisors can reference recognized management system standards in their expectations, so confirm the current guidance for your sector.
- High-impact uses: Systems that affect benefits, credit, care or employment draw closer scrutiny and need documented impact assessment.
- Public procurement rules: Tender criteria vary by jurisdiction, so check the procurement documents.
- Oversight records: Buyers often want to see who approves high-impact AI and how decisions are reviewed.
Ask the buyer whether the requirement is contractual, a tender criterion or a regulatory expectation, since each leads to a different plan.
Why ISO 42001 does not by itself meet the EU AI Act quality management system
An ISO/IEC 42001 certificate does not, by itself, establish conformity with the EU AI Act. The European Commission's standardisation FAQ says ISO/IEC 42001:2023 helps an organization set up an AI management system, but its objectives and definitions do not match the quality management system that Article 17 of the AI Act requires of providers of high-risk AI systems. The Commission therefore requested a separate standard for that purpose. Providers of high-risk systems should read Article 17 themselves and map its thirteen aspects, including the compliance strategy, data management, the Article 9 risk management system and post-market monitoring, against their existing documentation before assuming any overlap with an ISO certificate.
CEN and CENELEC approved EN 18286 in June 2026, and Commission Implementing Decision (EU) 2026/2274 cited EN 18286:2026 in the Official Journal on 14 October 2026 as the first harmonised standard under the AI Act. Ask your legal or compliance lead to confirm the current status of that citation and the scope of EN 18286 for your system type before planning the quality management system. Do not treat ISO/IEC 42001 as a stand-in for that harmonised standard. Any claim that ISO/IEC 42001 gives presumption of conformity with the AI Act is not supported by the Commission's position.
The organization still owns its compliance. A certification body audits the management system against ISO/IEC 42001, and it does not test whether a specific high-risk system meets the AI Act's obligations. Decide internally who is accountable for the AI Act file, which evidence supports each Article 17 aspect, and how the ISO management system records feed into that file. Plan for the gap between the two frameworks as an explicit workstream, not as a side effect of certification.
Where ISO 42001 helps with AI Act and NIST AI RMF expectations
ISO/IEC 42001 gives an organization a certifiable management system, and several of the governance, impact assessment, life cycle and supplier records that regulators and customers ask about can be produced from it. It does not replace the EU AI Act quality management system or the NIST AI RMF, so each card below marks where the overlap stops and what to confirm before relying on it.
Governance and AI policy records
Clauses 4 to 10 and the A.2 and A.3 controls require a documented AI policy, defined roles and a route for raising concerns about AI systems. Regulators and customer questionnaires often ask who owns AI risk and where that ownership is written down. A named accountable owner with a reviewed policy is the record most reviewers ask for first. Confirm which governance duties your specific AI Act obligations assign to you as a provider or deployer.
Impact assessment process
The A.5 controls cover an AI system impact assessment process, its documentation, and a separate look at impacts on individuals, groups and society. This overlaps with the fundamental rights impact assessment the AI Act sets for certain deployers, but the two are not the same assessment. Check the scope and content requirements of the AI Act article that applies to your system before treating an ISO impact record as sufficient.
Life cycle and technical documentation
The A.6 controls ask for design records, verification and validation, deployment and operation records, technical documentation and event logs. These map closely to the kind of evidence a provider must keep for a high-risk system, yet the AI Act quality management system in Article 17 covers more aspects, including compliance strategy and post-market monitoring. Treat A.6 evidence as one input and confirm each Article 17 aspect separately.
Data governance for AI systems
The A.7 controls cover data management processes, acquisition, data quality, provenance and data preparation. Customers and auditors often ask where training and evaluation data came from and how its quality was checked. Records of provenance and quality checks are the evidence to collect, and they must match what the system actually used, not what the design intended.
Supplier and customer evidence
The A.10 controls allocate life cycle responsibilities across organizational boundaries and cover managing suppliers of AI products and services. When you buy a model or AI service, your customers and regulators may still ask what your supplier provided. Collect supplier responsibilities in writing and confirm them against any contract or model documentation you hold.
NIST AI RMF is voluntary
NIST AI RMF 1.0, released on 26 January 2023, is intended for voluntary use and has no certification. As of October 2026, NIST's page says AI RMF 1.0 is being revised as part of the White House AI Action Plan, so confirm the current version before citing it. NIST hosts a crosswalk to ISO/IEC FDIS 42001 that can show where the two overlap. Confirm each mapping in that crosswalk yourself rather than relying on this page.
How customer questionnaires and procurement turn a request into a certification need
A questionnaire line or contract clause about ISO 42001 rarely asks for a certificate outright, and the difference matters before any money is spent. Buyers usually mean one of three things: evidence that an AI management system exists and is operated, a third-party certificate that proves it, or a self-assessment the supplier completes and signs. Each one leads to a different project, budget and timeline. Ask the buyer which of these they mean, and get the answer in writing with the exact clause, questionnaire item or reference number. Many requests that read as "are you ISO 42001 certified?" are satisfied by a documented AI policy, a current statement of applicability and a summary of recent internal audit results.
The Cloud Security Alliance gives the clearest external example of the three paths. Its STAR for AI program starts with Level 1, an AI-CAIQ self-assessment, which the supplier completes against the questionnaire. Since 20 November 2025, a validated AI-CAIQ combined with ISO/IEC 42001 certification reaches STAR for AI Level 2. A buyer who asks for "STAR for AI" may therefore accept a self-assessment or may require the certificate underneath it, and the answer changes the scope of work. Confirm the level and whether the buyer will accept a validated submission, using the program's published STAR certification and attestation levels as the reference point.
Procurement teams also need to know whether a certificate is the only acceptable proof. Ask whether the buyer accepts certification from an accredited body, an unaccredited body, or an internal assessment, and which scope of AI systems the proof must cover. A product that uses one third-party model may be out of scope for a narrower management system than the supplier expects. Record the agreed evidence list in the contract or questionnaire response before scoping work begins, so that a readiness project is not commissioned for a deliverable the buyer would have accepted as a summary.
Who owns what when a certificate is requested
A certificate request involves four parties with different jobs. The organization decides and owns its AI governance, an implementation partner prepares systems and evidence, an accredited or recognized certification body audits and issues the certificate, and the buyer decides which evidence it accepts. Keeping these roles separate is what makes the result credible to a customer or regulator.
The organization owns its AI controls
The organization sets its AI policy, decides which Annex A controls apply, accepts the risk of its AI systems and makes the operating decisions behind them. ISO/IEC 42001 requires this accountability to sit inside the organization, and a statement of applicability must justify each inclusion and exclusion. No partner or auditor can take these decisions over. Before any request, confirm named owners for policy, risk and AI system decisions.
The partner prepares systems and evidence
An implementation partner such as DeployOpen can plan the management system, configure the self-hosted platforms that produce logs and records, and assemble the documents an assessor will request. This work is contracted in a written, fixed scope. The partner prepares the evidence but does not decide the controls, does not audit them and cannot guarantee the certification outcome.
The certification body audits and certifies
Only an independent certification body issues an ISO/IEC 42001 certificate. ISO does not certify organizations, and accreditation of those bodies is voluntary. The body reviews the management system in a stage 1 and stage 2 audit and then runs surveillance audits. Its auditors must not design the controls they assess, so the partner and the auditor should never be the same team.
The buyer decides what evidence it accepts
A customer, regulator or procurement team decides whether a certificate, an attestation or a self-assessment answers its question. Before relying on a certificate, the buyer should confirm the scope, whether the certificate is accredited, and whether the certification body is recognized in its market. Asking for the statement of applicability and the scope statement reveals more than the certificate alone.
Who signs what in practice
The certification body signs the audit report and certificate, the organization signs its policies and risk acceptances, and the partner signs only its own deliverables and statements of work. Mixing these signatures is a common source of confusion in questionnaires. A useful check is to ask each party to name the document it produced and the person accountable for it.
What to confirm before committing budget
This sequence establishes what the buyer actually requires, what role your organization plays under the EU AI Act, and what scope is justified before any certification body is contacted or any quote is requested. Each step produces a written record that the budget decision can rest on.
Obtain the exact requirement wording
Collect the precise clause, contract language, tender requirement or questionnaire item that mentions ISO/IEC 42001, and record who wrote it and where it sits in the agreement. Your legal or contracts team usually owns this step, with the account owner who received the request. The output is a saved copy of the wording, with the date received, that the rest of the sequence refers back to. Many requests mention ISO 42001 loosely, so the exact text decides what you must prove.
Ask whether a certificate is required
Put the question to the requesting customer, regulator or procurement contact in writing: do you need an accredited third-party certificate, a self-assessment, or evidence that your AI governance meets specific controls? Ask which certification body or accreditation they accept, if any. The output is a written answer that distinguishes certification, self-assessment and evidence delivery. If the buyer accepts a self-assessment or a documented gap analysis, a certification project may not be needed at all.
Confirm the requirement is contractual or legal
Establish whether the obligation comes from a contract, a procurement rule, a sector regulator or a statute. Only a legal requirement binds your organization regardless of commercial terms, and ISO/IEC 42001 itself is a voluntary standard. Legal counsel or the compliance lead should review the source and record the conclusion. The output is a short memo stating the source of the obligation and whether any regulator names ISO/IEC 42001 directly.
Determine the EU AI Act role and risk category
With counsel, identify whether any AI system you build or use falls under the EU AI Act, and whether it is considered high-risk under that regulation. Classification depends on the intended purpose and the use context, so product, legal and the system owner should agree on it together. The output is a system inventory with a risk category for each system and a note on the applicable articles. Where the Act applies, the Article 17 quality management system obligation for high-risk providers is a separate question from ISO/IEC 42001 certification.
Establish provider, deployer or both
For each AI system in the inventory, record whether your organization develops and places it on the market or puts it into service under its own name (provider), uses a system built by someone else (deployer), or does both. The role determines which obligations apply and which evidence a customer or regulator will expect. The output is a role assignment per system, reviewed by the compliance lead and signed off by the accountable executive.
Map existing controls to the requirement
Compare the requirement wording and the role assignments against the AI governance, risk, data and documentation controls you already operate, including any ISO/IEC 27001 controls. Mark what is evidenced, what is partly evidenced and what is missing. The output is a short gap list that names the owner of each gap. This step often shows that the required evidence exists but is scattered across teams, which affects scope and effort more than any new control design.
Scope certification only after the decisions
Once the requirement, role and gap list are documented, define the scope of an AI management system that covers the systems and business units the requirement actually reaches. Then request written quotes from certification bodies and, if you use one, an implementation partner, against that scope. The output is a signed scope statement and a set of quotes that can be compared line by line. Ask each provider to state which items are included, what is excluded and which parts remain your responsibility.
What happens if you certify too early or wait too long
Certifying too early usually means certifying the wrong scope. An ISO/IEC 42001 certificate covers the AI management system the organization defined, not every AI feature it ships. If the scope was drawn around a pilot team or a single internal tool, while a customer's procurement questionnaire or a regulator's inquiry is about a production model embedded in your product, the certificate will not answer their question. The organization owns the controls and decides which AI systems fall inside the boundary. Before the audit, check the statement of applectability required by clause 6.1.3 against the AI systems your customers actually name, and confirm that each Annex A control you excluded has a written justification that holds up when a buyer pushes back.
Waiting too long creates the opposite problem: a deadline with no evidence plan. Certification is only as fast as the records behind it. Auditors look for an AI policy, assigned roles, impact assessments, resource records and operating logs that show the controls ran over time, and building those from nothing under a contract deadline tends to produce documents that describe intent rather than practice. Ask each control owner now which records they already keep, which are missing, and who in your organization will produce them. Confirm with your certification body how it schedules the stage 1 and stage 2 audits and what lead time it needs, because that schedule, not the contract date, sets the realistic start point.
Both failure modes come back to who owns the work. An implementation partner can help map systems to controls and organize evidence, but the organization must still decide the scope, accept the residual risk and run the controls after the audit. A useful check before committing is to ask whether the named internal owner for AI governance can explain the scope and the exclusions in the statement of applicability without consulting the consultant. If that answer is no, the timing problem is an ownership problem, and it should be solved before any certification body is engaged.
Common questions about whether ISO 42001 is required
Is ISO 42001 required by any law?
No law in the supplied sources requires ISO/IEC 42001 certification. The standard is voluntary, and ISO describes it as applying to any organization, of any size or sector, that provides or uses products or services that use AI systems. A requirement usually arrives through a contract, a customer questionnaire or a procurement rule rather than a statute. Ask your counsel to confirm whether any sector regulator or contract in your market names ISO/IEC 42001 specifically, because a reference in a contract can make certification a practical obligation even though no law demands it. Read the clause wording before assuming a certificate is the only acceptable form of proof.
Does ISO 42001 certification satisfy the EU AI Act?
No. ISO/IEC 42001 helps you set up an AI management system, but the European Commission says its objectives and definitions do not match the quality management system required by Article 17 of the EU AI Act. The Commission therefore requested a separate standard, prEN 18286, which CEN and CENELEC approved as EN 18286 in June 2026. The Commission cited EN 18286:2026 in the Official Journal on 14 October 2026 under Implementing Decision (EU) 2026/2274. A certificate for ISO/IEC 42001 can support parts of your AI Act work, but providers of high-risk systems should confirm the Article 17 scope with counsel and their notified body or assessor.
Can we answer a customer with evidence instead of a certificate?
Often yes, if the customer accepts it. Certification is one way to show an AI management system exists and operates, but the standard itself is a set of requirements that you can evidence directly. Prepare a statement of applicability that lists the Annex A controls you include or exclude and why, your AI policy, impact assessments, supplier records and internal audit results. Clause 6.1.3 requires the statement of applicability, so it is a natural first document to share. Confirm with the buyer which evidence format they accept, since some procurement teams insist on an accredited certificate and others will review documentation during due diligence.
Do we need a consultant or can we do it ourselves?
You can do it yourselves if you have the internal capacity to own the AI management system. The organization owns its controls and must be able to explain them, so the decision is about skills and time rather than legal permission. Outside help can prepare systems, documentation and evidence, but it cannot issue a certificate. Only an accredited certification body or independent auditor issues one, and that body should be independent of your advisers. Ask any partner to state in writing what they will deliver, what stays with your staff and how they will avoid conflicts with the certifier you choose.
How does the question change for a company that only uses AI?
The standard still applies, because ISO/IEC 42001 covers organizations that use AI systems as well as those that build or provide them. A company that only consumes third-party AI tools typically has fewer life cycle controls to meet, but still needs an AI policy, defined roles, resource records, supplier management and rules for responsible use. Annex A controls on use and third parties become more important. Decide early which controls apply to your role, record the exclusions with reasons in the statement of applicability, and ask counsel whether any use case falls under the EU AI Act deployer obligations.
Where does ISO 42001 help with NIST AI RMF expectations?
ISO/IEC 42001 and the NIST AI Risk Management Framework 1.0 cover overlapping ground, and NIST has published a crosswalk between them. NIST released AI RMF 1.0 on 26 January 2023 as a voluntary framework with no certification, and NIST's page says it is being revised as part of the White House AI Action Plan. Use the crosswalk to map your existing ISO evidence to the NIST functions, and check the current NIST page before you rely on a specific version. A customer that asks about NIST alignment can often be answered with the same governance records, but confirm the exact expectation in the buyer's questionnaire.
What should we confirm before committing to certification?
Confirm three things first: who requires the certificate, in what words, and by when. Ask the buyer whether an accredited certificate is mandatory or whether a documented management system and evidence would be enough. Check with counsel whether any EU AI Act obligation applies to your products, and whether the Article 17 quality management system is in scope. Finally, check the accreditation status of any certification body with the national accreditation body or IAF CertSearch, because accreditation is voluntary and unaccredited certificates may not satisfy every buyer.
How DeployOpen helps you answer the requirement
DeployOpen works on the platforms and evidence behind an ISO/IEC 42001 management system, not on the decision of whether your organization needs it. We help you set up the systems, records and controls that an independent certification body would later assess, and we leave the certification decision to that body.
How we scope
- We agree a written scope covering which AI systems, teams and infrastructure fall inside the management system.
- Scope, deliverables and timelines are fixed in writing before any implementation work starts.
- Scoping starts from your customer, contract or regulator requirements so the work targets the evidence they actually ask for.
How we build
- We implement and harden self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks.
- We configure logging, access records and documentation tooling so AI governance evidence is produced as systems run.
- We test applications, APIs and AI systems and agents, and record findings that feed your impact and risk assessments.
How we hand over
- We document the systems, configurations and control evidence in a form your internal owners and auditors can review.
- We prepare the evidence pack for your statement of applicability, and your organization decides which controls apply.
- Confirm with your certification body or customer which evidence format they accept before we finalize deliverables.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement ends.
- Retainers can keep evidence current between surveillance or customer review cycles, as your systems change.
- Ask your advisers to confirm which decisions stay with your AI governance owner and which sit with the independent auditor.
