“Do we need a penetration test, or do we just want one?” For regulated organisations the answer is usually the former, but the requirement is rarely as explicit as people expect. Some frameworks name penetration testing outright; others require it in effect by demanding evidence that only testing can produce. This is the framework-by-framework picture, so you know what your auditor will actually ask for.
The quick answer
| Framework | Penetration test required? | Frequency |
|---|---|---|
| PCI DSS | Yes, explicitly | Annually + after significant change |
| SOC 2 | In practice, yes | Annually (typical) |
| ISO 27001 | Effectively yes | Annually + risk-driven |
| HIPAA | Not named, expected | Annually (recommended) |
| GDPR | Effectively yes (Art. 32) | Regularly / risk-driven |
| NYDFS 500 | Yes, explicitly | Annually |
| FedRAMP | Yes, explicitly | Annually |
The pattern: the more prescriptive the framework, the more explicit the requirement. But even the “silent” ones expect testing, because they demand proof of effective controls, and a penetration test is how that proof is produced.
PCI DSS , the most explicit
If you store, process, or transmit cardholder data, PCI DSS is unambiguous. Requirement 11.4 (11.3 in prior versions) mandates penetration testing of both the external and internal network, at the application and network layers, at least annually and after any significant infrastructure or application change. If you use segmentation to reduce scope, you must also test that the segmentation actually works , a segmentation penetration test , at defined intervals.
This is the least negotiable requirement in mainstream compliance. There is no “we did a scan instead.” A QSA will ask for the report. Our PCI DSS penetration testing page covers exactly what the assessment must include.
SOC 2 , required in practice, not by name
SOC 2 is principle-based. It does not contain a line reading “you must run a penetration test.” Instead it asks you to demonstrate that the controls protecting the Trust Services Criteria , especially Security , are designed well and operating effectively.
In practice, auditors treat penetration testing as the standard evidence for this. A Type II report covers a period of operating effectiveness, and an independent test is how you show the controls held up. Ask ten SOC 2 auditors whether they expect to see a penetration test and ten will say yes. Skipping it invites a qualification or a finding. See SOC 2 penetration testing for what the report needs to contain, and our deeper post on SOC 2 pentest requirements.
ISO 27001 , effectively required through the evidence it demands
ISO 27001 does not use the phrase “penetration testing” as a mandatory control either, but two things make it effectively required. Annex A 8.8 (technical vulnerability management) requires you to identify and address technical vulnerabilities , and Clause 9 requires you to evaluate whether your controls are effective. Testing is the accepted way to evidence both, and certification auditors expect it as part of a mature ISMS.
ISO 27001 is also the framework where testing is easiest to win a ranking on and cheapest to satisfy relative to its value , the requirement is clear once you read past the absence of the literal phrase. Our ISO 27001 penetration testing page maps findings to the specific clauses your auditor examines.
HIPAA , not named, universally expected
The HIPAA Security Rule requires a risk analysis and a periodic technical evaluation of safeguards protecting electronic protected health information. It never says “penetration test.” But a risk analysis built on assumptions is an opinion, and one built on tested evidence is defensible documentation , which is why auditors, cyber insurers, and enterprise partners increasingly expect testing. If you are pursuing HITRUST, it becomes explicit. See HIPAA penetration testing and our healthcare penetration testing guide.
GDPR , required in effect by Article 32
GDPR’s Article 32 requires “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.” That is a testing requirement in all but name , if you process the personal data of EU residents, you are expected to regularly test the measures protecting it. GDPR penetration testing covers how testing satisfies Article 32.
NYDFS 500 and FedRAMP , explicit
NYDFS 23 NYCRR 500, covering financial-services firms operating in New York, explicitly requires annual penetration testing (alongside biannual vulnerability assessments) unless you can justify an alternative through continuous monitoring. We cover the specifics in our NYDFS 500 guide. FedRAMP, for cloud services sold to the US federal government, explicitly requires annual penetration testing against a defined attack model.
The honest summary
Almost every serious compliance framework requires penetration testing , the only real variation is whether it says so outright or requires it through the evidence it demands. If you are pursuing any of the above, budget for an annual test as a baseline, plus a retest after significant change. The organisations that treat this as a genuine security exercise rather than a box to tick get two things at once: the compliance evidence, and an actually more secure environment.
One practical note: a single well-scoped test can often produce evidence for multiple frameworks at once. If you hold SOC 2 and are pursuing ISO 27001, the same engagement, reported against both, frequently satisfies both. That is worth raising during scoping , it can halve your testing overhead.
Not sure which framework’s requirements apply to you, or how to scope one test to cover several? Tell us what you’re pursuing and we will map the engagement to the exact evidence your auditors need. Our full compliance testing overview covers each framework in detail.
Written by
Invadel Team
Senior penetration testers writing from real engagements — the same team that scopes, tests, and reports for our clients. About Invadel →