Does ISO 27001 Require
Penetration Testing?

No — ISO 27001 never uses the words “penetration test.” What it requires is that you identify and treat technical vulnerabilities in line with your risks. In practice, penetration testing is how most certified organizations satisfy that expectation, and certification auditors routinely ask what technical testing you performed. The mechanism is indirect but binding. Clause 6.1 of the standard — part of the mandatory clauses — makes your risk assessment and risk treatment plan the engine that selects controls. Annex A control A.8.8, Management of technical vulnerabilities, then requires that information about technical vulnerabilities be obtained in a timely fashion, your exposure evaluated, and appropriate measures taken. Neither says “pentest.” Both demand that vulnerabilities get found and fixed — and the depth of testing you use to find them is a risk-based decision you must be able to defend to an auditor, in writing, with a straight face.

• A.8.8 — Management of technical vulnerabilities. Information about technical vulnerabilities of systems in use must be obtained in a timely fashion, your exposure to them evaluated, and appropriate measures taken. This is the control doing the real work: it demands identification and remediation, but it does not name a method.
• A.8.29 — Security testing in development and acceptance. Security testing processes must be defined and implemented in the development life cycle — so software you build gets tested before and as it ships, not just after it is deployed.
• A.5.35 — Independent review of information security. Your approach to managing information security must be reviewed independently at planned intervals or when significant changes occur. Independent technical testing is one recognized way to give this control teeth.
• A.8.16 — Monitoring activities. Networks, systems, and applications must be monitored for anomalous behaviour. Point-in-time testing and continuous monitoring are complements, not substitutes — auditors expect to see both ends covered.

Read together, these controls require a working pipeline: vulnerabilities discovered promptly, assessed against your exposure, fixed on a defensible timeline, and the whole approach reviewed independently. What none of them does is prescribe how deep the discovery must go. A quarterly authenticated scan and a full red-team engagement can both be “appropriate measures” — for different organizations. The depth is your call, made through the ISMS’s risk process — and because it is your call, the burden of justifying it is also yours.

• Internet-facing products. If you run a SaaS platform, public APIs, or mobile apps, "we scanned but never had anyone attempt to exploit anything" is a hard position to defend in a risk-based audit.
• Customer contractual commitments. Many enterprise contracts and security questionnaires require an annual penetration test outright. Once you have signed one, the pentest is a compliance obligation regardless of what ISO 27001 says.
• High-risk profiles. Organizations handling payment data, health records, or other regulated information will struggle to argue that automated scanning alone matches their threat exposure.
• Your own risk assessment says so. If your Clause 6.1 analysis rates external attack as a significant risk — as it almost always does for connected businesses — your treatment plan needs testing proportionate to that rating.

Notice the inversion. Under a prescriptive framework, the question is “which rule compels me to test?” Under ISO 27001, the question is “can I justify testing this little?” If the honest answer is no — and for anything internet-facing it usually is — the standard has effectively required a penetration test without ever using the words.

PCI DSS names the method. Requirement 11.4 explicitly mandates penetration testing: internal and external tests at least annually and after significant changes, performed under a defined methodology, with exploitable findings corrected and segmentation controls tested where they are relied on. If you handle payment card data, there is no risk assessment that argues you out of it.

Privacy laws name only the outcome. GDPR asks for “appropriate technical and organisational measures,” including a process for regularly testing and evaluating their effectiveness, and data-protection statutes such as the DPDP Act require “reasonable security safeguards” — with no method, cadence, or depth specified at all. What counts as appropriate gets argued about after the breach, not before it.

ISO 27001 sits in between. It is stricter than privacy law — an accredited auditor examines your vulnerability management every year and can raise nonconformities — but looser than PCI DSS, because the method remains yours to choose and defend. Outcome-required, method-flexible. That flexibility is a feature when your risk profile is genuinely modest, and no cover at all when it is not.