Search interest in "ISO 42001" nearly doubled in India between January and August 2026, climbing from around 1,600 monthly searches to close to 2,900, according to SE Ranking's keyword data. Actual certifications have not kept pace with that curiosity. Public estimates gathered from certification bodies and company announcements put the worldwide count of ISO/IEC 42001 certificate holders at roughly 350 organizations by mid-2026. More than a million organizations hold ISO 9001, for comparison. People are searching for this standard faster than companies are getting certified against it.
That gap makes sense once you know the timeline. ISO/IEC 42001 was published in December 2023, the first certification cycles only wrapped in 2024, and Boston Consulting Group, announcing its own certification in January 2026, said it was among the first 100 organizations worldwide to receive it. Early movers have skewed toward technology, cloud, and professional services firms, the kind of companies that saw AI governance turning into a procurement requirement before most of the market caught on.
ISO/IEC 42001 is the first international standard for an AI management system, an AIMS. It gives an organization a structured, auditable way to govern how it designs, buys, deploys, and operates AI, instead of managing AI risk through scattered policies and good intentions that nobody revisits after the launch meeting. Anyone who has been through an ISO 27001 certification will recognize the shape immediately: the same Annex SL clause structure, the same Plan-Do-Check-Act cycle, an AI-specific set of controls bolted on through Annex A.
Here is the step that trips up a surprising number of early attempts at this. An AIMS cannot be scoped correctly until an organization has honestly worked out what it is, in ISO's own terms, in relation to the AI systems it touches. ISO/IEC 22989, the terminology standard ISO/IEC 42001 builds on, sorts this through AI roles, and three of them matter most when scoping an AIMS: the AI Producer or Developer, the AI Provider, and the AI User or Customer. Skip that step, or assume the answer is obvious, and the risk assessment, the Annex A controls selected, and the evidence collected downstream all get built for the wrong shape of organization. Fixing that later costs far more than getting it right at the start.
This guide covers what ISO/IEC 42001 requires, how its ten clauses and Annex A controls fit together, what the three AI roles mean and why sorting them out comes first, how the standard lines up against regulation like the EU AI Act, what skipping this work costs, and a readiness playbook toward certification. It is written for GRC leads, AI product owners, and the executives who will eventually have to sign the Statement of Applicability.
What ISO/IEC 42001 Actually Requires
ISO/IEC 42001:2023 sets requirements for establishing, implementing, maintaining, and continually improving an AI management system. It follows the Annex SL structure shared across modern ISO management-system standards: clause 4 covers organizational context, clause 5 leadership, clause 6 planning, clause 7 support, clause 8 operation, clause 9 performance evaluation, and clause 10 improvement. Annex A supplies a reference set of 38 controls under nine control objectives, AI policy, internal organization, resources, AI system impact assessment, the AI system life cycle, data for AI systems, information for interested parties, responsible use of AI systems, and third-party relationships. Annex B walks through implementation guidance for each control. Annex D covers integrating an AIMS with other management systems an organization might already run, ISO/IEC 27001 for information security and ISO/IEC 27701 for privacy being the two most common pairings.
Worth being precise about what certification does and does not mean, since this gets mixed up a lot. ISO does not issue certificates itself. Accredited certification bodies do, following a Stage 1 documentation review and a Stage 2 implementation audit, and the resulting certificate holds for three years subject to annual surveillance audits. The certificate covers the management system. Not a specific AI model, not a specific product. A certified organization has shown it governs AI systematically, a different claim from saying any one model it runs has been independently verified as safe, and conflating the two is a mistake worth avoiding in any marketing built around the certificate.
The Ten Clauses at a Glance
| Clause | Focus | What it requires in practice |
|---|---|---|
| 4. Context | Scope and interested parties | Work out which AI role or roles the organization holds and set the AIMS boundary around that |
| 5. Leadership | Policy and accountability | Top management commitment, a documented AI policy, assigned roles and responsibilities |
| 6. Planning | Risk and objectives | AI risk assessment, AI system impact assessments, measurable AI governance objectives |
| 7. Support | Resources and competence | Staff competence, awareness, the documented information the AIMS runs on |
| 8. Operation | Running the controls | Operational planning and control, with impact assessments done as systems go live, not after |
| 9. Performance evaluation | Monitoring and audit | Internal audit, management review, ongoing monitoring and measurement |
| 10. Improvement | Correcting course | Nonconformity handling, continual improvement of the AIMS itself |
The Three AI Roles ISO/IEC 42001 Wants Sorted Out First
Clause 4.3 requires the AIMS scope to reflect every role an organization actually holds, and holding more than one at once is common, not an edge case. ISO/IEC 22989 sets out several stakeholder roles across the wider AI ecosystem, but three of them carry most of the weight for an organization scoping an AIMS for the first time.
| AI role | What it means | Where its obligations concentrate |
|---|---|---|
| AI Producer / Developer | Designs, builds, tests, and deploys the AI system itself, owning the model or algorithm across its lifecycle | AI system life cycle controls: documented design and development process, defined system requirements, verification and validation before release |
| AI Provider | Makes an AI system, platform, or service available to other organizations, whether built in-house or sourced elsewhere | AI policy and third-party-facing obligations: information for interested parties, contractual terms, responsible-use commitments made to whoever the system goes to |
| AI User / Customer | Acquires and runs an AI system or service supplied by a provider, inside its own operations | Operational obligations: an AI system impact assessment for its own use case, production monitoring, human oversight of outcomes |
The same organization often occupies more than one of these roles at once. Take a bank that licenses a vendor's fraud-detection model. It is a User with respect to that system. The moment it turns around and exposes an AI-driven decision, a credit-score explanation, a personalized offer, back to its own retail customers as a feature of its own product, it becomes a Provider too. Both sets of obligations apply at the same time, and the AIMS needs a scope wide enough to cover both, not just whichever role feels closer to the core business.
Why Sorting Out the Role Comes Before Anything Else
Getting this wrong, or treating it as a box-ticking formality, is one of the more common reasons an early AIMS effort stalls out. The risk assessment an organization runs, the Annex A controls it picks, and the evidence it has to produce all hinge on which role, or roles, actually apply.
A pure AI User does not need the full AI system life cycle documentation a Producer has to keep, the design rationale, the training-data lineage, the verification and validation records, because it never built the system in the first place. What it does need is solid evidence on the operational side: a documented impact assessment for how it is using the vendor's system, monitoring that catches drift or unexpected outcomes once the system is live, and clear human oversight over decisions the system influences. A Producer building its own models sits at the opposite end, heavier on life cycle and data documentation, lighter on some of the third-party contractual controls a pure Provider needs. Scope the AIMS around the wrong role and the resulting audit trail answers questions nobody was going to ask, while missing the ones that matter.
Where ISO/IEC 42001 Meets Regulation
ISO/IEC 42001 is voluntary. It is not a law, and holding the certificate does not automatically satisfy a legal obligation anywhere. What it does do well is give an organization a structured way to produce the kind of evidence several current regulations are starting to expect anyway.
The EU AI Act's Article 15 requirement that high-risk systems demonstrate accuracy, robustness, and resilience against adversarial manipulation lines up closely with the risk assessment and AI system impact assessment work clause 6 and Annex A already call for. India's DPDP Act adds a different but related layer: its Section 8(5) duty to implement reasonable security safeguards covers any personal data an AI system touches, and a working AIMS is one of the more concrete ways to show that duty was met rather than claimed after something goes wrong. Neither regulation gets satisfied by a certificate on its own. Think of ISO/IEC 42001 as a scaffold that makes meeting them a lot more tractable, not a substitute for reading what each one specifically demands.
What Skipping This Actually Costs
There's no fine schedule attached to not having an AIMS the way there is for a DPDP or EU AI Act breach. The costs are still real, and increasingly commercial rather than purely reputational.
| Gap | Consequence |
|---|---|
| No AI governance policy at all | IBM's 2025 Cost of a Data Breach Report found organizations with high levels of shadow AI faced roughly $670,000 in additional average breach cost, and 63% of the organizations studied had no AI governance policy in place |
| No documented access controls around AI tools | Among organizations that suffered an AI-related breach in the same IBM study, 97% said they lacked proper access controls |
| No AIMS to point to during vendor due diligence | ISO 42001 certification is increasingly showing up as a procurement requirement in financial services and healthcare, and not having it can knock a vendor out of a shortlist before pricing is even on the table |
| Duplicated governance work across standards | Skipping Annex D's integration guidance means AI governance, information security, and privacy programmes run as three separate efforts instead of sharing evidence and audit cycles |
| Copying another organization's Statement of Applicability | An SoA that does not reflect the organization's own risk profile and AI roles will not hold up under a Stage 2 auditor's questions |
A Maturity Model for AI Governance Under ISO/IEC 42001
Most organizations land somewhere on a five-level path between no governance at all and a fully operating AIMS.
Level 1: No AI inventory, no assigned AI role, tools adopted ad hoc across teams ↓ Level 2: An inventory exists and a policy has been written, but no AI role has been assigned per system ↓ Level 3: Scope is defined under Clause 4.3, an AI role is assigned to each system, and an initial risk assessment has been run ↓ Level 4: The applicable Annex A control set is implemented, documented in a Statement of Applicability, and has passed Stage 1 and Stage 2 audits ↓ Level 5: Internal audit and management review run continuously, and the same evidence base gets cross-mapped to EU AI Act and DPDP obligations instead of being maintained twice
Most of the friction described in this guide sits at the jump from Level 2 to Level 3: assigning a role to every system, rather than governing AI in the abstract at the organizational level.
A Readiness Playbook Toward Certification
- Inventory every AI system in use or under development, sanctioned and shadow alike. A scope defined before this step is a scope built on an incomplete picture.
- Work out the AI role, or roles, held for each system under Clause 4.3. Producer, Provider, and User obligations differ enough that this needs doing system by system, not once for the whole organization.
- Define the AIMS scope and get leadership sign-off on a documented AI policy, which satisfies Clause 5 before moving on.
- Run the AI risk assessment and the AI system impact assessments Clause 6 calls for, scoped to the roles identified in step 2.
- Pick the applicable Annex A controls and write the Statement of Applicability, with a real justification for anything excluded rather than assuming everything applies equally.
- Build competence and documented evidence into normal operation, under Clauses 7 and 8, instead of reconstructing it retroactively right before an audit.
- Run an internal audit and a management review under Clause 9 before booking anything external, so gaps get caught while they are still cheap to fix.
- Book Stage 1 and Stage 2 audits with an accredited certification body, checking first that the body's accreditation specifically covers ISO/IEC 42001.
Common Mistakes and Edge Cases
Treating ISO/IEC 42001 as a one-time documentation project. The Plan-Do-Check-Act structure assumes continual operation, not a policy binder produced once for an audit and left to gather dust afterward.
Assigning a role once and never revisiting it. A new AI system added six months after certification needs its own role determination. The organization's overall role does not automatically extend to every new system it picks up.
Copying another organization's Statement of Applicability. An SoA is supposed to reflect a specific risk profile and role set. Reusing someone else's wholesale is a fast way to fail a Stage 2 audit.
Assuming ISO 27001 certification already covers this. Annex D makes integrating the two systems a lot easier, but it does not substitute AI-specific controls for information-security ones. They address different risks.
Skipping impact assessments for "low risk" internal tools. An internal tool built for a narrow use case can scale into something with much broader exposure within a year, and an AIMS that only assessed it at that small, early stage misses the shift entirely.
Confusing management-system certification with product certification. ISO/IEC 42001 certifies how an organization governs AI, not that a specific model has been independently verified as safe or unbiased.
When to Use What: A Few Decision Points
Build the AIMS in-house versus bring in outside support. An organization already running a mature ISO 27001 or broader GRC programme can often extend that structure on its own. One starting AI governance from a standing start typically moves faster with outside help getting the initial scope, role determination, and risk assessment right the first time.
Certify now versus wait. Procurement pressure from regulated buyers in financial services or healthcare, or direct exposure to the EU AI Act's high-risk obligations, both argue for moving now rather than waiting for the market to settle. An organization with limited AI exposure and no near-term regulatory or procurement pressure might reasonably build the governance practice first and leave formal certification for later.
Single-role scope versus multi-role scope. An organization that only consumes vendor AI tools can scope its AIMS around the User role alone. One that also builds or resells AI capability needs a scope covering Producer or Provider obligations too, even if that adds real work to the certification effort.
A fully audit-ready Statement of Applicability versus a lighter internal governance framework. If external certification is the actual goal, the SoA needs to meet the standard a Stage 2 auditor will hold it to from day one. If the near-term goal is internal risk management rather than a certificate, a lighter governance framework built to the same structure can still deliver most of the risk reduction at a lower upfront cost.
How SecNinjaz Fits Into This
The pattern running through this guide, get the scope and the role right before building out the controls, is the same sequencing SecNinjaz's GRC and DPDP practice follows when helping an organization stand up an AIMS. That practice covers AI Governance, ISO Certification and Compliance, Risk Management, and Audit and Gap Assessment, with vCISO support for organizations that need senior security leadership guiding the process without a full-time hire.
SecNinjaz holds ISO/IEC 42001:2023 certification itself, alongside ISO/IEC 27001:2022 for information security and ISO/IEC 27701:2025 for privacy information management, the same Annex D-style integration described above, applied internally rather than only advised on from the outside. For organizations trying to work out which AI role they actually hold before the next audit, the next vendor security questionnaire, or the next EU AI Act obligation lands on their desk, that combination of certified practice and hands-on gap assessment is the pairing worth looking for, whether the organization works with SecNinjaz or anyone else.
Frequently Asked Questions
What is ISO/IEC 42001?
ISO/IEC 42001:2023 is the first international standard specifying requirements for an AI management system, an AIMS. Published in December 2023, it follows the same Annex SL clause structure as ISO 27001 and ISO 9001, with an AI-specific set of 38 controls across nine objectives in Annex A.
What are the three AI roles in ISO/IEC 42001?
Drawing on ISO/IEC 22989's terminology, the three roles most relevant to scoping an AIMS are the AI Producer or Developer, who designs and builds the AI system; the AI Provider, who makes an AI system or service available to other organizations; and the AI User or Customer, who acquires and operates an AI system supplied by a provider. An organization can hold more than one role at once, and Clause 4.3 requires the AIMS scope to reflect every role it actually holds.
Is ISO/IEC 42001 certification mandatory?
No. It is a voluntary, certifiable management-system standard, not a legal requirement. Regulations such as the EU AI Act still apply based on how an organization's AI systems are classified and used, regardless of whether it holds ISO/IEC 42001 certification, though the certification makes it a good deal easier to produce the evidence those regulations expect.
How long does ISO/IEC 42001 certification take and how long does it last?
Certification runs through a Stage 1 documentation review and a Stage 2 implementation audit, and organizations already certified to ISO 27001 can often move through it faster by extending existing management-system infrastructure. The certificate holds for three years, subject to annual surveillance audits, with a full recertification audit closing out the cycle.
Does ISO 27001 certification already cover AI governance?
Not on its own. ISO/IEC 42001's Annex D gives guidance for integrating an AIMS with an existing ISO/IEC 27001 information security management system, which cuts down duplicated audit and documentation work substantially, but the AI-specific controls in Annex A cover risks, AI system life cycle management and algorithmic impact among them, that an information security management system was never built to address.
What is a Statement of Applicability in ISO/IEC 42001?
A Statement of Applicability, or SoA, is the document where an organization records which of Annex A's 38 controls apply to its AIMS and justifies any it has excluded, based on its own risk assessment and the AI roles it holds. An SoA copied from another organization instead of built around a specific risk profile is a common reason an AIMS fails a Stage 2 audit.
Does ISO/IEC 42001 certify a specific AI model as safe?
No. Certification applies to the management system an organization uses to govern AI across its lifecycle, not to any individual AI model, product, or vendor. A certified organization has shown systematic governance of how it manages AI risk, not that a specific system has been independently verified as safe or free of bias.
Where should an organization start if it has no AI governance in place yet?
Start with a full inventory of every AI system in use or under development, including tools adopted without formal approval, then work out the AI role held for each one under Clause 4.3 before writing any policy. Scoping the AI management system around the wrong role, or around the organization as a whole rather than system by system, is the most common reason an early governance effort produces documentation that does not hold up under audit.
