ISO 27001 does not use the words “penetration test” anywhere. And yet, auditors conducting Stage 2 assessments routinely expect to see one.  Understanding why that gap exists, and how to close it, is what separates organizations that sail through ISO 27001 certification from those that get caught off-guard. This guide covers what the standard actually says about security testing, which controls drive the expectation for penetration testing, what types of testing are relevant, and how to build a testing programme that genuinely supports your ISMS rather than simply ticking a compliance box. What Is Penetration Testing in the context of ISO 27001? ISO 27001 penetration testing refers to structured, simulated attacks conducted against an organization’s systems, networks, and applications in order to identify exploitable vulnerabilities before real attackers do. In the context of ISO 27001, it serves a specific purpose: providing evidence that the technical controls underpinning your Information Security Management System (ISMS) actually work under real-world conditions. The distinction matters. A vulnerability scan tells you what weaknesses exist whilst a penetration test tells you whether those weaknesses are exploitable, to what degree, and with what consequence. That difference is exactly what auditors are looking for when they ask for testing evidence. Penetration testing is not an isolated activity in an ISO 27001 programme. Its findings feed directly into three of the most scrutinised documents in your ISMS: the risk register, the risk treatment plan, and the Statement of Applicability (SoA). A risk listed in your register as “medium” looks very different once a tester has demonstrated they can chain it into a full domain compromise. Is Penetration Testing a Requirement for ISO 27001? No, it is not explicitly required. The standard does not mandate it by name. What ISO 27001 does require is that organisations establish and maintain a functioning ISMS, perform systematic risk assessments (Clause 6.1.2), implement appropriate controls (Clause 8), evaluate the performance and effectiveness of those controls (Clause 9), and pursue continual improvement (Clause 10). Vulnerability assessment and penetration testing supports every one of those activities with hard evidence. Two Annex A controls make it practically impossible to demonstrate compliance without some form of penetration testing: A.8.8 (Management of Technical Vulnerabilities) and A.8.29 (Security Testing in Development and Acceptance). Auditors conducting Stage 2 assessments will expect to see testing evidence mapped to both. Organisations that substitute a vulnerability scan report and call it done regularly receive non-conformances. The absence of an explicit penetration testing requirement is sometimes misread as permission to skip it. In practice, certified auditors universally expect evidence of testing that goes beyond automated scanning. Relying solely on scan reports is the fastest route to a failed audit. What ISO 27001:2022 Says About Security Testing Annex A 8.29: Security Testing in Development and Acceptance Annex A 8.29 requires organisations to define and implement security testing processes throughout the development lifecycle and before final acceptance of any system. This applies to both in-house development and outsourced or third-party software. The control is preventive in nature. Its purpose is to ensure that no application, database, or system goes into production with known, unmitigated vulnerabilities. For in-house development, the standard specifically references conducting code reviews, performing vulnerability scans, and carrying out penetration tests to identify weak coding and design. For outsourced environments, organisations must set contractual requirements that ensure suppliers meet equivalent security testing standards, accepting a supplier’s assurance without evidence is not sufficient. Annex A 8.29 does not prescribe specific tools or techniques. What it demands is that testing is risk-based, documented, and proportionate to the sensitivity and exposure of the system. A low-risk internal tool used by five people warrants a different level of scrutiny than a customer-facing payment platform. Security testing should scale with risk, and it should happen throughout development, not only at the end. Worth knowing: Annex A 8.29 consolidates two controls from ISO 27001:2013, specifically A.14.2.8 (System security testing) and A.14.2.9 (System acceptance testing), into a single, clearer requirement. The 2022 version makes the expectation of penetration testing more explicit, particularly for major releases and architectural changes. Auditors will ask to see signed penetration test reports or independent security audit summaries for recent major system updates. If such evidence does not exist, they have grounds to mark the control as non-compliant. Annex A 8.8: Management of Technical Vulnerabilities Annex A 8.8 is the vulnerability management control. It requires organisations to identify, assess, and address technical vulnerabilities in a timely manner, taking a proactive and risk-based approach rather than reacting only when something breaks. Crucially, the control explicitly lists periodic, documented penetration tests, conducted either by internal staff or by a qualified third party, as a method for identifying vulnerabilities. Automated scanners have their place, but penetration tests are recognised here as the mechanism for discovering high-risk weaknesses that scanners routinely miss: logic flaws, chained vulnerabilities, privilege escalation paths, and misconfigurations that only become dangerous in combination. Annex A 8.8 replaces two controls from ISO 27001:2013: A.12.6.1 (Technical vulnerability management) and A.18.2.3 (Technical compliance review). The 2022 version introduces a broader, more holistic approach, including the organisation’s public responsibilities, the role of cloud providers, and the expectation that vulnerability management is integrated with change management rather than treated as a separate activity. The Role of Penetration Testing in ISO 27001 Compliance Risk Assessment and Treatment ISO 27001’s risk-based model sits at the core of everything. Penetration testing feeds that model with real-world evidence rather than hypothetical assumptions. When a tester demonstrates that an attacker can move laterally from a compromised workstation to a production database in four steps, that finding transforms what was previously a theoretical risk into a documented, evidenced vulnerability with a severity rating, an exploitability score, and a required remediation action. This evidence directly informs how risks are treated. ISO 27001 requires organisations to choose one of four treatment options for each risk: mitigate, accept, avoid, or transfer. Without penetration test data, those decisions rest on estimation. With it, they rest on proof. If you haven’t yet mapped