Penetration testing for compliance means running a test that satisfies a specific framework’s wording, not just finding bugs. Only a few frameworks name a pentest outright with a fixed cadence (PCI DSS, CMMC Level 3, FedRAMP, NYDFS Part 500 and DORA’s threat-led testing). Others, including SOC 2, ISO 27001, HIPAA and GDPR, require you to test or evaluate your controls without saying “penetration test,” yet auditors routinely expect one as evidence.
This guide covers what each framework actually says, how often you need to test, how to scope a compliance penetration testing engagement, and what an auditor wants to see in the report. Where a requirement is genuinely ambiguous, we say so. If you are new to the topic, start with our explainer on what penetration testing is.
Penetration Testing Requirements By Framework At A Glance
The table below summarizes the position as of October 2026. “Explicit” means the framework text itself names penetration testing. “Implied” means the framework requires control testing or vulnerability management and a pentest is the usual way to evidence it.
|
Framework
|
Is A Pentest Required?
|
Frequency
|
Notes
|
|
PCI DSS v4.0.1
|
Yes, explicit (Requirement 11.4)
|
Internal and external at least every 12 months and after significant change; segmentation every 12 months (every 6 months for service providers)
|
Tester must be qualified and organizationally independent; does not have to be a QSA or ASV
|
|
SOC 2
|
Not mandated
|
Not specified; annual is the market norm
|
CC4.1 points of focus list penetration testing as one type of evaluation; most auditors and customers expect a recent test
|
|
HIPAA Security Rule (current)
|
Not explicit
|
Not specified
|
Risk analysis and periodic evaluation are required; a pentest is a common way to support both
|
|
HIPAA Security Rule (proposed)
|
Would be explicit
|
At least every 12 months, plus vulnerability scans at least every 6 months
|
January 2025 proposal; not final as of October 2026, final action now targeted for July 2027 at the earliest
|
|
ISO 27001:2022
|
Not mandated
|
Not specified; set by your own risk assessment
|
ISO 27002 guidance for Annex A 8.8 lists planned, documented, repeatable penetration testing as a way to find vulnerabilities; 8.29 covers security testing in development
|
|
DORA (EU financial entities)
|
Yes for in-scope entities
|
Tests of systems supporting critical functions at least yearly; TLPT at least every 3 years for designated entities
|
TLPT follows TIBER-EU style methodology; detailed rules in Delegated Regulation (EU) 2025/1190
|
|
GDPR Article 32
|
Not explicit
|
“Regularly”
|
Requires a process for regularly testing the effectiveness of security measures; a pentest is common supporting evidence
|
|
CMMC Level 3
|
Yes, explicit (CA.L3-3.12.1e)
|
At least annually or after significant security changes
|
Applies to Level 3 only; Level 1 and Level 2 do not include this requirement
|
|
FedRAMP
|
Yes, explicit
|
Initial test by a 3PAO, then at least every 12 months
|
FedRAMP guidance defines six mandatory attack vectors
|
|
NYDFS 23 NYCRR 500
|
Yes, explicit (500.5)
|
At least annually
|
Testing from inside and outside system boundaries by a qualified internal or external party
|
PCI Penetration Testing: Requirement 11.4
PCI DSS is the most prescriptive framework on this list. PCI penetration testing lives in Requirement 11.4 of PCI DSS v4.0.1, the current version of the standard. It breaks into seven sub-requirements:
- 11.4.1: a documented methodology based on industry-accepted approaches, covering the whole cardholder data environment (CDE) perimeter and critical systems, testing from inside and outside the network, validating segmentation, and keeping results for at least 12 months.
- 11.4.2 and 11.4.3: internal and external penetration tests at least once every 12 months and after any significant infrastructure or application upgrade or change.
- 11.4.4: exploitable vulnerabilities are corrected according to your risk ranking, and the test is repeated to verify the fixes.
- 11.4.5: if you use segmentation to shrink PCI scope, test those controls at least every 12 months and after any change to them.
- 11.4.6: service providers must run segmentation tests at least every six months and after changes.
- 11.4.7: multi-tenant service providers must support their customers’ external penetration testing. This was a best practice until 31 March 2025 and is now required.
Two details trip people up. First, the tester must be qualified and organizationally independent of the systems being tested, but does not need to be a QSA or ASV. An internal team can do it if it sits outside the group that runs the CDE. Second, an ASV quarterly scan (Requirement 11.3.2) is not a penetration test and will not satisfy 11.4. Our comparison of vulnerability scanning vs penetration testing explains the difference.
Which parts apply also depends on how you validate. Merchants filing certain Self-Assessment Questionnaires may have a reduced set of 11.4 requirements, while entities completing a Report on Compliance get the full set. Confirm the applicable requirements with your QSA or acquirer before scoping. The source text is the PCI SSC document library, which also hosts the Council’s penetration testing guidance supplement.
SOC 2 Penetration Testing: Expected, Not Mandated
The AICPA Trust Services Criteria do not require a penetration test. SOC 2 is a principles-based attestation: you define controls, and the auditor tests whether they are designed and operating effectively. No criterion says “perform a pentest.”
The criteria do point toward one. The points of focus under CC4.1 (monitoring activities) describe management using different types of ongoing and separate evaluations, and penetration testing is named as one example. CC7.1 (system operations) covers detecting new vulnerabilities and configuration changes, with vulnerability scanning as a point of focus. Points of focus are illustrative rather than mandatory, which is why the honest answer to “is SOC 2 penetration testing required?” is no, but most firms do it anyway.
In practice the pressure comes from two directions. Many auditors treat an annual third-party test as the expected evidence for CC4.1 and CC7.1, and will ask how you validate controls if you do not have one. Enterprise customers often ask for the pentest summary letter alongside the SOC 2 report during security reviews. If your control description says you perform an annual pentest, the auditor will test that control, so only write it in if you will actually do it. The AICPA Trust Services Criteria with revised points of focus are the primary source.
HIPAA Penetration Testing: Today And Under The Proposed Rule
What The Current Security Rule Requires
The HIPAA Security Rule in force today does not use the words “penetration test.” It requires covered entities and business associates to conduct an accurate and thorough risk analysis (45 CFR 164.308(a)(1)(ii)(A)) and to perform periodic technical and nontechnical evaluations of their safeguards (164.308(a)(8)). HIPAA penetration testing is a common and defensible way to support both, especially for systems that store or transmit electronic protected health information (ePHI), but it is not a stated requirement.
The 2025 Proposed Rule And Its Status
On 6 January 2025, HHS published a notice of proposed rulemaking to strengthen the Security Rule. Among many changes, it would require vulnerability scans at least every six months and penetration testing at least every 12 months. The comment period closed on 7 March 2025.
As of October 2026, there is no final rule. The federal regulatory agenda had targeted final action for May 2026, then moved the rulemaking to its long-term actions list with a target of July 2027. Target dates have slipped before, and a final rule could change the proposed requirements or drop them. Treat the annual pentest as a likely direction, not current law. The proposal is published in the Federal Register.
For most healthcare organizations the practical advice is the same either way: an annual test of ePHI systems strengthens your risk analysis today and positions you for the rule if it lands.
ISO 27001 Penetration Testing: Annex A 8.8 And 8.29
ISO 27001:2022 does not mandate a penetration test. Annex A controls are selected through your risk assessment and justified in your Statement of Applicability, and none of them says “pentest annually.”
Two controls are where ISO 27001 penetration testing usually lands. Annex A 8.8 (management of technical vulnerabilities) requires you to obtain information about vulnerabilities, evaluate your exposure and act on it; the ISO 27002 implementation guidance lists penetration testing or vulnerability assessment that is planned, documented and repeatable, carried out by competent and authorized testers. Annex A 8.29 (security testing in development and acceptance) requires security testing to be defined and carried out as part of development, which is where application and pre-release tests fit.
Certification auditors will usually ask how you know your technical controls work. A recent pentest with tracked remediation is the clearest answer. The frequency is yours to set, but you need to justify it, and annual testing plus testing after major changes is the common baseline.
DORA, GDPR, CMMC, FedRAMP And NYDFS
DORA: Yearly Testing And Threat-Led Penetration Testing
The EU Digital Operational Resilience Act has applied to banks, insurers, investment firms and other financial entities since 17 January 2025. Articles 24 and 25 require a testing program that can include vulnerability scans, source code reviews, scenario-based tests and penetration tests, with systems supporting critical or important functions tested at least yearly.
Article 26 adds threat-led penetration testing (TLPT) for entities that national authorities designate based on size and systemic importance. TLPT is an intelligence-led red team exercise against live production systems, run at least every three years and modeled on the TIBER-EU framework. The detailed rules sit in Commission Delegated Regulation (EU) 2025/1190, which entered into force in July 2025. TLPT is closer to red teaming than to a standard pentest; see red teaming vs penetration testing for the distinction.
GDPR Article 32
Article 32(1)(d) of the GDPR requires, where appropriate, a process for regularly testing, assessing and evaluating the effectiveness of technical and organizational security measures. It names no specific test and no interval. A pentest of systems that process personal data is a common way to show you meet this duty, and it is useful evidence if a regulator ever asks how you assessed your security after a breach.
CMMC
For US defense contractors, the pentest requirement only appears at CMMC Level 3. Requirement CA.L3-3.12.1e, drawn from NIST SP 800-172 and codified in 32 CFR 170.14, calls for penetration testing at least annually or when significant security changes are made, using automated scanning tools and ad hoc tests by subject matter experts. Level 1 and Level 2 do not include it. Under the phased rollout, Level 3 requirements start appearing in contracts at award from 10 November 2027, and Level 3 assessments are performed by the DoD.
FedRAMP
FedRAMP requires a penetration test as part of the initial security assessment, performed by a third-party assessment organization (3PAO) no more than six months before the security assessment report is submitted, and then at least every 12 months during continuous monitoring. The FedRAMP penetration test guidance defines six mandatory attack vectors, including tenant-to-tenant and tenant-to-management-plane testing, plus social engineering of the provider’s administrators. FedRAMP has been reworking its processes, so check the current guidance with your 3PAO before scoping.
NYDFS Part 500
Financial services companies regulated by the New York Department of Financial Services must, under 23 NYCRR 500.5, have a qualified internal or external party run penetration testing from both inside and outside their information system boundaries at least annually.
How To Scope A Compliance Penetration Test
Scope is where most compliance tests succeed or fail. A test that covers the wrong systems produces a clean report the auditor cannot use.
Start From The Framework’s Boundary
Each framework defines what is in scope differently. For PCI DSS it is the CDE plus any connected or security-impacting systems. For SOC 2 it is the system described in your system description. For HIPAA it is anything that creates, receives, maintains or transmits ePHI. For ISO 27001 it is your ISMS scope statement. For FedRAMP it is the authorization boundary. Hand the tester the relevant document, not a list of IPs you picked.
Cover The Test Types The Framework Expects
PCI DSS needs both internal and external network testing, application-layer testing, and segmentation validation if you rely on segmentation. NYDFS needs inside and outside testing. FedRAMP needs its six attack vectors. For SOC 2 and ISO 27001, test the external perimeter and the customer-facing application at minimum, since that is where auditors and customers focus. Our guide to internal vs external penetration testing covers when each matters.
Combine Frameworks Where You Can
If you hold SOC 2 and ISO 27001 and also process cards, one well-scoped annual test can often serve all three, as long as it meets the strictest requirement (usually PCI DSS) and the report maps findings to each framework. Ask the vendor to confirm this in the statement of work, and confirm with each auditor that a shared report is acceptable.
Plan For The Retest
PCI DSS 11.4.4 requires retesting to confirm fixes, and other auditors want proof that findings were closed. Budget for a retest window in the original contract. Pricing varies with scope, test types and retest terms; our penetration testing cost guide breaks down typical ranges.
What Auditors Want To See In The Report
Auditors are not reading the report to judge your security. They are checking that the test meets the control. Make their job easy by making sure the report includes:
- Dates and scope: when testing happened and exactly which systems, applications and network ranges were in scope, matching your compliance boundary.
- Tester identity and independence: who performed the work, their qualifications, and their independence from the systems tested. PCI DSS assessors check this explicitly.
- Methodology: the approach followed (for example NIST SP 800-115, OWASP testing guides or PTES), and for PCI DSS, alignment with your documented 11.4.1 methodology.
- Findings with severity and evidence: each issue rated, reproducible and tied to an affected asset.
- Remediation and retest results: what was fixed, when, and confirmation from the tester that the fix holds.
- Segmentation results: for PCI DSS, a clear statement on whether segmentation controls isolate the CDE.
- An attestation or summary letter: a short, shareable document for customers, separate from the full technical report.
Keep the full report and remediation records for at least 12 months (PCI DSS requires this) and ideally through your next audit cycle. For a section-by-section breakdown, see our guide to the penetration testing report.
Avoiding The Checkbox Pentest
The biggest risk in compliance penetration testing is paying for a report that passes the audit and tells you nothing. Common signs of a checkbox test include a rebranded vulnerability scan with no manual exploitation, a scope narrowed to make results look clean, a fixed price that does not change regardless of the size of your environment, and a report delivered without any conversation about attack paths.
Auditors are getting better at spotting these, particularly PCI assessors, who must confirm the test followed a real methodology. A scan dressed up as a pentest can also leave you exposed after a breach, when regulators ask what your testing actually covered.
[EXPERT QUOTE: White Knight Labs, John Stigerwalt, on the difference between a checkbox compliance pentest and one that finds real attack paths]
To get value beyond the audit, ask vendors:
- What share of the engagement is manual testing, and who will do it?
- Can you share a sanitized sample report, including a compliance mapping section?
- Have you tested against this framework before, and will your report satisfy our auditor or QSA?
- Is retesting included, and within what window?
- Will you chain findings into attack paths, or only list them individually?
- What certifications do the testers on our engagement hold? Our list of penetration testing certifications explains what each one signals.
Testing more often than the minimum also helps. Many teams pair an annual compliance test with continuous or on-demand testing between audits; our comparison of PTaaS vs traditional penetration testing covers that model.
Frequently Asked Questions
Is A Penetration Test Required For SOC 2?
No. The Trust Services Criteria do not mandate one, though the CC4.1 points of focus name penetration testing as one type of evaluation. Most auditors and enterprise customers expect an annual third-party test, so in practice most SOC 2 companies run one.
How Often Is PCI Penetration Testing Required?
Internal and external tests at least every 12 months and after significant changes. Segmentation testing is required every 12 months for merchants and every six months for service providers, plus after any segmentation change.
Does HIPAA Require Annual Penetration Testing?
Not under the current Security Rule. The rule HHS proposed in January 2025 would require annual pentests, but as of October 2026 it has not been finalized and final action is targeted for July 2027 at the earliest.
Can One Pentest Cover Multiple Frameworks?
Often, yes. Scope it to the union of your compliance boundaries, meet the strictest framework’s requirements, and ask for a report that maps findings to each framework. Confirm with each auditor in advance.
Can Our Internal Team Perform The Compliance Pentest?
Sometimes. PCI DSS and NYDFS allow a qualified internal party if it is independent of the systems tested. FedRAMP requires a 3PAO for the assessment test, and customers reviewing SOC 2 or ISO 27001 evidence often expect a third-party report.
Conclusion
Penetration testing for compliance comes down to reading the framework closely. PCI DSS, CMMC Level 3, FedRAMP, NYDFS and DORA spell out testing requirements. SOC 2 penetration testing, ISO 27001 penetration testing and HIPAA penetration testing are expected rather than mandated, at least until the HIPAA proposal is finalized. In every case, a well-scoped annual test with documented remediation is the evidence auditors want.
When you are ready to choose a vendor, compare firms on our lists of the top penetration testing companies in 2026 and top web application penetration testing companies, or browse everything in our penetration testing hub.
