Penetration testing for compliance
PCI DSS and DORA require penetration testing outright. SOC 2 and ISO 27001 auditors expect it. GDPR and HIPAA ask you to test your security regularly. Here is what each framework asks for, and how to run one test that satisfies them.
What each framework expects
A summary for planning. Always confirm the exact requirement with your auditor or assessor, because it depends on your scope and the version you are assessed against.
| Framework | Penetration test required? | What it asks for |
|---|---|---|
| PCI DSS v4 | Yes, explicitly | Internal and external penetration tests at least once a year and after significant changes (requirement 11.4), covering the cardholder data environment. Segmentation controls must be tested too, every six months for service providers. |
| SOC 2 | Expected, not named | No fixed rule, but auditors usually expect an annual penetration test as evidence that your controls work, especially for monitoring and change management. Test inside your observation period. |
| ISO/IEC 27001:2022 | Expected, not named | Annex A controls 8.8 (technical vulnerability management) and 8.29 (security testing) are commonly met with regular penetration tests, scoped by your risk assessment. |
| HIPAA | Risk-based today | The Security Rule requires a risk analysis and periodic evaluation of your safeguards. Changes proposed by HHS in 2025 would require penetration testing at least once a year. |
| GDPR | Testing required | Article 32 requires a process for regularly testing and evaluating the effectiveness of your security measures. Penetration testing is a common way to show it. |
| DORA (EU finance) | Yes, explicitly | In force since January 2025. Financial entities must test the systems behind critical functions at least once a year, and larger entities run threat-led penetration tests every three years. |
| India: RBI, SEBI, CERT-In | Yes, for regulated entities | Banks and SEBI-regulated entities must run periodic VAPT under their cybersecurity frameworks, and CERT-In requires many incidents to be reported within six hours. |
A report your auditor will accept
Auditors care less about the number of findings than about whether the test was scoped properly, done independently and followed up. We write every report to answer those questions directly.
For industry-specific guidance, read our guides to financial cybersecurity, healthcare cybersecurity and the UK PSTI Act.
What makes a test audit-ready
- A scope that matches the systems in your audit or certification boundary
- Testing dates inside your audit or observation period
- The methodology and standards named in the report
- Every finding with a severity and a fix
- Evidence of remediation, through a retest and an updated report
- Independence: testers who do not run the systems they test
Compliance questions
Which compliance frameworks require a penetration test?
PCI DSS and DORA require penetration testing explicitly. SOC 2 and ISO 27001 do not name it, but auditors widely expect it as evidence that your controls work. GDPR requires regular testing of your security measures, and HIPAA requires periodic evaluation, with proposed changes that would make annual penetration tests mandatory.
Can one penetration test cover several frameworks?
Usually, yes. A test built to the PCI DSS standard, with a clear scope, named methodology, independent testers and a retest, generally satisfies SOC 2 and ISO 27001 too, as long as the scope covers the systems each audit includes. Tell us every framework on the scoping call and we will make sure the report covers them.
How often should we test for compliance?
At least once a year, and after significant changes such as a new application, a major release or an infrastructure move. PCI DSS service providers must test segmentation every six months.
Is a vulnerability scan enough for compliance?
Usually not. Scans are required separately by some frameworks, for example quarterly scans under PCI DSS, but they do not replace a penetration test, which proves whether weaknesses can be exploited.
Start your security assessment.
Tell us about your application, architecture or compliance requirements. Our team will scope a penetration test around them.