PCI DSS and FedRAMP explicitly require penetration testing at least every 12 months. SOC 2, ISO 27001 and the current HIPAA Security Rule don’t name it outright, but each requires you to test and evaluate your security controls, and a penetration test report is one of the clearest pieces of evidence an auditor can review.
That difference matters when you plan an audit year. Where a framework mandates a pentest, the scope, frequency and tester qualifications are set for you. Where it doesn’t, you set them in your own policy, and the auditor holds you to what you wrote.
Penetration testing requirements at a glance
| Framework | Pentest explicitly required? | Minimum frequency | Who can perform it | Where the requirement lives |
|---|---|---|---|---|
| PCI DSS v4.0.1 | Yes | Internal and external every 12 months and after significant changes; segmentation every 12 months (every 6 months for service providers) | Qualified internal resource with organizational independence, or a qualified third party | Requirement 11.4 |
| FedRAMP | Yes | Annually, plus the initial authorization assessment | An accredited Third Party Assessment Organization (3PAO) | NIST SP 800-53 CA-8; FedRAMP Penetration Test Guidance |
| HIPAA (current rule) | No, but risk analysis and periodic evaluation are required | Not specified | Not specified | 45 CFR 164.308(a)(1)(ii)(A) and 164.308(a)(8) |
| HIPAA (proposed rule) | Yes, if finalized as proposed | At least every 12 months | Qualified personnel | Security Rule NPRM, published January 6, 2025 |
| SOC 2 | No; listed as one way to evaluate controls | Set by your own policy (annual is common) | Not specified | Trust Services Criteria CC4.1 and CC7.1 |
| ISO 27001:2022 | No; supports vulnerability management and security testing controls | Set by your ISMS risk assessment | Not specified | Annex A 8.8, 8.29 and 5.35; Clause 9.1 |
What are the PCI DSS penetration testing requirements?
PCI DSS v4.0.1 Requirement 11.4 requires internal and external penetration testing at least once every 12 months and after any significant infrastructure or application change. It is the most prescriptive pentest requirement of the five frameworks here.
The sub-requirements break down like this:
- 11.4.1 – Methodology. You need a defined, documented methodology based on industry-accepted approaches. It must cover the entire cardholder data environment (CDE) perimeter and critical systems, test from inside and outside the network, include application-layer and network-layer testing, and validate segmentation controls.
- 11.4.2 – Internal testing. At least every 12 months and after significant changes, performed by a qualified internal resource or a qualified external third party. The tester must have organizational independence; they don’t need to be a QSA or ASV.
- 11.4.3 – External testing. The same frequency and independence rules, applied from outside the network.
- 11.4.4 – Remediation. Exploitable vulnerabilities and security weaknesses found during testing must be corrected according to your risk ranking, then retested to confirm the fix.
- 11.4.5 – Segmentation testing. If you use segmentation to reduce PCI scope, test those controls at least every 12 months and after changes to them.
- 11.4.6 – Service providers. Segmentation testing moves to at least every 6 months.
- 11.4.7 – Multi-tenant service providers. You must support your customers’ external penetration testing.
The methodology also requires you to keep penetration test results and remediation records for at least 12 months.
A common audit gap: a vulnerability scan is not a penetration test under PCI DSS. Quarterly internal and external scans fall under Requirement 11.3. They sit alongside the annual pentest; they don’t replace it.
The PCI Security Standards Council’s Penetration Testing Guidance information supplement explains scoping, tester qualifications and reporting in more depth. It is worth reading before you write your methodology.
Does HIPAA require penetration testing?
Not explicitly, under the HIPAA Security Rule in force today. It does require two things a penetration test directly supports: a risk analysis and a periodic evaluation of your safeguards.
- Risk analysis – 45 CFR 164.308(a)(1)(ii)(A). Covered entities and business associates must conduct an accurate and thorough assessment of the potential risks and vulnerabilities to electronic protected health information (ePHI).
- Evaluation – 45 CFR 164.308(a)(8). You must periodically perform a technical and nontechnical evaluation of how well your security policies and procedures meet the rule.
HHS’s Guidance on Risk Analysis doesn’t prescribe a method, so the rule never names pentesting. In practice, a pentest is how you show that the vulnerabilities in your risk analysis were tested, not just listed. It shows which weaknesses an attacker could actually use to reach ePHI.
What would change under the proposed HIPAA Security Rule?
HHS published a proposed overhaul of the Security Rule on January 6, 2025. As proposed, it would require penetration testing at least every 12 months and vulnerability scanning at least every 6 months (HHS fact sheet). The rule is not final. HHS has pushed its target for final action to July 2027 (Fierce Healthcare).
Until a final rule is published, the current rule applies. Healthcare organizations that already test annually will have far less to change if the requirement lands as proposed.
Is penetration testing required for SOC 2?
No. The AICPA Trust Services Criteria don’t mandate a penetration test. They do expect you to evaluate whether your controls are present and working, and penetration testing is named as one way to do that.
- CC4.1 – Monitoring activities. The organization selects, develops and performs ongoing or separate evaluations of its internal controls. The points of focus for CC4.1 list penetration testing among the types of separate evaluations.
- CC7.1 – System operations. The organization uses detection and monitoring procedures to identify configuration changes that introduce new vulnerabilities and susceptibilities to newly discovered vulnerabilities.
What this means for your audit:
- Your policy sets the bar. If your security policy says you pentest annually, your auditor will test against that.
- Timing matters for Type II. A Type II report covers how controls operated over a period, often 6 to 12 months. A pentest dated inside that window, with remediation tickets that follow it, is stronger evidence than one from before the period started.
- Customers ask for it anyway. Many enterprise security questionnaires request a recent third-party pentest summary alongside the SOC 2 report.
Does ISO 27001 require penetration testing?
No. ISO/IEC 27001:2022 never uses the words “penetration test.” It is risk-based: your risk assessment and Statement of Applicability decide which controls you implement and how you prove they work. Several controls are hard to evidence without a pentest:
| Control | What it asks for | How a pentest supports it |
|---|---|---|
| Annex A 8.8 – Management of technical vulnerabilities | Obtain information about technical vulnerabilities, evaluate your exposure and take action | Confirms which vulnerabilities are exploitable in your environment, not just present |
| Annex A 8.29 – Security testing in development and acceptance | Define and carry out security testing during development | Application pentests before release or after major changes |
| Annex A 5.35 – Independent review of information security | Review your approach to information security independently at planned intervals | A third-party test gives an outside view of whether controls hold |
| Clause 9.1 – Monitoring, measurement, analysis and evaluation | Determine what to monitor and measure, and evaluate effectiveness | Repeat tests give comparable results year over year |
Certification bodies look for consistency. If your risk treatment plan says you pentest critical systems annually, expect the auditor to ask for this year’s report and proof that findings were treated.
The transition period from ISO 27001:2013 ended on October 31, 2025. Valid certificates are now issued against the 2022 version and its Annex A numbering.
What are the FedRAMP penetration testing requirements?
FedRAMP requires an annual penetration test for every Rev. 5 baseline: High, Moderate, Low and LI-SaaS (FedRAMP). The requirement comes from NIST SP 800-53 control CA-8, and the test must be performed by an accredited Third Party Assessment Organization (3PAO).
The FedRAMP Penetration Test Guidance is unusually specific. Every 3PAO test must cover six mandatory attack vectors, unless the Authorizing Official approves a deviation:
- External to corporate – for example, a phishing campaign against the cloud service provider’s staff.
- External to CSP target system – an outside attacker going after the cloud service itself.
- Tenant to CSP management system – a customer account trying to reach the provider’s management plane.
- Tenant to tenant – one customer trying to reach another customer’s data.
- Mobile application to target system – where the service offers a mobile app.
- Client-side application and/or agents to target system – where customers install software or agents.
The guidance also sets the rules of engagement and the report structure. Results feed the Security Assessment Report (SAR) that agencies use to make authorization decisions.
FedRAMP is in transition. The FedRAMP 20x path replaces control narratives with Key Security Indicators, and the 2026 Consolidated Rules become mandatory for both 20x and Rev. 5 providers on January 1, 2027 (Secureframe). Neither path makes penetration testing optional. Confirm the current testing expectations for your path with your 3PAO before you scope.
How can compliance officers use penetration testing for audits?
Treat the pentest as audit evidence from the start: scope it to your compliance boundary, time it to your audit window, and require a report an assessor can map to specific controls. These seven steps cover all five frameworks.
- Map the scope to each framework’s boundary. That means the CDE for PCI DSS, systems that store or process ePHI for HIPAA, the system description for SOC 2, the ISMS scope for ISO 27001 and the authorization boundary for FedRAMP.
- Test once, map many, where you can. One well-scoped engagement can produce evidence for SOC 2, ISO 27001 and HIPAA together. PCI segmentation testing and the FedRAMP 3PAO assessment have their own rules, so plan those separately.
- Time it to the audit. Land the test inside the SOC 2 Type II period, within 12 months of the last PCI DSS test, and on the cadence your ISO risk treatment plan promises.
- Specify the report before testing starts. Auditors look for scope, dates, methodology, tester qualifications and independence, risk-rated findings and remediation guidance.
- Track remediation to closure. Log every finding in your ticketing system with an owner and due date. PCI DSS 11.4.4 requires corrected findings to be retested; other frameworks reward the same discipline.
- Retest and keep the record. Save the retest results with the original report. PCI DSS requires 12 months of retention, and prior years’ reports let you show improvement.
- Retest after significant change. A new application, a cloud migration or a major network redesign can put last year’s results out of date. PCI DSS requires testing after significant changes; for the other frameworks, it keeps your risk analysis honest.
What should a compliance-ready pentest report include?
- Scope statement listing in-scope systems, IP ranges and applications, and what was excluded
- Testing dates and the methodology followed
- Tester names or credentials, and a statement of independence
- Findings with risk ratings, evidence and affected assets
- Remediation guidance for each finding
- Retest results showing which findings were closed
- An executive summary non-technical stakeholders can read
Frequently asked questions
What is the role of penetration testing in regulatory compliance?
Penetration testing shows that security controls work under real attack conditions, not just on paper. PCI DSS and FedRAMP require it outright. HIPAA, SOC 2 and ISO 27001 require you to assess risk and evaluate controls, and a pentest report is direct evidence for both.
How can penetration testing help with compliance?
It finds exploitable weaknesses before an auditor or attacker does, gives you documented evidence for control testing, and produces a remediation record that shows due diligence. One well-scoped test can support several frameworks at once.
I’m a compliance officer. How do I use pen testing for audits?
Scope the test to your compliance boundary, schedule it inside your audit window, and agree the report format in advance. Then track every finding to closure, retest, and keep the original report and retest results together for your auditor.
Does HIPAA require annual penetration testing?
Not under the current Security Rule. The rule proposed on January 6, 2025 would require it at least every 12 months, but it has not been finalized. Today, pentesting supports the required risk analysis and periodic evaluation.
Is penetration testing required for SOC 2?
No. The Trust Services Criteria list it as one way to evaluate controls under CC4.1. If your own policy commits to annual testing, your auditor will expect to see it.
Is a vulnerability scan the same as a penetration test for compliance?
No. A scan identifies known vulnerabilities automatically. A penetration test has a skilled tester try to exploit weaknesses and chain them together. PCI DSS requires both: quarterly scans under Requirement 11.3 and annual pentests under Requirement 11.4.
Can one penetration test satisfy multiple frameworks?
Often, yes, for SOC 2, ISO 27001 and HIPAA, as long as the scope covers each framework’s boundary. PCI DSS has specific methodology, segmentation and retest rules, and FedRAMP requires an accredited 3PAO, so confirm those are covered before you rely on one test.
How often should you run a penetration test for compliance?
At least every 12 months, and after significant changes. That meets the PCI DSS and FedRAMP minimums and matches the proposed HIPAA rule. For SOC 2 and ISO 27001, write the frequency into your policy and stick to it.
Need a penetration test scoped to your next audit? Talk to Canary Trap →
