ISO 42001, explained for security teams

An AI management system (AIMS) is a structured set of policies, procedures, roles, and records that allows an organisation to govern its AI systems in a consistent, auditable way. The “management system” framing is deliberate: an AIMS is not a tool, a platform, or a checklist. It is an organisational capability — one that produces documented evidence of the decisions made about AI systems, the risks assessed, and the controls applied.

Organisations implement an AIMS for several reasons. The most common are: preparing for ISO 42001 certification, meeting procurement requirements from enterprise customers or regulated sectors, responding to board or regulatory pressure to demonstrate AI governance maturity, and building the internal infrastructure to scale AI deployment without losing accountability.

The distinction matters for security teams. An AIMS implementation is primarily a governance project. The technical work — threat modelling, control design, evidence collection — feeds the AIMS. It is not a substitute for it. An organisation that has well-designed technical controls but no documented governance process does not have an AIMS; it has a good security programme that has not been organised into a certifiable system.

ISO 42001 applies to any organisation that develops, provides, or uses AI systems — which covers nearly every enterprise. The standard is sector-neutral: it is equally applicable to a financial services firm using AI for credit decisioning, a healthcare organisation using AI for clinical support, and a technology company developing AI products for customers.

The standard uses three distinct roles to describe how organisations relate to AI systems:

• AI provider. An organisation that develops and makes available an AI system for use by others. This includes model developers and platform vendors.
• AI operator. An organisation that deploys an AI system developed by a provider and uses it to deliver a product or service. Most enterprises using third-party AI fall in this category.
• AI subject. A person whose interests are affected by the outputs of an AI system — a customer, employee, or member of the public.

Most organisations adopting ISO 42001 are AI operators. The standard requires them to assess and document the AI systems in scope, define the governance processes applied to those systems, and maintain records of how those processes operate over time.

ISO 42001 follows the ISO High Level Structure (HLS), which means its clause numbering and general architecture will be familiar to anyone who has worked with ISO 27001 or ISO 9001. The management system obligations run from Clause 4 to Clause 10.

In addition to the core clauses, ISO 42001 includes Annex A, which defines specific AI controls across domains including AI policy, risk management, system lifecycle, human oversight, and transparency. Annex A is referenced in the Statement of Applicability — the document that records which controls apply and why.

The most substantive clauses for a security team are Clause 6 (planning, which contains the AI risk assessment requirement) and Clause 8 (operation, which covers the AI system lifecycle). These two clauses are where the technical work of an AI security review maps most directly to the management system.

ISO 42001 requires an organisation to:

• Define the scope of the AIMS — which AI systems are governed by it.
• Conduct a documented AI risk assessment for each system in scope, identifying risks across the system lifecycle.
• Produce and maintain risk treatment plans with named owners and timelines.
• Define roles and responsibilities for AI governance, with top management demonstrating commitment.
• Establish operational procedures for AI system development, deployment, and monitoring.
• Conduct periodic management reviews and internal audits of the AIMS.
• Maintain documented information sufficient to demonstrate that the management system is operating.

The standard specifies how to govern AI systems — not which systems to deploy, which models to use, or what level of performance is acceptable. Organisations that expect ISO 42001 to tell them which AI is safe will be disappointed; it tells them how to make and document that determination for themselves.

ISO 42001 does not require specific technical controls. It does not mandate a particular risk assessment methodology. It does not prescribe how many AI systems an organisation may operate, or what constitutes an acceptable residual risk level. These are left to the organisation to determine and document — and that documentation is what the auditor inspects.

Organisations can relate to ISO 42001 in two ways: they can claim conformance, or they can pursue third-party certification.

Conformance means the organisation has implemented a management system that meets the standard's requirements, but has not engaged an accredited certification body to verify it. Self-declaration of conformance is permissible under the standard. Many organisations adopt ISO 42001 as a governance framework without pursuing formal certification — particularly in the early stages of AIMS implementation.

Certification means an accredited third-party certification body (CB) has audited the AIMS and issued a certificate. The certificate covers the organisation, not the individual AI systems. A certificate does not mean that any particular AI system has been independently verified as safe or fit for purpose — it means the management system governing those systems has been found to meet the standard's requirements at the time of audit.

The choice between conformance and certification depends on commercial pressure and organisational maturity. Regulated sectors and large enterprise procurement increasingly expect certification. Organisations building toward certification typically find it useful to spend at least one full cycle operating the AIMS under conformance before inviting external audit.

The ISO 42001 risk assessment requirement (Clause 6.1.2) is satisfied by a documented process that identifies, analyses, and evaluates AI-specific risks for each system in scope. An AI security review — which produces a threat model, a list of identified control gaps, and a risk treatment record — maps directly to this requirement.

Specifically, an AI security review conducted for assessed systems produces evidence relevant to the following AIMS clauses:

• Clause 6.1.2. Risk identification: the threat model identifies attack paths, adversarial inputs, data quality risks, and integration boundary risks for the assessed system.
• Clause 6.1.3. Risk treatment: the control gap report identifies where controls are absent or insufficient, providing the basis for a treatment plan.
• Clause 8.4. AI system deployment: evidence that the system was reviewed before deployment supports the lifecycle gate record required by this clause.
• Annex A controls. The security review produces evidence for Annex A controls in the security domain — access control for the model API, output filtering, logging, and adversarial robustness.

The review does not replace the AIMS. It produces inputs to it. The organisation still needs the policy framework, the roles, the management review cadence, and the other management system components that the standard requires. But for organisations building an AIMS, an AI security review of each system in scope produces the most technically substantive evidence in the package.

For organisations approaching ISO 42001 for the first time, the most productive starting point is an inventory: what AI systems are in operation, who owns them, and what risk they carry. This inventory becomes the scope of the AIMS and the input list for the initial risk assessments.

The second step is a gap analysis against the seven management clauses. Most organisations have partial coverage — some policies exist, some roles are informally assigned, some risk assessments have been done in procurement or legal review. The gap analysis identifies where the management system is absent or informal, and what documentation needs to be created.

The ISO 42001 AI governance toolkit provides structured templates for the scope definition, risk assessment process, Statement of Applicability, and management review agenda that most organisations need to build from scratch.