ISO 42001 for AI Security Teams: What It Requires

Typically, a security team meets the standard in the same way – when a procurement query hangs up on one of the security providers, or when a board asks if the company's AI is "governed," and ISO 42001 appears on your desk with no specific owner. The first certifiable AI management system standard, ISO/IEC 42001:2023, was published in December 2023, and most of the AI management system's content has been published as a governance overview for compliance leads. This piece is narrower and more useful: the required clauses, the 38 Annex A controls, the Statement of Applicability, and the audit itself, and, crucially, where the standard ends. See our comparison of AI risk management frameworks for how it compares to NIST AI RMF and EU AI Act.

What ISO 42001 Actually Certifies

The most frequent misread is considering it as a technical standard; a list of AI guidelines that are either checked or unchecked. It is not. An AIMS is the AI Management System of an organization, certified by ISO/IEC 42001:2023, that consists of policies, roles, processes, and documented decisions that enable an organization to consistently manage the development, provision, and use of its AI. It is entitled Information technology - Artificial intelligence - Management system. If, like me, you have been through ISO 27001, this is the same equipment aimed at AI risk as opposed to Information security risk.

Such a distinction has practical implications for scope. Certification does not apply to a company or a single model; it applies to a defined boundary. Google Cloud's certification as an accredited ISO/IEC 42001 certifies specific products, not “Google's AI” in general, as announced in December 2024. The real question a security team should ask is not "which controls do we need?" but "which AI systems are inside the AIMS, and can we defend this line of the AIMS to an auditor?

The Mandatory Clauses (4–10)

All that an auditor can raise a nonconformity against resides in Clauses 4- 10, which are the actual ISO 42001 requirements, and written in the same Harmonized Structure as all other modern ISO management systems. Clauses 1-3 contain scope, references, and terminology and have no obligations. The following six subsections take you through the required clauses, marking their responsibilities on a security team's agenda and highlighting where ownership lies, as it is shared throughout the business.

Context, Leadership, and AI Policy (Clauses 4–5)

Clauses 4 and 5 require you to specify who's covered by the AIMS (which AI systems, business units, and interested parties) and who's not (what external and internal issues, such as regulatory exposure and your AI maturity, are covered, and what are not). Clause 5 places accountability at the top management level; they own AI policy, assign roles, and commit resources. Responsible AI is not a task that can be handed off to the model shipper. The leadership is recorded in Clause 5; if your CISO is a role owner of AIMS, the auditor will verify that leadership is in fact engaging and not rubber stamping.

Risk Assessment and Objectives (Clause 6)

Clause 6 is the planning core: define a process for AI risk assessment and risk-treatment; define measurable objectives for AI; and - in contrast to ISO 27001 - define the process for assessing the impact of AI systems (Clause 6.1.4). The question of risk assessment here is what can go wrong with the organization, and impact assessment is what the system can do to individuals, groups, and society. The methodology for identifying all sources of risk is normally the property of a security team, who will map out the various sources of risk associated with the use of AI into the register.

Resources, Competence, and Documentation (Clause 7)

The supporting fabric, resources, competence, awareness, communication, and documented information are covered in Clause 7. In actual terms, the artifacts that can be audited are a competency matrix (who is qualified for each AI-related role), training records in proportion to the exposure of each role, and documents that are version controlled. Senior management requires strategic AI literacy, operators require process-specific training, and the AIMS coordinator requires depth. This clause is not often a finding on intent and is almost always a finding on evidence, such as an undocumented "everyone knows their job" or a missing dated training record.

AI Risk Assessment, Treatment, and Impact Assessment (Clause 8)

The plans in Clause 6 need to be executed in Clause 8. You carry out risk treatment, monitor the lifecycle of the AI system in production and — under Clause 8.4 — conduct the AI system impact assessment at regular intervals and when a material change occurs in the system, and keep the results. This is the question auditors ask the toughest, as a risk register without considering the impacts on people in the real world will not meet this requirement. The dedicated approach in ISO/IEC 42005 (2025) on AI system impact assessment is worth applying instead of developing your own template.

Monitoring, Internal Audit, and Management Review (Clause 9)

Under Clause 9, you are expected to monitor and measure AIMS, conduct internal audits against the clauses and your applicable controls, and conduct a management review to formally review performance as led by leadership. The keyword is evidence for security teams: there's the internal audit report showing the evidence, there's the management review showing the decisions and actions, and there's the monitoring data that shows the system is monitored and not assumed. A control on paper that doesn't generate any monitoring output is a failure waiting to happen – Stage 2.

Continual Improvement and Nonconformity (Clause 10)

When an incident, a missed impact assessment, or a failed control happens, you generate a nonconformity, take corrective action, and put the lesson back in the system: that is C10 in the Plan-Do-Check-Act cycle. An auditor is not interested in a clean record, with no problems. An auditor is not interested in a record that has no problems in it, but is interested in a working corrective-action trail. If it's not a system that has been operating for a year without a single nonconformity, then it's not mature; it's not looking. It's more convincing than a clean slate to catch and close real problems.

Annex A: The 38 Controls Are a Reference Set, Not a Checklist

Annex A provides the control catalog, which is the most frequently misapplied part of the management system defined in Clauses 4–10. ISO 42001 Annex A controls are not a checklist of controls to implement en masse, but a reference list of controls which are used based on risk and impact assessments. The three subsections below cover the nine objectives, how you record selections in the Statement of Applicability, and how to exclude a control without a nonconformity.

The Nine Control Objectives

There are 38 controls listed in the Annex A, organised into nine control objectives (A.1 is an introduction to the controls, so individual controls start at A.2.2). The nine areas are: A.2 Policies related to AI, A.3 Internal organization (roles and reporting of AI concerns), A.4 Resources for AI systems (data, tooling, compute, and human resources an AI system relies on), A.5 Assessing impacts of AI systems, A.6 AI system life cycle, A.7 Data for AI systems (governance, quality, and provenance), A.8 Information for interested parties (transparency and documentation), A.9 Use of AI systems (responsible and intended use, and monitoring in operation), and A.10 Third-party and customer relationships (allocating responsibility across the AI supply chain).

Building the Statement of Applicability (SoA)

The ISO 42001 Statement of Applicability is the document that makes the catalog your control set. In Clause 6.1.3, you define the set of controls you need to treat your risk, evaluate your list against Annex A to see if anything is missing, and write down each control as applicable or not applicable, with a reason. The SoA is not a document you create at the end, but is instead the path that you can follow from a risk from your register to a control on the ground. It is the first thing that auditors read, as it tells them what you claim to do and provides them with a sample of evidence against what you claim. Most implementations flag the mid-to-low 30s of the 38 controls as relevant, with third-party models only consumed by some organizations that only use data-heavy controls.

Justifying Exclusions Without Creating a Nonconformity

If you exclude a control, it's OK; if you don't, it's a Finding. The test would be whether the exclusion is a result of your risk and impact assessments. The justification is valid and grounded in a true statement about your systems because you don't train or fine-tune models, so controls for training-data acquisition are not applicable to your AIMS scope. We didn't get to it" is not. Failure mode auditors flag is a mismatch – a risk identified in your risk register that has no corresponding control and no reason given for the gap. Ensure that all exclusions are supported by a documented reason and the SoA is maintained.

What Annexes B, C, and D Are Actually For

The other annexes are guidance, and you are certified against clauses and Annex A. Each Annex A control is accompanied by implementation guidance that is contained in Annex B - the "how" of conformity. Auditors will refer to it, and you should read it first, before designing a control. Annex C contains a list of organizational objectives and risk sources that relate to AI - bias, security, explainability, data quality, drift – that you can consider for your risk assessment under Clause 6, but treat as an idea bank to minimize the risk of missing out on a risk source your context should have identified. Using the AIMS across sectors and in conjunction with other management systems is covered in Annex D (where you are planning to harmonize across the frameworks if you are implementing other standards, such as ISO 27001 or ISO 9001). Of the three, none includes requirements that need to be certified, but a team can have a control without writing it down in Annex B and still not convince an auditor.

The Certification Path

As with any ISO management system, certification takes place following the accredited path, as defined by ISO/IEC 17021 – Requirements for Bodies Certifying AIMS are defined in ISO/IEC 42006 (published 2025). The sequence involves gap analysis with clauses and the 38 controls and then establishing the AIMS (forming the AI policy, setting up risk and impact assessment processes, and applying relevant controls in actual workflows, not in a document). Then you use it for a while until you get the results - finished impact assessment, risk treatments, results of monitoring, output, etc. - and conduct your own audit and management review before an external auditor arrives, so leadership has already had a look at the system.

The external assessment consists of two parts: a certification audit. Stage 1 is a documentation and readiness review - the auditor confirms that the AIMS is documented and that you are ready, which usually takes 1-2 days. Stage 2 assesses if it actually works by gathering evidence that covers the controls you are applying and interviewing owners. When producing a clean result, there is a certificate issued for a period of 3 years, to be followed by annual surveillance audits and a complete recertification at the end of that 3-year period. The greatest expense is in developing and implementing the AIMS internally, not on the audit, hence the months, not weeks.

If You're Already ISO 27001 Certified

Teams that have an information security program will undoubtedly ask if ISO 42001 is a duplicate of ISO 27001. The truth about ISO 42001 vs ISO 27001 - It's just a rehash and a change of topic. Both are based on the Harmonized Structure, and all the clauses of 4 through 10 and the approach to Annex A (Statement-of-Applicability) are the same, as are the internal-audit and management-review cycles. It is for this reason that the harmonization of ISO 27701, ISO 27001 and ISO 9001 is so important - it means you don't have to maintain parallel bureaucracies, as you can conduct combined internal audits, have one governance forum, and one documentation system. The vast majority of organizations that already have ISO/IEC 27001 say the ISO 42001 project substantially reduces in size as the load-bearing machinery is already in place.

The AI-specific delta is not transferable, which is where a security team's true work lies. While ISO 27001 covers the confidentiality, integrity, and availability of information assets, ISO 42001 covers AI behavior and impact - risk factors not related to “leaks” like biased output, model drift, unexplained decisions, and harm to individuals or society. The really new artifacts are the AI system impact assessment, the AI lifecycle controls (A.6), and the AI responsible-use and transparency controls (A.8, A.9). Attempt to meet those - point to the existing ISMS evidence; an auditor will pick up: Management system shared, impact/lifecycle content not.

What Security Teams Specifically Need to Own

There are four points handed out specifically to security that warrant taking them up, not leaving them out. Four items are handed specifically to security and are worth having and not taking for granted throughout the program as a whole. Typically, security takes ownership of the AI risk methodology and register (the list of sources that are exposed to risk and the drive to treat them in relation to AI, such as prompt injection, drift, poisoning, excessive agent permissions, etc.). If a policy team writes the register without threat, it will look generic to an auditor.

To implement an AI system impact assessment. The Clause 8.4 impact assessment requires input from a security technical expert that can be given positionwise: what data is systemically affected, what data can it do on its own, what is the area of influence in case of misbehavior. Most of the controls eventually boil down to evidence — a list of AI systems, monitoring results, incident and violation logs, tests. This is the product of the security teams' own tooling, and continuous evidence is better than a screenshot captured the week before the audit. Auditor selection: Insist on an accredited certification body – accreditation (from bodies like UKAS, ANAB or RvA) is the key to making the certificate a recognized certificate for the buyers and regulators that you are certifying for. An unaccredited "assessment" is not a credential, sign prior to confirmation of accreditation and the auditor's AI-specific experience.

Where ISO 42001 Doesn't Reach

Here is what ISO 42001 doesn't say, and doesn't say much about operational agentic and MCP-specific risk. It does not tell you how to prevent a prompt injection, how to detect a poisoned MCP tool, how to block an over-permissioned agent from chaining tool calls, how to detect line-jumping in an MCP workflow, etc.; it requires you to have a process to assess and treat AI risk. A certified AIMS isn't an indication that your systems filter or log individual agent requests; it's a guarantee that you make the decisions.

That's the difference in action. A compliance team could take months to document models, data governance, and risk assessments for certification and, meanwhile, runtime behavior of production agents remains ungoverned and agent behavior changes between audits in ways a point-in-time assessment doesn't capture. The OWASP Top 10 for Agentic Applications (insecure tool use, excessive permissions, multi-agent trust boundaries), the OWASP MCP Top 10 and the MITRE ATLAS map the agent-level attack surface, which ISO 42001 regulates but does not operationalize. This aligns with our overarching MCP security guidance: The standard is the governance frame, and runtime discovery, testing, and enforcement is the line in the sand against agentic threats. They both are required and easy to combine, thereby passing the audit and still being breached.

How Akto Generates ISO 42001 Audit Evidence

ISO 42001 boils down to evidence, and the AI-focused elements, such as inventory, lifecycle testing, runtime monitoring, and impact input, are where manual collection falls short. That is where Akto is in. AI agents, MCP servers, tools, and resources are automatically identified and cataloged by Akto-via 50+ connectors-providing the live AI system inventory that Clause 8 operation and A.4 resource controls depend on; with only 21% of enterprises having visibility into what their agents are doing, as found by the 2025 State of Agentic AI Security Report released by Akto. It introduces an AI Agent Context Graph that visualizes the relationship of agents, tools, permissions, and data, directly feeding into the impact assessments and risk treatment.

In CI/CD, Akto continuously red-teams over 4,000 AI-specific probes and, for use control, applies runtime guardrails to prevent malicious prompts, unsafe tool calls, and data leakage in real time, keeping a forensic audit trail of every prompt, response, and violation. Importantly, for certification, Akto documents that activity to recognized frameworks like ISO 42001, and produces evidence that a policy was followed, that data is classified, and that violations were logged: what you give an auditor is what the systems really did, not what a policy says.

Final Thoughts on ISO 42001 for AI Security Teams

Remember, ISO 42001 is an auditable AI management system, not a checklist to be reviewed by the security team. Don't think of the 38 controls as a checklist to be ticked off by the security team; ISO 42001 is an auditable AI management system - owned across the business - where the security team's role is to own the risk assessment, feed the impact assessments, and provide the evidence. The most difficult to prove are those portions I identified as specifically related to AI: a live inventory of agents and MCP tools, Lifecycle testing, and Runtime monitoring, not captured by a point-in-time audit. That's exactly what Akto does: it automatically discovers the components in your system, constantly simulates attacks, and, with runtime guardrails, logs every interaction and stores it as evidence that can be audited according to ISO 42001. Book a demo with Akto and see how that evidence is created with your own AI footprint.

FAQs: ISO 42001 for AI Security Teams

What does ISO 42001 actually certify an organization for?

It certifies you are running an AI Management System, which is a documented, auditable framework of policies, roles and processes to manage AI responsibly within a clear scope. It does not certify a model or a certain technical control set, and it is not a proof by itself of EU AI Act conformity.

Are all 38 Annex A controls mandatory for certification?

No. The following clauses are mandatory: Clauses 4 to 10. Annex A is a reference list – the controls you need to have in place will be identified in the Risk/Impact assessments, and you will record any inclusions/exclusions and provide a justification for these.

What is a Statement of Applicability, and why does it matter?

The SoA specifies the controls in Annex A that are in effect (that are not being excluded), and that they are in effect because. It's the "connect the dots" between your risk register and your controls, and typically the first document an auditor reads.

What is an AI system impact assessment, and which clause requires it?

It considers impacts an AI system may have on people, groups, and society, separate from impacts to organizations. You will need to set up the process in Clause 6.1.4 and do it on material change and at intervals, and keep the results in Clause 8.4. An ISO/IEC 42005 template can be used.

What's the difference between Annex A, B, C, and D?

The set of 38 controls is the certifiable set (Annex A). Annex B is implementation guidance for them. Annex C is a list of AI objectives and AI risk sources for your risk assessment. See Annex D for cross-sector and cross-standard application. The requirement is only for Annex A.

What does the ISO 42001 certification process actually involve, step by step?

Gap analysis, develop the AIMS, implement it to produce records, conduct an internal audit and management review, and an external audit of two phases: Stage 1 (documentation and readiness), and Stage 2 (operating effectiveness). If the test result is clean, it will be issued a three-year certificate, with annual surveillance audits.

Is ISO 42001 easier to achieve if we're already ISO 27001 certified?

Yes, materially. The foundation of both is the same; they share both the Harmonized Structure and the approach of SoA, and the SoA audits are conducted as per the same cadence. The additional work is the AI-specific delta (impact assessments, lifecycle controls, and responsible-use controls) not included in ISO 27001 evidence.

What should a security team specifically own during ISO 42001 implementation?

The components that are likely to fail when passed to a non-technical team: the AI risk methodology and register, technical input to impact assessments and the tooling that creates the control evidence, as well as the criteria for selecting an accredited auditor.

Does ISO 42001 address agentic AI or MCP-specific security risks?

Not at a technical level. It demands that you exercise control over AI risks but leaves you without guidelines on what to do about prompt injection, tool poisoning, MCP trust boundaries, or agent permissions. Others are found in references such as the OWASP Agentic and MCP Top 10 and the MITRE ATLAS, which are enforced using runtime tooling.

What should we look for when selecting an auditor for ISO 42001 certification?

It is an accredited certificate (certificates accredited by UKAS, ANAB, RvA or other accreditation body are recognized). Ensure that the accreditation is up to date and check for experience in auditing in the general ISO area, as well as AI-specific experiences.

How does Akto help generate evidence for ISO 42001 audits?

Akto identifies and catalogs your AI agents, MCP servers, and tools, continually red-teams them, and applies runtime guardrails while keeping a record of all interactions. It maps that activity to frameworks like ISO 42001 and generates the data to document enforcement, data classification, and violations for audits.