“Do we need a penetration test, or do we just want one?” For regulated organizations 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.
Penetration testing requirements by framework
| Framework | Penetration test required? | Frequency | Details |
|---|---|---|---|
| PCI DSS | Yes, explicitly | Annually + after significant change | PCI DSS 11.4 requirements explained |
| SOC 2 | In practice, yes | Annually (typical) | SOC 2 pentest requirements |
| ISO 27001 | Effectively yes | Annually + risk-driven | ISO 27001 penetration testing |
| HIPAA | Not named, expected | Annually (recommended) | HIPAA penetration testing requirements |
| GDPR | Effectively yes (Art. 32) | Regularly / risk-driven | GDPR penetration testing |
| NYDFS 500 | Yes, explicitly | Annually | NYDFS 23 NYCRR 500 penetration testing |
| FTC Safeguards Rule (GLBA) | Yes, explicitly, unless you run continuous monitoring | Annually, plus vulnerability assessments every six months | FTC Safeguards Rule penetration testing |
| FedRAMP | Yes, explicitly | Annually | FedRAMP penetration testing, NIST requirements |
| CMMC 2.0 | Level 2: in effect; Level 3: explicit | Each assessment cycle (3 years) | NIST 800-171 penetration testing |
| DORA (EU) | Yearly ICT testing; threat-led penetration testing for entities regulators select | Yearly; threat-led testing at least every 3 years | Fintech penetration testing |
| Cyber Essentials Plus | Not by name: an assessor-run technical audit | With each annual certificate | Cyber Essentials checklist |
| CIS Controls v8.1 | Yes, explicitly, from Implementation Group 2 (Control 18) | External tests annually from IG2; internal tests annually at IG3 | CIS Controls v8.1 explained |
| NY hospital rule (10 NYCRR 405.46) | Yes, explicitly, for New York general hospitals | At least annually | New York hospital cybersecurity regulations |
| CCPA cybersecurity audit | Named among the components the audit must assess, where applicable (11 CCR 7123(c)(6)) | No interval set; test inside each 12-month audit period | CCPA audit penetration testing |
| SEC Regulation S-P | Not named; safeguards and an incident response program must be reasonably designed | Not set | Regulation S-P penetration testing |
| CJIS Security Policy | No; it requires monthly vulnerability scans instead | Scans monthly; control assessment every 3 years | CJIS compliance checklist |
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, and the PCI DSS 11.4 requirements explained guide goes line by line.
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 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, and our ISO 27001 checklist walks through Clauses 4 to 10 and the 93 Annex A controls by theme.
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 guide to the HIPAA penetration testing requirements.
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.” (The British spelling is the regulation’s own.) 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.
Cyber Essentials Plus, a technical audit rather than a pentest
Cyber Essentials Plus, the UK scheme that public-sector and defense buyers there ask for, never requires a penetration test by name. The certification body runs a hands-on audit instead: an external vulnerability scan, authenticated scans of sampled devices, malware tests and MFA checks. We deliver Cyber Essentials Plus certification and test those same controls first, so the audit confirms what is already fixed. The Cyber Essentials checklist walks through each control.
NYDFS 500, the FTC Safeguards Rule and FedRAMP, explicit
NYDFS 23 NYCRR 500, covering financial-services firms operating in New York, explicitly requires penetration testing at least annually, from inside and outside the information systems’ boundaries, by a qualified internal or external party, plus automated scans at a frequency set by your risk assessment and after material system changes (Section 500.5). We cover the specifics in our NYDFS 500 guide, and our NYDFS 23 NYCRR 500 penetration testing page shows the evidence examiners receive.
The FTC Safeguards Rule is how GLBA reaches non-bank financial institutions such as auto dealers, mortgage brokers and tax preparers. Under 16 CFR 314.4(d)(2), unless you run effective continuous monitoring, it requires annual penetration testing and vulnerability assessments at least every six months. Institutions that hold customer information on fewer than 5,000 consumers are exempt from that paragraph (16 CFR 314.6). Our FTC Safeguards Rule penetration testing page covers who is in scope.
FedRAMP, for cloud services sold to the US federal government, explicitly requires annual penetration testing against a defined attack model. The penetration test for an initial authorization must be performed by an accredited third-party assessment organization (3PAO), and testing repeats at least every 12 months under continuous monitoring. We are not a 3PAO: we run readiness and pre-assessment penetration testing before the 3PAO arrives. See FedRAMP penetration testing.
CMMC: in effect at Level 2, explicit at Level 3
Defense contractors and subcontractors handling Controlled Unclassified Information face CMMC 2.0. Level 2 never uses the words “penetration test,” but its NIST SP 800-171 controls require periodic security assessments (CA.L2-3.12.1) and vulnerability identification and remediation (RA.L2-3.11.2 and 3.11.3), and assessors expect independent testing as the evidence behind both. At Level 3, NIST SP 800-172 makes it explicit with penetration-test-informed assessment. For most contractors the highest-value engagement is testing the CUI enclave itself, plus the segmentation that keeps the rest of the network out of assessment scope. Our CMMC Level 2 penetration testing page maps the controls and typical scope, and the CMMC Level 2 requirements checklist lists all 110 with the evidence an assessor asks for.
Frequently asked questions
Can one penetration test cover several compliance frameworks? Often, yes. A single well-scoped test can produce evidence for SOC 2 and ISO 27001 at once, and for PCI DSS or NYDFS 500 too, as long as three things hold: the scope covers every system each framework puts in scope, the test falls inside each audit period, and the report maps findings to each framework separately. Raise it at scoping. It can halve your testing overhead, and our reports map findings to SOC 2, PCI DSS, HIPAA, ISO 27001, NYDFS 500 or CMMC as needed.
How often does compliance require a penetration test? At least once a year for almost every framework on this page, plus after significant changes. PCI DSS adds six-monthly segmentation tests for service providers, and the FTC Safeguards Rule adds vulnerability assessments every six months. Our frequency table by framework has the detail.
Does a vulnerability scan count as a penetration test? No. Frameworks that name both, such as PCI DSS, NYDFS 500 and the FTC Safeguards Rule, list them as separate requirements. A scan finds known weaknesses; a penetration test shows what an attacker can do with them.
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 organizations 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.
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 →