Penetration testing is one of the most widely misunderstood requirements in ISO 27001. Consultants frequently tell clients they need annual pen tests to achieve certification. Organisations buy pen tests as an ISO 27001 checkbox exercise. And the common assumption — that pen testing is a mandatory requirement of the standard — is repeated frequently enough that it has become accepted wisdom.
It is not accurate. ISO 27001 does not mandate penetration testing. What it does require is considerably more nuanced — a structured approach to identifying and managing technical vulnerabilities, and where appropriate, independent technical reviews. Whether penetration testing is the right mechanism to fulfil those requirements depends on your organisation’s scope, risk profile, and the nature of your systems.
This guide explains what the standard actually says, which controls are relevant, and how to make an informed decision about whether and how pen testing fits into your ISMS.
What ISO 27001:2022 Actually Says
There are two Annex A controls that bear directly on this topic.
Control 8.8 — Management of Technical Vulnerabilities
Control 8.8 requires that “information about technical vulnerabilities of information systems in use shall be obtained in a timely manner, the organisation’s exposure to such vulnerabilities shall be evaluated and appropriate measures taken to address the associated risk.”
This is a vulnerability management requirement, not a penetration testing requirement. It requires:
- A process for obtaining timely information about vulnerabilities (monitoring vendor advisories, NVD feeds, or similar)
- Assessment of which vulnerabilities apply to your systems and what your exposure is
- A process for acting on that assessment — typically patch management
Penetration testing can contribute to vulnerability management, but it is one mechanism among many. Automated vulnerability scanning, patch management processes, configuration reviews, and threat intelligence subscriptions can all fulfil the spirit of this control without a pen test.
What ISO 27001 Actually Says About Penetration Testing
The standard does not mandate pen testing — but your risk assessment might
Control 8.34 — Protection of Information Systems During Audit Testing
Control 8.34 covers a narrower point — that audit test activities and other assurance activities involving assessment of operational systems shall be planned and agreed to minimise disruption. This control is about the safe conduct of technical testing activities, not about requiring them.
Where Independent Testing Appears
The ISO 27001 standard itself does not include explicit language requiring independent technical testing such as penetration testing. However, the guidance document ISO 27002:2022 (which provides implementation guidance for the Annex A controls) notes under Control 8.8 that “technical vulnerability assessments may be performed by, or on behalf of, the organisation by qualified internal or external personnel” and specifically acknowledges penetration testing as one mechanism for assessing technical exposure.
This means penetration testing is an example of how you might meet the intent of Control 8.8 — not a requirement in itself.
So When Do You Need a Pen Test?
The honest answer is: it depends on your risk assessment.
The standard requires you to implement controls appropriate to your risks. For some organisations, the risks associated with internet-facing systems, customer data, or high-value targets make penetration testing not just appropriate but clearly necessary. For others — particularly smaller organisations with limited public-facing infrastructure — vulnerability scanning and patch management may be proportionate and sufficient.
The key question is not “does ISO 27001 require a pen test?” but “does our risk assessment indicate that independent technical testing is an appropriate control for the risks we face?”
Factors that make penetration testing clearly appropriate:
Internet-facing applications processing sensitive data. Web applications, APIs, and customer portals that handle personal data, financial information, or business-critical transactions have a risk profile that warrants independent assessment beyond automated scanning.
Cloud and SaaS platforms. Organisations offering software or services to customers will often find that customers (and their auditors) expect evidence of independent security testing. This is a contractual and commercial driver as much as a standards requirement.
High-consequence environments. Healthcare systems, financial services, critical national infrastructure, and environments with regulatory requirements (PCI-DSS, for example) typically have explicit pen testing requirements outside of ISO 27001.
Significant infrastructure changes. Major system migrations, new application deployments, and significant architecture changes are logical trigger points for independent testing, even where annual testing is not otherwise mandated.
Types of Testing and Their Relevance
When pen testing is appropriate, it is worth understanding the different types and what each assesses.
Infrastructure penetration testing assesses the security of networks, servers, and infrastructure components. It identifies network-level vulnerabilities, misconfigurations, and exploitation paths. Relevant for organisations with significant on-premises infrastructure or complex network environments.
Web application penetration testing assesses internet-facing applications for vulnerabilities such as injection flaws, authentication weaknesses, access control failures, and misconfigurations. Relevant for any organisation with customer-facing web applications.
Internal penetration testing simulates an attacker who has already achieved a foothold inside the network — either through a phishing attack or insider threat. Assesses lateral movement capability, privilege escalation, and internal controls. Particularly valuable for understanding post-breach impact.
Cloud configuration review assesses the configuration of cloud environments (AWS, Azure, GCP) for security misconfigurations — exposed storage, overpermissive IAM roles, unencrypted data, and so on. This is often more valuable than a traditional pen test for cloud-native organisations.
Vulnerability scanning (distinct from pen testing) uses automated tools to identify known vulnerabilities in systems. Lower cost and lower depth than a pen test, but suitable as a regular baseline check and often appropriate for lower-risk environments.
Technical Vulnerability Management: The Control 8.8 Cycle
A systematic process that satisfies Control 8.8 — pen testing is one option at the Identify stage
What to Do with Pen Test Results
A penetration test produces a report. The report is not the end of the process — it is the beginning. The way you handle pen test findings is itself evidence of control effectiveness under ISO 27001.
Each finding in a pen test report should be:
Reviewed and risk-rated. Not all findings require immediate remediation. Critical and high findings typically warrant urgent action; medium and low findings may be scheduled or risk-accepted where remediation cost is disproportionate to impact.
Logged in your risk register or corrective action register. Findings that reveal previously unidentified risks should be reflected in your risk assessment. Findings that confirm known risks provide evidence for your existing treatment decisions.
Assigned to an owner with a remediation target date. Findings with no owner and no timeline will not get fixed. The ISMS lead should track open findings in the same way as other corrective actions.
Retested where appropriate. For critical or high findings, a retest or verification check after remediation confirms the fix is effective. A pen test report showing critical findings with a retest confirming closure is strong evidence of effective vulnerability management.
Retained as documented information. Pen test reports, remediation logs, and retest results are records under Clause 7.5.3. They provide the audit trail that your vulnerability management process is operating as intended.
Frequency: How Often Is Enough?
Annual penetration testing is a widely used benchmark, but it is not a standard requirement. The appropriate frequency depends on your risk profile and the rate of change in your environment.
For most organisations, an annual test of key internet-facing systems is a reasonable starting point. But consider whether your environment warrants more frequent testing — particularly if you release new application features regularly, if you operate in a high-threat sector, or if your customer contracts specify a testing frequency.
Equally, consider whether an annual test of systems that rarely change is genuinely adding value, or whether the same budget would be better spent on continuous vulnerability scanning and addressing the findings that generates.
What Auditors Look For
When reviewing your approach to technical vulnerability management, ISO 27001 auditors are assessing whether you have a systematic process — not whether you have a pen test report.
A defined vulnerability management process. How do you learn about new vulnerabilities? How do you assess which ones apply to your systems? How do you prioritise remediation? This process should be documented and operating.
Evidence of regular patching. Patch management records, update logs, or similar evidence that known vulnerabilities are being addressed in a timely manner.
A risk-based approach to testing. If you conduct pen testing, evidence that the scope, frequency, and type of testing is informed by your risk assessment and the nature of your systems.
Findings are tracked and managed. Whether from pen tests, vulnerability scans, or internal reviews — findings should be tracked through to closure, not reported and forgotten.
No orphaned findings. An auditor who sees a pen test report with critical findings from two years ago and no evidence of remediation or risk acceptance has found a gap.
Common Mistakes
Treating pen testing as a one-time certification activity. Buying a pen test to achieve certification and not building a sustainable vulnerability management process misses the point of Control 8.8 entirely. The control requires ongoing management, not a single point-in-time assessment.
Confusing the test with the remedy. The value of a pen test is in what you do with the findings. An organisation that files its pen test report without actioning the findings has spent money and gained no security improvement.
Scoping tests too narrowly. Pen tests scoped to a single application often miss the infrastructure and configuration issues that represent the most exploitable attack surface. Ensure the test scope reflects your actual risk exposure.
Using the pen test as a substitute for basic hygiene. Penetration testing reveals exploitable vulnerabilities; it does not fix them. Patch management, access control, and configuration hardening are the controls that reduce your attack surface — the pen test measures how well those controls are working.
FAQs
Does ISO 27001 require annual penetration testing?
No. ISO 27001:2022 does not specify a penetration testing frequency — or mandate penetration testing at all. Control 8.8 requires a systematic approach to identifying and managing technical vulnerabilities. Penetration testing is one mechanism for fulfilling this, but not the only one. The appropriate frequency and type of testing should be determined by your risk assessment.
Will I fail my ISO 27001 audit if I have no pen test?
Not automatically. If your risk assessment identifies significant internet-facing systems processing sensitive data and your treatment plan includes no form of independent technical testing, an auditor may raise a finding. But for organisations with limited internet-facing infrastructure and robust patch management and vulnerability scanning processes, the absence of a pen test may be entirely appropriate and defensible.
Who should conduct our pen test?
Testing should be conducted by qualified personnel who are independent of the systems being tested. External penetration testing firms provide independence and access to up-to-date attack techniques. Internal security teams may conduct certain assessments, but auditors will expect to understand how independence is maintained when internal staff test their own infrastructure.
How do we evidence vulnerability management without a pen test?
Through your patch management records, vulnerability scan results, configuration baseline reviews, remediation logs, and the risk assessment process that identifies technical risks and documents treatment decisions. These together constitute evidence of a functioning vulnerability management process under Control 8.8.
Do pen test reports need to be shared with the auditor?
Yes — audit reports and testing records are documented information under your ISMS. Auditors may request to review recent pen test reports and ask how findings were managed. You do not need to share the full technical detail of every finding with external parties, but the evidence that testing occurred, findings were managed, and critical issues were remediated should be available.
