ISO/IEC 42001:2023 is the international standard that specifies requirements for establishing, implementing, maintaining, and continually improving an artificial intelligence management system, usually shortened to AIMS. Published in December 2023, ISO describes it as the world’s first AI management system standard, and ISO/IEC 42006:2025 sets the additional requirements for bodies that audit and certify AI management systems against ISO/IEC 42001.
It uses the harmonized structure ISO applies across its management system standards, set out in Annex SL of the ISO/IEC Directives and shared with ISO/IEC 27001:2022, so the shape is familiar: context, leadership, planning, support, operation, performance evaluation, improvement. AI-specific requirements and guidance extend beyond Annex A, but Annex A contains 38 reference controls organized under nine control objectives, covering areas such as AI policies, internal organization, resources, impact assessments, data, interested parties, and third-party relationships.
Running through these requirements is a practical dependency that can undermine an implementation before it begins: maintaining an accurate inventory of the AI systems the organization develops, provides, or uses. Without that inventory, security leaders may reach the internal audit only to discover that the scope of their AIMS is incomplete.
Be precise about what certification means, because the market is already blurring it. Certification to ISO/IEC 42001 does not establish that an AI system is safe, fair, or accurate. It provides independent assurance that an organization’s AI management system conforms to the standard’s requirements. This means that decisions are made deliberately, risks are assessed against stated criteria, controls operate, and the whole system is continually improved
Clauses 4 through 10 carry the auditable requirements, and they describe a continuous process of understanding the context, providing leadership, planning, providing support, operating, evaluating performance, and improving. Annex A provides reference controls that organizations compare against the controls they determine are necessary. The resulting Statement of Applicability documents the necessary controls, their implementation status, the reasons for including them, and the justification for excluding any Annex A controls - the same type of instrument used in ISO/IEC 27001. What gets tested during an audit is whether the management system conforms to the standard and operates effectively - and whether the decisions made within it are backed by evidence.
The standard also frames roles in a note to Clause 4.1 that draws its terms from ISO/IEC 22989. These include AI providers, AI producers, AI customers including AI users, AI partners, and AI subjects. Which controls carry the most implementation weight depends on where the organization sits.
Organizations that primarily deploy third-party AI generally act as AI customers, which shifts the emphasis toward responsible use and third-party relationships and can make some development-oriented controls less applicable. Settle that question early, because it influences which Annex A controls may be justifiably excluded. Impact assessment, oversight, transparency, and allocation of responsibility usually remain relevant, because an organization’s accountability for how it deploys and uses an AI system does not disappear simply because a third party developed it.
Every inclusion and exclusion still has to be justified based on the organization’s control determination and risk-treatment process, then recorded in the Statement of Applicability.
ISO/IEC 42001 is a voluntary standard. Certification can still become a contractual or procurement requirement, but the standard itself is not a law. In practice, it can function as a procurement instrument. Enterprise buyers that have added AI questions to vendor security reviews now have a certificate to ask for, and asking for one is considerably easier than reading forty pages of policy documents.
For a CISO, that changes the business case. The question is rarely whether the standard is legally required. It is whether the next enterprise renewal, public-sector tender, or insurance questionnaire will ask for it, and how long the organization would need to become ready from a standing start.
Note: Certification is issued by an independent certification body, preferably one accredited by a recognized accreditation body, though accreditation is not compulsory. The audit assesses conformity with ISO/IEC 42001 within the declared scope, while the Statement of Applicability records which Annex A controls were selected or excluded and why. Two certified companies can therefore hold very different control sets, which is why sophisticated buyers ask for the scope statement rather than the certificate.
Ownership is worth settling at the same time. The management system itself usually sits with compliance, legal, or a quality function, because the clause structure is their native territory. Security often owns or supports the layer underneath, including the inventory, access and permission data, monitoring, and evidence that controls operated. The friction to expect is a compliance team assuming security will produce the classification, and a security team assuming compliance already knows what is deployed. Neither assumption is safe on day one, and the gap between them usually lands on the CISO.
This is where confident vendor messaging tends to outrun the facts. ISO/IEC 42001 is an international standard and has not been cited in the Official Journal of the European Union as a harmonized standard under the AI Act. An ISO/IEC 42001 certificate therefore does not itself create a presumption of conformity under the Act.
Two developments are worth separating from that. ISO/IEC 42001 has been adopted in Europe as EN ISO/IEC 42001:2026, but European adoption alone does not make it a harmonized standard. Separately, CEN and CENELEC made EN 18286:2026 available in July 2026. It is the first European standard developed specifically to support implementation of the AI Act, addressing the quality management system that Article 17 requires of providers of high-risk AI systems. Its reference has not yet been cited in the Official Journal. Until that citation occurs, applying the standard does not trigger the Article 40 presumption of conformity. An ISO/IEC 42001 certificate remains a credibility asset, not a legal shield.
The timeline is now settled law. Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published in the Official Journal on 24 July 2026 and entered into force on 27 July. It defers the principal high-risk obligations for stand-alone Annex III systems from August 2026 to 2 December 2027, and for high-risk AI embedded in Annex I regulated products to 2 August 2028. The relief is narrower than the headlines suggested. The general application date of 2 August 2026 did not move; the AI literacy duty remains although Article 4 was amended, and transparency obligations apply on a staggered basis with limited transitional arrangements.
The practical read for a security leader is that ISO/IEC 42001 will not discharge an AI Act obligation. Still, the evidence it requires organizations to produce, including an inventory, a risk assessment, impact records, life cycle controls, and defined supplier responsibilities, overlaps substantially with evidence required under the Act. Building a reusable evidence base is the efficient move. Treating the certificate as proof of compliance is not.
Clause 4.3 asks for a documented scope. On paper, this is administrative. In practice, it is often one of the hardest requirements in the standard, because a scope statement is a claim about reality, and reality here is unusually slippery.
An employee grants a writing assistant read-and-write access to a mailbox in the time it takes to skim a consent screen. A developer connects a code assistant to a repository. A sales team enables an AI note-taker that joins every call and keeps the transcripts. None of these may appear in a procurement system. All of them are AI systems processing organizational data, and each one needs to be assessed to determine whether it falls within the declared scope, sits outside it for a defensible reason, or should be removed under organizational policy.
That is why discovery has to precede scoping rather than follow it. The uncomfortable version of this exercise is the productive one. Run technical discovery across identity providers, third-party services, and the agents built on top of them, look at what comes back, and write the scope against what you find instead of what you assumed.
Navigate to AI Agent Security
A useful distinction emerges quickly. Some agents and third-party services interface directly with foundation models, sending prompts and data to a model provider. Others embed AI features without exposing direct model access, like assistive drafting inside a productivity suite. Direct model access and data sensitivity are useful risk indicators rather than scoping rules on their own. A scope can legitimately be bounded by business unit, geography, process, or service. What it cannot survive is an AI system or agent nobody ever assessed.
Warning: Clause 4.3 does not prescribe a discovery method, and no clause makes an unassessed AI system or agent automatically a nonconformity. The exposure is downstream. An organization that cannot show what AI sits inside its declared boundary will struggle to evidence the risk assessment in Clause 6.1.2 or the impact assessment in Clause 6.1.4 for those systems. In practice, this can become an early audit finding, and it is preventable.
The second thing implementations get wrong is treating evidence as a deliverable rather than a byproduct of an operating management system. Certification bodies assess whether the management system has been implemented and operates effectively over time. A control verified once, in the month before the Stage 2 audit, does not demonstrate that the control operates consistently. It only demonstrates that the control was observed then.
That reframes what you should be building. The grouping below is a practitioner view rather than a distinction the standard draws, since ISO/IEC 42001 specifies control objectives and not the tooling used to satisfy them. In practice, controls covering resources (A.4), AI system impact assessment (A.5), the AI system life cycle (A.6), data for AI systems (A.7), the use of AI systems (A.9), and third-party and customer relationships (A.10) are easier to evidence when you hold reliable factual records of which AI systems and agents exist, what permissions they hold, whose accounts they can access, what data those permissions reach, and when each was last active. Those facts are the substrate, not the whole control. The assessments, approvals, and decisions layered on top still have to be made by people and recorded. What technical evidence removes is the archaeology, not the judgment.
This is where a security platform belongs inside the program rather than beside it. Reco continuously inventories discovered agents, connected identities, authorization status, and permission context, and runs posture checks on a 24-hour cycle. That supplies the underlying facts needed to evidence controls across several Annex A control objectives, as a standing record rather than a fire drill. The management system records, impact assessments, review minutes, and Statement of Applicability remain yours to produce.
Action: Map each recurring export and technical record to the specific controls it supports, then archive every run. Dated output accumulated across the operating period beats any document written from memory the week before the audit.
Certification follows the standard two-stage pattern. Stage 1 reviews documentation and readiness. Stage 2 tests whether the system actually operates and conforms to the standard’s requirements. Certificates typically follow a three-year cycle with surveillance audits in between, so the system has to keep running rather than peak once.
The constraint most programs underestimate is operating history. Stage 2 evaluates implementation and effectiveness, so a system that only existed on paper the week before the audit produces nothing to sample. ISO/IEC 17021-1 sets no minimum operating period. Stage 1 evaluates whether internal audits and management reviews are being planned and performed, while Stage 2 requires evidence that the applicable management-system requirements have been implemented. Organizations should therefore complete an internal audit and management review before Stage 2 and retain the resulting records. Certification bodies often look for several months of operating evidence, although the required period varies by scope, complexity, and certification body. That makes the floor a matter of evidence accumulation rather than how fast your team can write policy.
Organizations with a mature ISO/IEC 27001 program may move faster, because the clause structure, the Statement of Applicability mechanism, the internal audit function, and much of the access and data control substrate already exist. The new work includes AI-specific risk and impact assessments, AI objectives, resource documentation, life cycle controls, and controls governing the responsible use of AI systems. The AI system impact assessment in Clause 6.1.4 and Annex A.5 is especially significant because it has no direct information security equivalent. Resource documentation and the third-party controls in A.10 can build on supplier processes an existing program already runs.
Three recurring patterns account for significant delay, and none of them can be solved by tooling alone.
Organizations that implement the standard effectively often treat ISO/IEC 42001 as an extension of a management system they already run, pointed at a class of technology that can enter the organization faster than established governance processes can track it. That is the real difficulty, and no amount of documentation solves it. Visibility does.
This article provides general information current as of August 2026, does not constitute legal or compliance advice, and paraphrases rather than quotes the standards it describes. Certification decisions rest with independent certification bodies, and readers should work from the purchased standard and consult their own advisers.
%201.svg)
Gal is the Cofounder & CPO of Reco. Gal is a former Lieutenant Colonel in the Israeli Prime Minister's Office. He is a tech enthusiast, with a background of Security Researcher and Hacker. Gal has led teams in multiple cybersecurity areas with an expertise in the human element.
%201.svg)
.svg)