Compliance is often the primary driver for a company's first penetration test. A SOC 2 auditor asks for it. A PCI DSS assessment requires it. An enterprise customer's security questionnaire demands evidence of recent testing. But the requirements vary significantly across frameworks, and understanding exactly what each one requires helps you scope the right test, avoid unnecessary spending, and ensure your report satisfies every framework you need it to.
This guide covers the penetration testing requirements for every major compliance framework in 2026, including what each framework actually says, what auditors and assessors expect in practice, and how to structure a single engagement that covers them all.
Framework-by-framework requirements
SOC 2 (AICPA Trust Services Criteria)
SOC 2 does not explicitly use the words "penetration test" anywhere in its trust services criteria. What it does require, under CC7.1, is that organizations "use detection and monitoring procedures to identify changes to configurations that result in the introduction of new vulnerabilities" and "anomalies that are indicative of the introduction of new vulnerabilities."
In practice, nearly every SOC 2 auditor expects penetration testing as evidence of this control. The expectation is that you perform at least annual testing by an independent third party, and that critical findings are remediated and documented. Your SOC 2 report will reference your pentest results as supporting evidence for multiple common criteria, including CC6.1 (logical access), CC6.6 (external threats), and CC7.1 (detection of changes).
ISO 27001
ISO 27001:2022 addresses penetration testing through Annex A.8.8 (Management of Technical Vulnerabilities), which requires organizations to obtain information about technical vulnerabilities, evaluate exposure, and take appropriate measures. Annex A.5.36 also requires compliance with the organization's information security policies, which typically include security testing requirements.
Most certification bodies expect annual penetration testing as evidence of technical vulnerability management. The test should cover the systems within the ISMS scope, and findings should be tracked through the organization's risk treatment process.
PCI DSS v4.0
PCI DSS is the most prescriptive framework regarding penetration testing. Requirement 11.4 explicitly requires penetration testing at least annually and after any significant change to the cardholder data environment. The standard specifies that tests must cover both internal and external network penetration testing, web application testing for applications that process or protect cardholder data, and validation of network segmentation controls.
PCI DSS also specifies methodology requirements: the test must follow a recognized methodology (PTES, OWASP, NIST SP 800-115), must be performed by qualified personnel, and must test from both inside and outside the network. Service providers have additional requirements, including segmentation testing every six months.
HIPAA
HIPAA does not explicitly require penetration testing by name. The Security Rule requires covered entities and business associates to conduct a risk analysis (45 CFR 164.308(a)(1)(ii)(A)) that identifies threats to the confidentiality, integrity, and availability of electronic protected health information. HHS guidance recommends penetration testing as a component of this risk analysis.
In practice, healthcare organizations that process ePHI are expected to perform annual security testing. A pentest is not the only acceptable approach, but it is the most commonly used method and the one that auditors and regulators are most familiar with.
FedRAMP and NIST 800-53
FedRAMP requires annual penetration testing for all cloud service providers seeking authorization. The test must follow the FedRAMP Penetration Test Guidance and cover the complete system boundary. NIST 800-53 control CA-8 (Penetration Testing) requires penetration testing of information systems at a frequency defined by organizational policy.
GDPR
GDPR 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." Penetration testing is widely recognized as an appropriate method for fulfilling this requirement. Data protection authorities have referenced the absence of security testing as a factor in enforcement decisions.
The compliance comparison table
| Framework | Pentest Required? | Frequency | Scope Specifics |
|---|---|---|---|
| SOC 2 | Expected (not explicit) | Annual minimum | Systems in scope of trust services criteria |
| ISO 27001 | Expected (A.8.8) | Annual minimum | Systems within ISMS scope |
| PCI DSS v4.0 | Required (Req. 11.4) | Annual + after changes | CDE, connected systems, web apps |
| HIPAA | Recommended | Annual | Systems handling ePHI |
| FedRAMP | Required | Annual | Full system boundary |
| GDPR | Recommended (Art. 32) | Regular (not specified) | Systems processing personal data |
| HITRUST | Required | Annual | All in-scope systems |
One pentest, multiple frameworks
The good news is that a single well-scoped penetration test can satisfy the requirements of multiple compliance frameworks simultaneously. The key is ensuring the scope covers all the systems and testing areas that each applicable framework requires, and that the report maps findings to the relevant controls.
At Lorikeet Security, our pentest reports include compliance mapping that shows which findings are relevant to SOC 2, ISO 27001, PCI DSS, and HIPAA controls. This means a single engagement produces a report you can use for all your compliance needs, eliminating redundant testing and reducing your overall compliance costs.
Cost savings example: A company pursuing SOC 2 and ISO 27001 simultaneously might pay $15,000 for two separate pentests scoped to each framework. A single combined engagement with compliance mapping for both frameworks costs $10,000 to $12,000 and saves weeks of scheduling and coordination. Lorikeet Security's compliance-ready reports are designed for exactly this scenario.
What auditors actually check
Understanding what auditors look for in your pentest evidence helps you ensure the engagement produces the right artifacts.
- Independence. The test was performed by a qualified third party, not your internal team.
- Scope adequacy. The test covered the systems relevant to the compliance framework.
- Methodology. A recognized testing methodology was followed (OWASP, PTES, NIST).
- Findings management. Critical and high findings have documented remediation plans and evidence of completion.
- Recency. The test was performed within the audit period (typically the last 12 months).
- Retesting. Evidence that remediated findings were verified through retesting.
Planning your compliance-driven pentest
When scheduling a pentest for compliance purposes, time it to align with your audit cycle. Most auditors want the test performed during the audit observation period, not before it. Work with your auditor to understand their expectations and then share those with your pentest provider so the scope and report format meet the requirements.
If you are pursuing multiple frameworks, tell your pentest provider upfront. This allows them to scope the engagement to cover all applicable requirements and format the report with the appropriate compliance mappings. Doing this proactively costs nothing extra but saves significant effort after the fact.
Need a Compliance-Ready Pentest?
One engagement, one report, multiple frameworks covered. Our reports map findings to SOC 2, ISO 27001, PCI DSS, and HIPAA controls out of the box.
