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 your current control gaps against what testers are likely to find, an gap analysis is a useful starting point before commissioning a test.
Security Controls Validation
Your ISMS documentation asserts that certain controls are in place and working. Penetration testing verifies whether that is actually true. Network segmentation, multi-factor authentication, access restrictions, encryption in transit: these can all appear correctly configured on paper while being trivially bypassable in practice.
According to NIST Special Publication 800-115, organisations should conduct analysis and reporting that translates penetration test findings into concrete risk mitigation actions. Mapping each finding to a specific Annex A control, and documenting whether that control withstood or failed the test, is precisely the kind of evidence that satisfies an auditor and strengthens your SoA.
Monitoring and Continual Improvement
ISO 27001’s Clause 10 requires continual improvement of the ISMS. Penetration testing is one of the most direct mechanisms for driving that improvement. Each test cycle identifies new weaknesses, confirms previous remediations are holding, and adjusts your risk picture to reflect changes in the threat landscape and your own infrastructure. An annual penetration test programme, properly integrated with your risk register, is a living feedback loop rather than a point-in-time snapshot.
Types of Penetration Testing for ISO 27001
The scope of penetration testing for ISO 27001 should align with the boundaries of your ISMS. Every asset type that falls within scope is a candidate for testing proportionate to its risk profile. The following categories represent the most relevant testing types for organisations pursuing or maintaining certification.
Network Infrastructure Testing evaluates routers, firewalls, switches, intrusion detection systems, and remote access controls. Testers attempt to bypass network defences, pivot between segments, and exploit protocol weaknesses. This directly validates Annex A 8.20 (Secure network architecture).
Web Application Security Testing assesses internet-facing applications for vulnerabilities including injection attacks, broken authentication, insecure direct object references, and business logic flaws. The OWASP Top 10 provides a widely accepted reference framework for this type of testing.
Wireless Testing examines the security of Wi-Fi networks, including rogue access points, weak encryption configurations, and captive portal bypasses. Wireless environments are frequently underscoped in ISO 27001 programmes despite representing a meaningful attack surface.
Application and API Security Review assesses internal and external APIs for authentication weaknesses, excessive data exposure, rate-limiting failures, and injection vulnerabilities. As API-driven architectures become the norm, this testing type has grown in direct relevance to Annex A 8.29 compliance.
Social Engineering Testing simulates phishing campaigns and pretexting attempts to assess whether personnel controls are effective. This type directly informs people-focused controls including Annex A 6.3 (Information security awareness, education and training).
Mobile Security Testing reviews mobile applications and their backend interactions for insecure data storage, weak authentication, and insufficient transport layer security.
Remote Working Assessment evaluates the security of remote access infrastructure, VPN configurations, endpoint controls, and cloud access pathways. Given the permanent shift to hybrid working in most organisations, this assessment type is increasingly relevant to any ISMS scope.
Firewall Configuration Review examines rule sets, zone configurations, and egress controls to identify permissive rules, redundant exceptions, and policy drift that may have accumulated over time.
Penetration Testing Perspectives and Methodologies
The perspective from which a penetration test is conducted determines what it can realistically find. Choosing the right methodology for each testing context is part of scoping effectively. For a deeper look at the trade-offs involved, see our guide on automated vs manual penetration testing.
Black Box Testing provides the tester with no prior knowledge of the target environment. This most closely simulates an external attacker who has done reconnaissance but has no insider access. It is realistic in terms of attack simulation but may miss issues that require architectural understanding to identify.
Grey Box Testing gives the tester partial information: network diagrams, application credentials, or high-level architecture documentation. This is often the most practical approach for ISO 27001 engagements because it balances realism with efficiency. The tester can focus on meaningful attack paths rather than spending engagement time on reconnaissance.
White Box Testing provides full access to source code, architecture documentation, and configuration details. This is the most thorough approach and is particularly relevant to Annex A 8.29, where the goal is to identify insecure coding patterns and design flaws before deployment.
What Should an ISO 27001 Penetration Test Plan Include?
A penetration test without a documented plan produces findings that are difficult to defend in an audit. The plan should define the scope (which systems, IP ranges, and applications), the testing methodology (black, grey, or white box), the testing window, rules of engagement, and who has authorised the engagement.
The resulting report should include an executive summary that maps findings to business impact, a technical findings section with severity ratings tied to a recognised scoring system such as CVSS, remediation guidance for each finding, and a retesting section that confirms whether fixes are effective. Findings should be explicitly mapped to Annex A controls wherever possible. An auditor reviewing this report should be able to trace each finding to a specific risk, a treatment decision, and an outcome.
Critically, penetration test documentation should be stored in your organisation’s native ISMS repositories, your SharePoint, Confluence, or equivalent. Findings sitting inside a third-party tool’s dashboard are not visible to auditors and do not demonstrate management ownership or oversight.
How Penetration Testing Supports Your ISMS
In-House Development Environments
For organisations that develop software internally, Annex A 8.29 requires that security testing is embedded in the development lifecycle, not bolted on at the end. Penetration testing is listed specifically as a method for identifying weak coding and design. The practical expectation is that significant releases and architectural changes are subject to an independent penetration test before promotion to production. “Independent” is the operative word: internal developers testing their own code does not meet the requirement.
Outsourced Development Environments
Where development is delegated to a third party, the organisation remains responsible for security outcomes. Annex A 8.29 requires that contractual arrangements include security testing requirements, and Annex A 5.20 (Supplier relationships) establishes the broader framework for managing supplier security obligations. Accepting a vendor’s self-attestation in lieu of test evidence introduces risk that auditors will probe.
Structural and Organisational Changes
Penetration testing should not be a purely calendar-driven exercise. Any significant change, a cloud migration, a new application, a network rearchitecture, an acquisition, reintroduces risk that existing controls may not adequately address. ISO 27001’s change management requirements (Annex A 8.32) and continual improvement obligations both support the case for trigger-based testing in addition to annual cycles.
ISO 27001:2022 vs ISO 27001:2013: Changes to Security Testing Requirements
What Changed in Annex A 8.29 for ISO 27001:2022
The 2022 update consolidated Annex A 14.2.8 (System security testing) and A.14.2.9 (System acceptance testing) from the 2013 standard into a single, clearer control: A.8.29. The consolidation is not merely administrative. The new control is more explicit about the requirement for security testing in both the development phase and at acceptance, for both in-house and outsourced environments.
The 2022 version also places greater emphasis on the idea that testing must be risk-based and documented, not performed as a routine checklist exercise. Auditors under the 2022 standard are expected to check not only that testing occurred, but that test plans linked security requirements to test cases, that findings were triaged appropriately, and that remediation was verified before sign-off. This is a meaningful shift from how many organisations approached the 2013 requirements.
How ISO 27001:2013 Approached Acceptance Testing
Under the 2013 standard, acceptance testing (A.14.2.9) was largely focused on confirming that new systems met predefined acceptance criteria before deployment. Security testing (A.14.2.8) addressed systematic testing of systems against defined security requirements. The two controls were related but treated separately, and in practice many organisations satisfied them with functional test results rather than dedicated security testing. The 2022 consolidation closes that gap by making security validation in both development and acceptance a single, unified expectation. Organisations still working toward transition should also review the common ISO 27001 pitfalls that trip up programmes during this shift.
How to Maintain ISO 27001 Certification Through Ongoing Penetration Testing
Certification is not a destination. Annual surveillance audits and three-yearly recertification audits require ongoing evidence that your ISMS is functioning, including that security testing is current and that findings are being acted upon.
The practical standard for maintaining certification through penetration testing involves testing at least annually, with additional targeted tests following material changes to systems or infrastructure. Tests should be completed six to eight weeks before any scheduled audit to allow time for remediation. Maintain a remediation log that maps each finding to a closure date and a verification test, and formally accept in writing any residual risk that cannot be fully remediated before the audit.
The risk register and Statement of Applicability should always reflect the most recent test cycle. If a penetration test uncovered a weakness in network segmentation six months ago and your SoA still describes segmentation as fully effective, an auditor will notice the inconsistency. For organisations building out or reassessing their current testing programme, starting with an ISO 27001 gap analysis is an effective way to prioritise where testing effort is most urgently needed.
Organisations that are new to this process or working through a transition to the 2022 standard often benefit from working with an experienced ISO 27001 consultant who can align the testing programme with audit expectations from the outset. Equally, pairing your penetration testing evidence with a rigorous ISO 27001 internal audit process, or using dedicated internal audit services, ensures that findings are properly integrated into your ISMS before an external auditor arrives.
If you are ready to build a penetration testing programme that holds up under audit scrutiny, or need support aligning your existing testing evidence with ISO 27001 requirements, contact us to discuss your situation. You may also find it useful to learn more about how compliance automation tools can support your broader ISMS programme.
Is penetration testing mandatory for ISO 27001 certification?
How often should penetration testing be performed for ISO 27001?
What is the difference between a vulnerability assessment and a penetration test in the context of ISO 27001?
Who can perform a penetration test for ISO 27001?
How does a penetration test support an ISO 27001 audit?
Does ISO 27001 require both internal and external penetration testing?
