Loading
Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
ISO 27001 never says "penetration test" — what Annex A.8.29 actually requires instead, and why auditors still expect one as evidence.
ISO/IEC 27001 never uses the words "penetration test." Search the standard's actual Annex A control text and you won't find it named once — which surprises a lot of people scoping a test specifically because an auditor asked for one. The real requirement sits one level more abstract, in a control that names testing as a method, not a mandate.
Annex A.8.29, "Security testing in development and acceptance," requires organizations to define and carry out security testing throughout the development lifecycle — from initial design through to final acceptance, before anything goes live. The control names a range of acceptable testing methods, static analysis and code review among them, and dynamic testing — vulnerability scanning and penetration testing specifically — as an accepted implementation approach, not the only one. It's risk-based by design: the standard doesn't mandate specific tools or a fixed testing cadence, it expects testing that's proportionate to the system and its actual exposure.
This is the exact same shape of nuance that shows up across every framework we scope testing against — NIS2's Article 21 and DORA's general ICT testing obligation both describe risk-management outcomes without naming penetration testing as the only path there either. ISO 27001 follows the same pattern: A.8.29 is satisfied by structured, risk-based security testing, and penetration testing happens to be the most common, most credible way organizations actually demonstrate they've done it — not because the standard requires that specific method, but because it's the method that produces evidence an auditor can actually evaluate.
In practice, an ISO 27001 auditor reviewing A.8.29 evidence wants to see that testing happened, that it was proportionate to what's being protected, and that findings were tracked through to remediation — not a specific report format or a specific vendor. A single annual automated scan with no manual validation is a much harder sell as "risk-based" testing for a system handling sensitive data than it would be for a low-exposure internal tool. This is exactly where the distinction in our piece on manual testing vs. automated vulnerability scanning matters for an ISO 27001 audit specifically — a scan report alone is thinner evidence than a report showing genuine exploitation attempts and validated findings.
The contrast with PCI DSS Requirement 11.4 is instructive: PCI DSS names penetration testing directly, with numbered sub-requirements specifying scope and frequency. ISO 27001 deliberately doesn't — it's a general-purpose management-system standard covering every kind of organization and risk profile, so it stays at the level of "test appropriately" rather than prescribing a specific control for every certified organization's very different threat models. That flexibility is also what makes A.8.29 easy to under-scope if nobody on the implementation team has actually mapped what "appropriate" means for their specific environment.
If ISO 27001 certification (or maintaining an existing one) is driving your testing requirement, the practical starting point is documenting why your chosen testing approach is proportionate to your actual risk — not just that testing happened. A scoping conversation should cover what's in-scope for your ISMS, how sensitive the data behind it is, and what evidence your certification body has historically expected to see, since auditor expectations for A.8.29 evidence do vary in practice even though the control text itself doesn't specify. Our Penetration Testing service and Cybersecurity Consulting team can help scope testing that genuinely holds up as A.8.29 evidence, not just a checkbox exercise.
Tell us about your environment and goals — we'll help you scope the right engagement.