Penetration Testing for ISO 27001: What Your Auditor Expects
Penetration testing and ISO 27001 compliance go hand in hand, even though the standard doesn’t explicitly mandate pentesting. If you’re pursuing ISO 27001 certification in Australia, your auditor will expect to see evidence that you’ve identified and assessed technical vulnerabilities across your systems. For most organisations, that means conducting penetration tests as part of your risk management process.
Understanding what your auditor is looking for, how often you should test, and what needs to be included in your scope can save you time and headaches during the certification audit. This guide explains the practical requirements for ISO 27001 penetration testing and how to satisfy your auditor without overcomplicating things.
Does ISO 27001 Require Penetration Testing?
Not explicitly. ISO 27001 doesn’t mandate penetration testing as a specific requirement. However, the standard does require you to identify, evaluate, and treat technical vulnerabilities in a timely manner. This falls under Annex A control 8.8 (Management of Technical Vulnerabilities) in the 2022 version of the standard.
Most auditors interpret this control to mean you need regular vulnerability assessments and, where appropriate, penetration testing. The difference matters. Vulnerability scanning is automated and identifies known weaknesses. Penetration testing simulates real attacks to see if those weaknesses can actually be exploited.
If you skip pentesting entirely and rely only on vulnerability scans, your auditor may question whether you’ve adequately assessed your risk exposure. They’ll want to see that you’ve gone beyond just identifying vulnerabilities to understanding whether your controls can withstand an actual attack.
Which ISO 27001 Controls Relate to Penetration Testing?
Several Annex A controls connect directly to penetration testing. The most relevant ones are:
Control 8.8: Management of Technical Vulnerabilities
This is the primary control. It requires you to obtain information about technical vulnerabilities, evaluate your exposure, and take appropriate measures to address the associated risk. Penetration testing is one of the most effective ways to demonstrate compliance with this control.
Control 8.29: Security Testing in Development and Acceptance
This control applies to systems under development or being deployed. It mandates security testing during the development lifecycle and acceptance phases. For web applications, APIs, or custom software, penetration testing validates that your code is free from critical vulnerabilities before it goes live.
Control 8.7: Protection Against Malware
While not directly about pentesting, this control relates to how well your defences hold up against exploitation attempts. A penetration test that includes social engineering or payload delivery can validate whether your malware protection is working as intended.
Your auditor will cross-reference your penetration test reports to these controls during the audit. They’ll check that you’ve scoped testing appropriately, documented findings, and treated the risks you’ve identified.
How Often Should You Conduct ISO 27001 Penetration Testing?
ISO 27001 doesn’t specify a fixed frequency, but annual penetration testing is considered best practice. Most organisations pursuing or maintaining certification conduct at least one full pentest per year, covering both external and internal infrastructure.
You should also test after significant changes. If you migrate to a new cloud provider, deploy a major application update, or restructure your network, a targeted retest makes sense. Waiting until your next annual test could leave you exposed if those changes introduced new vulnerabilities.
Some industries and regulatory frameworks require more frequent testing. If you’re in financial services (subject to APRA CPS 234) or handling health data, you may need to test quarterly or semi-annually. Your risk assessment should guide the frequency, not just what the standard technically requires.
If you’re not sure how often your organisation should be testing, a risk-based approach is the safest bet. Siege Cyber can help you determine the right testing frequency based on your environment, risk profile, and compliance obligations. Learn more at siegecyber.com.au/services/iso-27001.
What Should Be Included in Your Penetration Test Scope?
Your pentest scope should cover the systems and assets that store, process, or transmit sensitive information. At a minimum, most ISO 27001 audits expect to see:
External network and infrastructure testing
This tests your internet-facing assets: firewalls, VPNs, mail servers, web servers, and any publicly exposed services. The goal is to identify whether an attacker could gain unauthorised access from outside your network.
Internal network testing
This simulates an attacker who has already gained initial access, either through social engineering or a compromised endpoint. It tests whether lateral movement is possible and whether critical systems are adequately segmented.
Web application testing
If your organisation develops or hosts web applications, they need to be tested for common vulnerabilities like SQL injection, cross-site scripting, broken authentication, and insecure configurations. This aligns with Control 8.29.
Cloud infrastructure testing
If you’re running workloads in AWS, Azure, or Google Cloud, your pentest should include cloud-specific testing: IAM misconfigurations, exposed storage buckets, overly permissive security groups, and API vulnerabilities.
Your scope will depend on what’s in your Statement of Applicability and what you’ve identified in your risk assessment. If you’ve decided certain controls aren’t applicable, you need to justify that decision. Your auditor will check that your pentest scope reflects the risks you’ve accepted or treated.
What Does Your Auditor Expect to See in a Penetration Test Report?
A compliant penetration test report should document the following:
-
Scope: What was tested and what was excluded
-
Methodology: How the test was conducted (e.g. OWASP, NIST SP 800-115, or CREST standards)
-
Findings: Vulnerabilities identified, including severity ratings (critical, high, medium, low)
-
Evidence: Screenshots, logs, or proof-of-concept demonstrations for key findings
-
Risk assessment: The potential impact and likelihood of exploitation
-
Recommendations: Specific, actionable steps to remediate each finding
Your auditor will review this report during the Stage 2 audit. They’ll check that findings have been addressed or formally accepted as residual risk. If critical or high-severity vulnerabilities were identified, they’ll expect to see evidence of remediation or a documented risk treatment decision signed off by management.
The report also needs to be relatively recent. A pentest report from three years ago won’t satisfy your auditor. If your last test was more than 12 months ago and you haven’t had significant changes, you’re probably fine. Beyond that, you’ll likely be asked to conduct a new test before certification.
Vulnerability Scanning vs Penetration Testing for ISO 27001
Many organisations confuse vulnerability scanning with penetration testing. They’re both important, but they serve different purposes.
Vulnerability scanning is automated. It identifies known weaknesses based on signatures and version information. It’s cheap, fast, and can be run weekly or monthly. ISO 27001 doesn’t explicitly require it, but most organisations use it as part of ongoing monitoring.
Penetration testing is manual. It validates whether vulnerabilities are actually exploitable and tests the effectiveness of your defences. It’s more expensive, more disruptive, and typically done annually or after major changes.
Your auditor expects both. Vulnerability scanning provides continuous visibility. Penetration testing provides periodic validation. Together, they satisfy the spirit of control 8.8.
How Siege Cyber Helps with ISO 27001 Penetration Testing
Siege Cyber offers comprehensive penetration testing services designed specifically for Australian businesses pursuing or maintaining ISO 27001 certification. We understand what auditors expect, and we deliver reports that satisfy compliance requirements while giving you actionable insights to improve your security.
We test external networks, internal infrastructure, web applications, APIs, cloud environments, and wireless networks. Every test is scoped to align with your ISO 27001 risk assessment and Statement of Applicability. You get a detailed report that maps findings back to Annex A controls, making it easy for your auditor to verify compliance.
You can view our penetration testing services at siegecyber.com.au/services/penetration-testing and our fixed-price compliance packages at siegecyber.com.au/#compliance-pricing.
Next Steps
If you’re preparing for an ISO 27001 audit and you haven’t conducted a penetration test in the past year, now is the time. Waiting until the audit is scheduled puts you at risk of findings or delays in certification.
Siege Cyber works with businesses across Brisbane, Sydney, and throughout Australia to deliver audit-ready penetration tests that satisfy ISO 27001 requirements. We’ve helped numerous organisations achieve certification, and every single one has passed their audit on the first attempt.
Siege Cyber has been helping businesses across Australia with penetration testing, compliance, and cyber risk for over 20 years. If you’d like to discuss what type of testing makes sense for your organisation, or if you’re preparing for an ISO 27001 or SOC 2 audit and need testing as part of that process, get in touch.
You can reach us at siegecyber.com.au or email [email protected] directly. We’re based in Brisbane but work with clients across the country.