As part of the ISO 27001 certification process, auditors are increasingly asking to see a penetration test report. But where does this requirement come from if the word pentest or penetration test does not exist in the text of ISO 27001?
ISO 27001 is the international standard for setting up and operating an ISMS (Information Security Management System). Appendix A of this standard contains control objectives for implementation. A more specific explanation of the individual controls can be found in the ISO 27002 standard, which corresponds in its document structure to the control objectives of Appendix A of ISO 27001.
In Appendix A of ISO 27001, section A.18.2 now contains the requirement to carry out “information security reviews”. The ISO27002 implementation guideline for this control includes performing vulnerability scans and/or penetration testing as a solution to fullfill this requirement.
Anyone dealing with penetration testing as part of an ISO/IEC 27001:2022 certification quickly realizes one thing: the theory of the standard and the reality in the audit are often worlds apart. Because the standard does not universally mandate penetration testing but instead requires a risk-based approach, many companies find themselves navigating a regulatory gray area during their audit.
After more than a decade and hundreds of pentest projects within the context of certification, we consistently see the same patterns, misunderstandings, and misinterpretations on the auditors’ side.
Here are four unvarnished real-world insights you won’t find in any textbook.
1. The “Auditor Lottery”: Why You Must Take Control of Your Own Scoping
Auditor requirements regarding exactly what needs to be tested, how deeply, and to what extent vary massively. What Auditor A at Certification Body X waves through as “perfectly sufficient” leads to a bitter non-conformity with Auditor B at Certification Body Y.
Many auditors are highly skilled at verifying processes but hit their limits when it comes to defining technical attack surfaces.
Pro Tip: Don’t wait for the auditor to tell you what to test. As a company, establish a well-founded, written scoping argument yourself within your ISMS. If you clearly document why certain systems are in focus (based on risk!) and others are not, auditors accept this reasoning in 95% of cases.
2. The Initial Certification Myth: No Pentest in the First Year?
It is an open secret in the compliance world: during an initial certification according to ISO 27001, a surprising number of auditors do not yet demand a completed penetration test. Why? Because the initial audit primarily checks whether the processes of the ISMS have been established. It is often enough for the auditors if the risk treatment plan states that a technical security assessment is scheduled.
However, the real awakening happens one year later during the first surveillance audit. Anyone who slacks off during the first year will find themselves under massive time pressure in the second year. At the latest, proof of identifying technical vulnerabilities (Control A.8.8) will be rigidly demanded then.
3. “Scope Hopping”: Annually Rotating Pentests Are Not Best Practice
To save costs while still getting the annual checkmark in the audit report form, many companies use a trick:
- Year 1: A pure external pentest (infrastructure & perimeter).
- Year 2: A pure internal pentest (Active Directory & internal network).
- Year 3: A pentest of the primary web application.
Strategically speaking, this satisfies the demand for “regular reviews” and theoretically covers everything over the three-year certification cycle. However, this is not best practice. A critical external vulnerability does not wait two years until it is its turn again. Auditors are increasingly seeing through this “scope hopping” and are demanding real continuity for business-critical systems.
4. Tunnel Vision in Product-Manufacturing Companies
If your company develops software, SaaS platforms, or physical products, a strong tunnel vision can be observed among auditors. They almost exclusively request or demand a pentest of the software or the actual product itself (Control A.8.29).
In practice, this leads to a dangerous imbalance in risk management: the focus shifts rigidly onto the application, while the internal and external attack vectors against the company itself (corporate IT, developer workstations, phishing resilience, ransomware protection) lose all significance within the audit. Yet reality shows that most supply chain attacks do not start within the production software, but rather via compromised corporate networks of the employees.
The Conclusion
A penetration test for ISO 27001 should never be a mere alibi exercise for the audit log. Take advantage of the freedom that the risk-based approach of the standard provides to face the auditor with a well-thought-out, proactive testing concept. Those who do their homework in risk management do not lead the discussion in the audit defensively, but on an equal footing.
