PCI DSS is the only major framework that names penetration testing explicitly (requirement 11.4). SOC 2, ISO 27001, HIPAA and GDPR don't name it but expect it as the standard evidence for their risk-assessment and technical-testing obligations — auditors treat it as effectively required. CMMC and FedRAMP fold it into assessment activity at higher levels. GCC regulators — CBB, NCA, SAMA — mandate or expect periodic testing. The near-universal cadence is at least annually and after significant change. One well-scoped, framework-mapped test can usually satisfy several at once.
// 01 The master comparison
Each row is the honest position: whether the framework names a penetration test, or merely expects one as evidence, plus the cadence and where to read the detail.
| Framework | Requirement | Cadence | Detail |
|---|---|---|---|
| PCI DSS v4.0 | Explicit (11.4) | 12 months + change; segmentation 6 months (service providers) | Req. 11.4.1–11.4.7 |
| SOC 2 | Expected evidence | Annual (norm) | CC4.1, CC7.1 |
| ISO 27001 | Expected evidence | Risk-based / annual | Annex A 8.8, 8.29 |
| HIPAA | Expected (evaluation) | Periodic / on change | Security Rule §164.308(a)(8) |
| GDPR | Expected (Art. 32) | Risk-based | "Regularly testing" security |
| CMMC | Assessment-driven | Per assessment cycle | NIST 800-171 CA controls |
| FedRAMP | Required | Annual | Rev 5 pentest guidance |
| NIST | Recommended | Risk-based | CA-8, SP 800-115 |
// 02 GCC regulators
The GCC layer sits on top of the global frameworks — and for regulated entities it is often the binding one.
| Regulator | Requirement | Detail |
|---|---|---|
| CBB (Bahrain) | Periodic penetration testing for licensees | Twice-yearly reporting cycles |
| NCA ECC (Saudi Arabia) | Penetration testing (control 2-11), periodically | CSCC adds 6-month interval |
| SAMA CSF (Saudi Arabia) | Penetration testing; red teaming at higher maturity | Maturity-level driven |
| UAE IA / NESA | Security testing for critical entities | Plus ADHICS, DESC sector rules |
| Qatar / Kuwait / Oman | Central-bank & national frameworks | See per-country guides |
// 03 "Explicit" vs "expected" — why it matters
The single most useful distinction here is between a framework that names penetration testing and one that merely expects it. PCI DSS names it: requirement 11.4 spells out internal and external testing, timing, and segmentation testing, so there is no ambiguity. SOC 2 and ISO 27001 don't name it — but their risk-assessment and technical-vulnerability requirements are, in practice, satisfied with a penetration test, and an auditor who sees only automated scan output will push back. Treating "expected" as "optional" is the mistake that stalls audits. If a framework expects genuine testing as evidence, a scan will not do.
// 04 The shared cadence: annually and on change
Whatever the framework, the timing converges on one rule: test at least every 12 months and after any significant change. PCI DSS states it outright and adds a stricter six-month segmentation-testing rule for service providers. SOC 2 and ISO 27001 are risk-based but annual testing is the auditor norm. Some GCC regulators expect twice-yearly cycles for higher-risk sectors. Our guide on how often to test covers the drivers in depth — but if you are aligning to several frameworks, set your cadence to the strictest one that applies.
// 05 Can one test satisfy several frameworks?
Usually, yes — and this is where a good provider saves you real money. If the engagement is scoped to cover the systems each framework cares about, and the report maps every finding to each relevant control (CC7.1 for SOC 2, Annex A 8.8 for ISO 27001, 11.4 for PCI, and the applicable GCC control), a single annual test can serve multiple audits at once. The exceptions to watch are PCI DSS — which has a specific scope (the cardholder data environment) and its own segmentation rules — and any regulator that demands a specific methodology. Use our requirements finder to map your exact obligations, then scope one test to cover them. Our engagements ship with control-mapped reporting for exactly this reason; see our methodology.
// 06 Frequently asked questions
Which frameworks require a penetration test?
PCI DSS explicitly (11.4). SOC 2, ISO 27001, HIPAA and GDPR expect it as standard evidence for their risk-assessment and technical-testing requirements. CMMC and FedRAMP include it in assessment at higher levels. GCC regulators (CBB, NCA, SAMA) mandate or expect periodic testing.
Does SOC 2 require a penetration test?
Not as a named control, but it's the standard evidence auditors expect for CC4.1 and CC7.1, and is treated as effectively required for a credible report. Customers also ask for one during due diligence.
How often does each framework require testing?
The baseline is at least annually and after significant change. PCI DSS 11.4 is explicit and requires 6-monthly segmentation testing for service providers. SOC 2 and ISO 27001 are risk-based with annual the norm. Some GCC regulators expect twice-yearly cycles.
Can one test satisfy multiple frameworks?
Usually, if scoped to cover each framework's systems and reported with findings mapped to each control set. PCI DSS scope (the CDE) and segmentation rules may need extra coverage — confirm scope against every framework in play first.
// 07 References
- PCI SSC, PCI DSS v4.0 Requirement 11.4; AICPA SOC 2 Trust Services Criteria (CC4.1, CC7.1); ISO/IEC 27001:2022 Annex A 8.8 & 8.29.
- Framework guides: PCI DSS, SOC 2, ISO 27001, HIPAA, GDPR, CMMC, FedRAMP, NIST.
- Map your obligations with the requirements finder.