Which frameworks actually require it
Only one of the common frameworks names penetration testing as an explicit mandatory requirement. The others expect technical vulnerability management and accept a test report as the evidence.
| Framework | Explicitly required? | What the auditor wants to see | Frequency |
|---|---|---|---|
| PCI DSS | Yes, explicitly | Internal and external testing, plus segmentation testing | Annually and after significant change |
| ISO 27001 | No, but expected | Evidence under Annex A technical vulnerability management and secure testing | At least annually |
| SOC 2 | No, but expected | CC7 vulnerability identification evidence, across the observation window | Within the window |
| HIPAA | No | Evaluation of technical controls protecting ePHI | Periodic |
| CMMC / NIST 800-171 | Scanning required | Vulnerability scanning and remediation evidence | Ongoing |
The nuance that matters: "not explicitly required" does not mean optional in practice. An ISO 27001 or SOC 2 auditor asking how you manage technical vulnerabilities will accept a current test report and will keep asking questions if you do not have one.
ISO 27001
Annex A covers technical vulnerability management and security testing in development and acceptance. Neither names penetration testing, and neither has to — the auditor is assessing whether you identify and remediate technical vulnerabilities systematically.
What satisfies it: a current test report covering the systems inside your ISMS scope, evidence that findings were tracked and remediated, and a retest confirming closure. Findings that fed your risk register and treatment plan are stronger still, because it shows the process connected rather than the test sitting in isolation.
The scope trap: a test covering an application outside your declared ISMS scope does not evidence anything about the ISMS. Align the test scope to the certificate scope.
SOC 2
CC7 covers detection and monitoring of vulnerabilities. Again not prescriptive, and again a test report is the usual evidence.
The Type 2 subtlety most people miss: a Type 2 tests across an observation window. A single test conducted the week before fieldwork evidences a point in time, not the period. Auditors increasingly ask what vulnerability management looked like across the whole window — which usually means regular scanning throughout, plus the annual manual test.
That combination is the right answer anyway: scan continuously, test manually once a year, and the evidence covers the period rather than a moment.
PCI DSS
The most prescriptive. Penetration testing is explicitly required, internal and external, at least annually and after significant change. Where segmentation is used to reduce the cardholder data environment scope, segmentation testing is required too — and if segmentation fails, the scope reduction it justified disappears with it.
Methodology must be documented and industry-accepted. Testers must be organisationally independent of the systems tested, which is worth checking if you were considering using your own team.
Why a findings list is not audit evidence
This is the practical difference between buying testing from a pentest firm and from a compliance consultancy.
A findings list is a security document. It says what is wrong. Someone then has to translate it into the vocabulary of the framework, map each finding to the relevant control, and assemble the remediation trail an auditor will ask for.
A framework-mapped report with a retest letter is audit evidence. It answers the auditor's question in the auditor's language, with closure already documented.
That translation work is real, it lands on your compliance lead at the worst possible moment, and it is avoidable by asking for the mapping up front. See what a VAPT report should contain.
Sequencing testing with your audit
Test early enough to remediate. The most common mistake is scheduling the test close to the audit. Findings arrive, there is no time to fix them, and the report goes to the auditor with everything open.
Working backwards: report issued and retest complete before fieldwork, which means remediation time before that, which means testing at least eight to ten weeks ahead of the audit for a first cycle.
For a SOC 2 Type 2, earlier still, because the evidence should span the observation window rather than appear at the end of it.
FAQs
Does ISO 27001 require penetration testing?
Not by name. Annex A covers technical vulnerability management and security testing, and auditors assess whether you identify and remediate technical vulnerabilities systematically. A current test report covering your ISMS scope, with evidence of remediation and a retest, is the usual evidence and is expected in practice.
Does SOC 2 require a penetration test?
SOC 2 does not name penetration testing as a mandatory control, but CC7 covers vulnerability identification and auditors routinely accept a test report as evidence. For a Type 2 the evidence should span the observation window, so regular scanning throughout plus an annual manual test is the stronger answer than a single test before fieldwork.
Does PCI DSS require penetration testing?
Yes, explicitly — internal and external testing at least annually and after significant change, plus segmentation testing where segmentation is used to reduce cardholder data environment scope. Methodology must be documented and industry-accepted, and testers must be organisationally independent of the systems tested.
When should I schedule testing before an audit?
At least eight to ten weeks ahead for a first cycle, working backwards from the requirement that the report and retest are complete before fieldwork, with remediation time in between. For a SOC 2 Type 2, earlier still, because evidence should span the observation window rather than appear at its end.
Why is a framework-mapped report better than a findings list?
A findings list says what is wrong and leaves someone to translate it into the framework's vocabulary, map each finding to the relevant control and assemble the remediation trail. A mapped report with a retest letter answers the auditor in their own language with closure already documented, which removes work at the worst possible moment in an audit cycle.
Where to go next
See penetration testing services, ISO 27001, SOC 2, or what the report should contain.