No. And the reason matters more than the answer, because it changes what you buy.
ISO/IEC 42001:2023 is titled Information technology, Artificial intelligence, Management system, published December 2023 as a first edition by ISO/IEC JTC 1/SC 42. Its scope clause opens: "This document specifies the requirements and provides guidance for establishing, implementing, maintaining and continually improving an AI (artificial intelligence) management system within the context of an organization." Two further paragraphs extend it to any organization, of any size, providing or using products or services that utilize AI systems.
That is a governance standard. The auditable requirements sit in clauses 4 through 10: context, leadership, planning, support, operation, performance evaluation, improvement. Nothing in that list is a test, and no requirement clause or Annex A control in the published standard is named for penetration testing, security testing or red teaming.
So a consultant telling you ISO 42001 mandates an annual AI penetration test is selling against a clause that does not exist. That does not make the test worthless. It makes it a decision you take on the merits.
The short answer, and why "required" is the wrong question
Management system standards do not prescribe controls. They prescribe a system for choosing controls, then demand you evidence the choice.
Three planning clauses do the work:
Clause | What it establishes | Where it is performed |
|---|---|---|
6.1.2 AI risk assessment | The process and criteria for assessing AI risk | 8.2 AI risk assessment |
6.1.3 AI risk treatment | How risks are treated, and the statement of applicability | 8.3 AI risk treatment |
6.1.4 AI system impact assessment | The process for assessing impacts on individuals, groups and societies | 8.4 AI system impact assessment |
Clause 6.1.4 is the requirement with no equivalent in ISO/IEC 27001. The standard defines it at 3.24 as a "formal, documented process by which the impacts on individuals, groups of individuals, or both, and societies are identified, evaluated and addressed by an organization developing, providing or using products or services utilizing artificial intelligence."
So the certification body never asks "did you run a pentest?" It asks "you identified this AI risk, you chose this treatment, show me it works." The introduction says as much: an organization conforming with the requirements can generate evidence of its responsibility and accountability regarding its role with respect to AI systems. Evidence is the currency, and a scoped AI security test is among the cleanest artefacts available.
What ISO/IEC 42001 actually is, and how it differs from a technical standard
Two structural facts decide most of the confusion here.
First, it uses the harmonized management system structure. The introduction states that the document applies the harmonized structure, with identical clause numbers, clause titles, text and core definitions, to enhance alignment among management system standards. That is why clauses 4 through 10 read like ISO/IEC 27001 or ISO 9001, and why running an AI management system alongside an existing ISMS is an integration exercise rather than a parallel build.
Second, and less well known, ISO/IEC 42001 has exactly one normative reference: ISO/IEC 22989:2022 on AI concepts and terminology. ISO/IEC 27001 is not a normative reference. The standard borrows the ISO/IEC 27000 definition of information security at term 3.23, but it does not import ISO/IEC 27001's control set by reference. Nothing in ISO/IEC 42001 obliges you to hold ISO/IEC 27001, and nothing in it drags 27001's technical controls into your AI scope automatically.
The other point worth correcting: vendor content widely claims ISO/IEC 42001's Annex A is informative, unlike ISO/IEC 27001's. The published contents page says otherwise. Annex A (normative), Reference control objectives and controls starts at page 17, and Annex B (normative), Implementation guidance for AI controls runs page 21 to page 45. Annex C and Annex D are informative. Annex B being normative and twenty-five pages long is the most underrated fact about implementing this standard: the implementation guidance is part of the requirements, not advisory colour.
Where testing enters: the Annex A controls that create the expectation
Annex A organises 38 controls under nine control objectives, numbered A.2 through A.10. The annex text is behind ISO's paywall, so the control titles below come from published reproductions rather than the standard itself, and they agree across independent sources.
Objective | Title | Relevance to security testing |
|---|---|---|
A.2 | Policies related to AI | Where testing cadence gets written down, if anywhere |
A.5 | Assessing impacts of AI systems | Feeds the impact assessment at 6.1.4 and 8.4 |
A.6 | AI system life cycle | Contains A.6.2.4 AI system verification and validation, the closest thing to a testing control |
A.7 | Data for AI systems | Poisoning and provenance risks land here |
A.9 | Use of AI systems | Responsible use, intended use, misuse boundaries |
A.10 | Third-party and customer relationships | Model provider and subprocessor risk |
A.6.2.4 is the control every buyer eventually points at. It sits between documentation of design and development at A.6.2.3 and deployment at A.6.2.5. It is a lifecycle assurance control, not a security testing control, and it names no method. That is the honest reading.
Here is what turns it into a practical expectation anyway. Term 3.26 defines the statement of applicability as "documentation of all necessary controls and justification for inclusion or exclusion of controls," and its notes are unusually direct: organizations may not require all Annex A controls, or may exceed the list with their own, and all identified risks and the risk management measures addressing them shall be reflected in the statement of applicability.
Read that against a customer-facing LLM application. If your risk register contains prompt injection, agent tool abuse or cross-tenant retrieval leakage, and your statement of applicability either excludes A.6.2.4 or includes it with no evidence behind it, you have written yourself a nonconformity. Not because the standard demanded a pentest, but because you claimed a risk was treated and showed nothing.
The 27001 overlap: which technical testing controls come from the neighbouring standard
If you already hold ISO/IEC 27001:2022, three Annex A controls are where AI security testing evidence naturally files:
Control | Title | What it covers |
|---|---|---|
A.8.8 | Management of technical vulnerabilities | Identification, evaluation and remediation of vulnerabilities in systems in use |
A.8.29 | Security testing in development and acceptance | Testing during the development lifecycle and before acceptance |
A.8.31 | Separation of development, test and production environments | Environment isolation, relevant when testing a live model backend |
Two corrections that save money. ISO/IEC 27001 does not mandate penetration testing either. None of those three controls names a method, and the standard sets no frequency, so "ISO 27001 requires an annual pentest" is as false as the 42001 version. And A.12.6.1 is withdrawn 2013 numbering: a proposal citing it in 2026 is working from a control set retired four years ago. The current references are A.8.8 and A.8.29.
The overlap gives you a control home, not a mandate. Run one testing programme, file the report against A.8.8 and A.8.29 in the ISMS and against your A.5 and A.6 treatment decisions in the AI management system, and you have paid once for evidence serving two certificates.
What a certification body will ask for as evidence of AI risk treatment
Certification bodies are themselves regulated here, worth knowing before the opening meeting. ISO/IEC 42006:2025, published on 7 July 2025, sets requirements for bodies auditing and certifying AI management systems, supplementing ISO/IEC 17021-1. Its structure tells you what to expect: clause 7.1.2 covers generic technical competence, 7.1.3 covers specific technical competence requirements and runs several pages, clause 9.1.4 covers determining audit time, clause 8.4.2 covers the auditor's access to your documentation, and Annex A, Audit time, is normative, with a further informative Annex B of worked calculations.
That last point answers the cost question honestly. Fees follow computed audit days under a normative annex, driven by scope, headcount, number and complexity of AI systems and site count. There is no list price, and any vendor quoting a fixed certification cost without scoping is guessing.
What the auditor will actually ask, clause by clause:
Clause | The question in the room | What closes it |
|---|---|---|
6.1.2 / 8.2 | How did you identify this AI risk, and against what criteria? | Risk register entries naming concrete AI failure modes, not "model risk" |
6.1.3 / 8.3 | Which control treats it, and why did you include or exclude the Annex A entries? | Statement of applicability with per-control justification |
6.1.4 / 8.4 | What is the impact on individuals, groups and society? | Impact assessment records, refreshed on material change |
A.6.2.4 | How do you know the system behaves as specified before it ships? | Verification and validation records, including adversarial testing where the risk register calls for it |
9.1 | How do you measure whether the treatment is effective? | Findings closed by severity, retest results, trend over time |
For the impact assessment, ISO/IEC 42005:2025 gives the structure: clause 6.8.3 on AI system failures and reasonably foreseeable misuse, clause 6.9 on measures to address harms and benefits, plus an informative annex on using it with ISO/IEC 42001 and an example template. A security test report enumerating reproducible failure modes populates 6.8.3 better than any workshop output, which is the practical argument for buying one.
Stingrai produces that testing evidence. We are a CREST-accredited penetration testing service provider at firm level, and our reports are built to hand straight to a certification body: scope statement, reproduction steps, severity, remediation status and retest dates, mapped to the risk register entry they support.
Scoping the testing line item: what a 42001-supporting AI assessment covers
An AI product is two surfaces, and buyers routinely pay for one assuming they bought both.
The model and agent layer. Direct and indirect prompt injection, tool and function-call permission scope, egress paths that let an injected instruction move data out, autonomy budget before a human sees an action, retrieval isolation across tenants, output handling into downstream sinks, and abuse of the model's own capabilities. This is human-led AI red teaming, mapping to your A.5, A.6 and A.9 treatment decisions.
The application layer. The web application wrapping the model still has authentication, authorisation and business logic. Stingrai's autonomous agent, Snipe, tests web applications: black-box dynamic testing plus white-box source review, hunting complex classes such as IDOR, broken authorization and business logic flaws, with AutoFix pull requests and pull-request gating. Snipe is a web application agent; network, Active Directory, cloud and social engineering testing need separate scoping.
Autonomous testing runs at US$3,000 one-time or US$450 per month; hybrid, which adds human validation of every finding, runs at US$6,800 one-time or US$1,275 per month on a twelve-month engagement. Both carry the "No High or Critical Finding = Don't Pay" guarantee, and enterprise engagements are scoped individually. See the pricing page and the AI/LLM pentest scope of work template.
42001 vs EU AI Act vs SOC 2: which one actually forces a test
Framework | Forces a test? | The operative text |
|---|---|---|
ISO/IEC 42001:2023 | No | No requirement clause or Annex A control names testing; expectation arrives through risk treatment evidence |
ISO/IEC 27001:2022 | No | A.8.8 and A.8.29 name neither method nor frequency |
SOC 2 | No | No pentest requirement and no frequency; CC7.1 is the vulnerability scanning criterion, and a pentest lands at CC4.1 |
EU AI Act, high-risk systems | Yes, but from 2 December 2027 or 2 August 2028 | Article 9(6): "High-risk AI systems shall be tested for the purpose of identifying the most appropriate and targeted risk management measures" |
EU AI Act, GPAI with systemic risk | Yes, in force since 2 August 2025 | Article 55(1)(a) requires model evaluation "including conducting and documenting adversarial testing of the model" |
PCI DSS v4.0.1 | Yes | The only framework in general use that mandates penetration testing across its whole population |
Article 9(8) requires testing of high-risk systems at any time throughout development and, in any event, before the system is placed on the market or put into service; Article 9(7) allows testing in real-world conditions under Article 60. Article 15 never uses the phrase penetration testing, but paragraph 5 requires resilience against unauthorised third parties altering use, outputs or performance, and names data poisoning, model poisoning, adversarial examples or model evasion, confidentiality attacks and model flaws. Article 55(1)(a) is the only one of the three that says adversarial testing, and it binds providers of general-purpose AI models with systemic risk.
Timing is where 2026 budget documents now go wrong, because the Article 113 published in the Official Journal in 2024 is no longer operative. Regulation (EU) 2026/1744 of 8 July 2026 amended it, so read the consolidated text. Chapter V still applied from 2 August 2025 and the regulation still applies generally from 2 August 2026, but the high-risk requirements were deferred: Chapter III Sections 1 to 3, where Article 9 and Article 15 both sit, now applies from 2 December 2027 for systems high-risk under Article 6(2) and Annex III, and from 2 August 2028 for systems high-risk under Article 6(1) and Annex I. The date 2 August 2027 no longer appears in Article 113 at all.
That splits your budget. High-risk exposure makes Article 9 and Article 15 a 2027 or 2028 duty, so you are funding readiness, not compliance. A general-purpose AI model with systemic risk is different: Article 55(1)(a) was untouched by the amendment and is live today.
One more thing buyers get told and should not believe: certifying to ISO/IEC 42001 does not give you a presumption of conformity with the EU AI Act. Article 40(1) attaches that presumption to harmonised standards whose references "have been published in the Official Journal of the European Union," and only so far as they cover the requirements. CEN-CENELEC JTC 21 develops the European standards for AI, including harmonised standards supporting the AI Act, and its work programme lists an AI quality management system standard of its own. An ISO/IEC 42001 certificate is no substitute.
Budget model: what to fund in year one and what can wait
Item | Year one | Surveillance years |
|---|---|---|
Gap assessment and AIMS build | Fund it | Maintenance only |
Impact assessment process and records | Fund it | Refresh on material change |
Certification body audit (stage 1 and stage 2) | Fund it, sized by ISO/IEC 42006 audit time | Reduced surveillance audit |
AI red team of the highest-risk system | Fund it | Repeat on material change |
AI red team of remaining systems | Defer unless customer-driven | Rotate through the estate |
Web application testing of the AI product | Fund it, continuous is cheaper than annual | Continuous |
Retest of high and critical findings | Fund it | Included in continuous |
The rule of thumb that survives an audit: test the systems your own risk assessment ranked highest, once, properly, before stage 2, and show the register entry, the treatment decision, the test, the fix and the retest as one chain. That beats a broad, shallow sweep across every model you touch.
If the EU AI Act drove this project, read the Article 15 security testing evidence pack next. For what auditors accept, see pentest evidence auditors accept and will an auditor accept an AI pentest. The defence-contractor equivalent is does CMMC require penetration testing; the technical scope is in AI red teaming for LLM and agentic apps.
Frequently Asked Questions
Does ISO 42001 require penetration testing?
No. ISO/IEC 42001:2023 places its auditable requirements in clauses 4 through 10, and no requirement clause or Annex A control is named for penetration testing, security testing or red teaming. The closest control by title is A.6.2.4, AI system verification and validation, which names no method. Testing enters indirectly, through clause 6.1.3 risk treatment and the statement of applicability, which at term 3.26 requires "documentation of all necessary controls and justification for inclusion or exclusion of controls."
What is ISO 42001 and who needs it?
ISO/IEC 42001:2023 is the international standard for an artificial intelligence management system, published in December 2023 by ISO/IEC JTC 1/SC 42. Its scope clause specifies requirements and guidance for establishing, implementing, maintaining and continually improving an AI management system within the context of an organization, and it applies to any organization of any size that provides or uses products or services utilizing AI systems. In practice the organisations pursuing it are AI vendors whose enterprise customers have started asking for it in security reviews.
Is ISO 42001 the same as ISO 27001?
No. They share the harmonized management system structure, so clauses 4 through 10 look similar, but the subject matter differs and neither imports the other. ISO/IEC 42001 has exactly one normative reference, ISO/IEC 22989:2022, so ISO/IEC 27001's control set is not pulled in. ISO/IEC 42001 also adds clause 6.1.4, the AI system impact assessment, which has no equivalent in ISO/IEC 27001.
Do I need ISO 27001 before ISO 42001?
No. Nothing in ISO/IEC 42001 makes ISO/IEC 27001 a prerequisite, and ISO/IEC 27001 is not among its normative references. Most organisations run them together because the harmonized structure lets one set of clause 4 to 10 processes serve both certificates, and because controls such as A.8.8 and A.8.29 give AI security testing evidence a natural filing home. That is an efficiency argument, not a sequencing requirement.
What evidence does an ISO 42001 auditor want for AI risk treatment?
A traceable chain: the risk register entry naming a concrete AI failure mode, the treatment decision, the statement of applicability entry justifying inclusion or exclusion of the relevant Annex A control, the control implementation, and evidence the control works. For a customer-facing AI system that usually means verification and validation records under A.6.2.4, plus impact assessment records under clause 8.4. ISO/IEC 42005:2025 structures that assessment, including clause 6.8.3 on AI system failures and reasonably foreseeable misuse, which is what a security test report populates.
How much does ISO 42001 certification cost?
There is no list price, and the reason is structural. ISO/IEC 42006:2025 governs certification bodies and makes its Annex A on audit time normative, with clause 9.1.4 covering how audit time is determined and an informative Annex B of worked calculations. Your fee therefore follows computed audit days driven by scope, headcount, number and complexity of AI systems and site count, plus your own build and evidence costs. Any quote given before scoping is a guess.
Does ISO 42001 require AI red teaming?
No. No requirement clause and no Annex A control in ISO/IEC 42001 is named for red teaming. It becomes hard to avoid when your own AI risk assessment under clause 6.1.2 identifies risks such as prompt injection or agent tool abuse, because clause 6.1.3 then requires a recorded treatment and the statement of applicability requires justification for including or excluding the relevant control. Regulation is stricter here: EU AI Act Article 55(1)(a) requires documented adversarial testing for general-purpose AI models with systemic risk.
Is ISO 42001 required by the EU AI Act?
No, and certifying to it does not give you a presumption of conformity. Article 40 attaches that presumption to harmonised standards whose references have been published in the Official Journal of the European Union, and CEN-CENELEC JTC 21 is developing European standards in support of the AI Act, including an AI quality management system standard of its own. An ISO/IEC 42001 certificate is useful evidence of governance maturity, but not a route to Article 40 presumption.
References
ISO/IEC 42001:2023, first edition 2023-12, official preview (contents, clauses 1 to 4, terms 3.1 to 3.26): standards.iteh.ai PDF; catalogue entry, edition and scope abstract: IEC Webstore
ISO/IEC 42006:2025, published 2025-07-07, official preview: standards.iteh.ai PDF and IEC Webstore
ISO/IEC 42005:2025, AI system impact assessment, official preview: standards.iteh.ai PDF
ISO/IEC 23894:2023, published 2023-02-06: IEC Webstore
Regulation (EU) 2024/1689 (EU AI Act), consolidated text 02024R1689 EN 27.07.2026 001.001, used for Articles 9, 15, 40, 55 and 113: EUR-Lex consolidated version. The as-published version, still carrying the superseded Article 113 dates: OJ L 1689, 12.7.2024
Regulation (EU) 2026/1744 of 8 July 2026, the amending act (OJ L 1744, 24.7.2026) replacing Article 113 points (a), (c) and (d): EUR-Lex
CEN-CENELEC, AI work programme and JTC 21 remit: cencenelec.eu
Secondary, Annex A numbering and titles (standard text paywalled; two reproductions cross-checked): ISMS.online and Mindset Cyber
Secondary, ISO/IEC 27001:2022 Annex A titles 8.8, 8.29 and 8.31: ISMS.online
