1. Quick Reference: What Each Framework Requires
| Framework | Pentest Required? | Frequency | Third Party Required? |
|---|---|---|---|
| SOC 2 Type II | Strongly implied by auditors | Annual (aligned to audit window) | No, but strongly preferred |
| ISO 27001 | Yes - Annex A.8.8 and clause 8.8 | At least annual, after major changes | No, internal is accepted |
| PCI DSS v4.0 | Yes - explicit and specific (Req. 11.3) | Annual + after significant changes | Yes - external tester with independence |
| HIPAA | Yes - technical evaluation required | Periodic (no specific interval) | No, but third-party adds defensibility |
| GDPR | Not explicit, but implied by Article 32 | Regular - undefined interval | No |
2. SOC 2 Type II: What CC6.1, CC6.6, and CC7.1 Actually Mean
SOC 2 Type II is the most commonly required framework for US-based B2B SaaS companies. The SOC 2 standard (Trust Services Criteria framework) does not use the word "penetration test" anywhere in the criteria text. This misleads many founders into thinking SOC 2 does not require one.
In practice, the three criteria most relevant to security testing almost always generate auditor questions about whether you have conducted active testing - not just documented controls:
"The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives." Auditors want evidence that access controls have been actively tested - not just designed and implemented.
"Logical access security measures to protect against threats from sources outside its system boundaries." External-facing applications and APIs are your primary external attack surface. This criterion requires evidence they have been evaluated under adversarial conditions.
"To meet its objectives, the entity uses detection and monitoring procedures to identify changes to configurations that introduce new vulnerabilities." This criterion is satisfied more completely by penetration testing than by monitoring alone, as it requires validating that changes have not introduced new exploitable paths.
You can technically achieve SOC 2 Type II without a penetration test if you have other strong evidence for CC6 and CC7. But in practice, most auditors will note the absence of penetration testing, which generates findings that require explanation. Nearly every company that achieves SOC 2 with a clean opinion conducts annual penetration testing. It is the most reliable way to satisfy these criteria without additional scrutiny.
3. ISO 27001: Annex A.8.8 and Clause 8.8 Explained
ISO 27001:2022 is more explicit about technical security testing than SOC 2. The 2022 revision (which superseded ISO 27001:2013) specifically addresses penetration testing as a control.
"Information about technical vulnerabilities of information systems in use shall be obtained in a timely fashion, the organization's exposure to such vulnerabilities evaluated, and appropriate measures taken to address the associated risk." The supporting standard (ISO 27002:2022) identifies penetration testing as a key tool for evaluating actual exposure - beyond the theoretical vulnerabilities identified by scanning.
ISO 27001 also requires organizations to test their information security controls through Clause 9.1 (performance evaluation) and Clause 9.3 (management review). Penetration testing is one of the primary tools that satisfies both.
Penetration testing is explicitly referenced in ISO 27002 (the implementation guidance document for ISO 27001) as the appropriate way to test for vulnerabilities under real-world conditions. Certification bodies and auditors typically expect to see evidence of penetration testing as part of a functioning ISMS. The frequency is at least annual and after significant changes to your environment.
4. PCI DSS v4.0: The Explicit Penetration Testing Requirements
PCI DSS is the most prescriptive of the four frameworks on penetration testing. It does not leave interpretation to auditors - it explicitly requires penetration testing, defines what the test must include, and specifies who can conduct it.
"External penetration testing is performed at least once every 12 months and after any significant infrastructure or application upgrade or modification." The test must be conducted by a qualified internal resource or qualified external third-party with organizational independence.
"Internal penetration testing is performed at least once every 12 months and after any significant infrastructure or application upgrade or modification." Internal testing covers your internal network and systems within the cardholder data environment boundary.
The test under PCI DSS must cover:
- Network-layer testing including network and operating system components
- Application-layer testing including all web-facing functionality
- Testing from both outside and inside the network perimeter
- Segmentation controls testing if cardholder data is segmented from other networks
- Remediation of all exploitable vulnerabilities before the testing cycle is considered complete
PCI DSS also defines "qualified" in specific terms: the tester must have specialized penetration testing skills and knowledge, and they must have organizational independence (meaning they cannot test systems they are responsible for maintaining).
If your product processes, stores, or transmits cardholder data, penetration testing is not optional. Requirement 11.3 is explicit, annually mandatory, and enforced by your Qualified Security Assessor (QSA) during certification. You cannot achieve PCI DSS compliance without documented evidence of penetration testing by a qualified individual.
5. HIPAA: §164.308(a)(8) and What Technical Evaluation Means
HIPAA's Security Rule requires covered entities and business associates to conduct periodic technical and non-technical evaluations of their security controls.
"Perform a periodic technical and non-technical evaluation, based initially upon the standards implemented under this rule and subsequently in response to environmental or operational changes affecting the security of electronic protected health information (ePHI)."
HIPAA does not use the term "penetration testing." But the Office for Civil Rights (OCR), which enforces HIPAA, and every major HIPAA auditing firm interpret "technical evaluation" to mean active security testing under adversarial conditions - not just documentation review or automated scanning.
The technical safeguards in §164.312 that must be evaluated include access controls, audit controls, integrity controls, and transmission security. Each of these requires active verification that the controls work under real-world attack scenarios, which is what penetration testing provides.
OCR enforcement history is instructive. Between 2019 and 2024, the most common finding in resolved enforcement actions was the absence of a thorough security risk analysis and technical evaluation. Organizations that conducted regular, documented penetration testing had significantly better outcomes in OCR investigations than those that relied on documentation and scanning alone.
A penetration test is the most defensible way to satisfy the §164.308(a)(8) technical evaluation requirement. "Periodic" is not defined in the regulation, but annual testing aligned to major changes in your ePHI environment is the industry standard and what OCR investigators expect to see evidence of. Use a third-party firm so the testing has organizational independence - this matters in post-breach investigations.
6. GDPR: What Article 32 Says About Security Testing
GDPR requires appropriate technical and organizational measures to ensure a level of security appropriate to the risk of processing personal data of EU residents.
"A process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing." This article explicitly requires a testing process - not just controls in place.
GDPR does not prescribe specific testing methods, but "regularly testing and evaluating effectiveness" is most meaningfully satisfied by penetration testing. A vulnerability scan demonstrates you looked for issues. A penetration test demonstrates you tested whether your controls are actually effective under adversarial conditions.
In the event of a data breach investigation by a supervisory authority (such as the UK ICO or Germany's BSI), evidence that you regularly conducted penetration testing is a significant mitigating factor. Organizations that cannot demonstrate proactive security testing face significantly higher fines.
7. Planning Your Testing to Satisfy Multiple Frameworks at Once
Most SaaS companies are not pursuing just one framework. A Fintech startup selling to enterprise might need SOC 2 for US customers, GDPR compliance for EU customers, PCI DSS for payment processing, and potentially ISO 27001 for enterprise contracts in Europe or Asia.
The good news: a single well-scoped penetration test can produce evidence that satisfies multiple frameworks simultaneously, as long as the scope, methodology, and documentation are structured correctly.
| Test Coverage | Satisfies |
|---|---|
| External web application + API testing | SOC 2 CC6.6, ISO 27001 A.8.8, PCI DSS 11.3.1, HIPAA §164.308 |
| Internal network + access control testing | SOC 2 CC6.1, PCI DSS 11.3.2, HIPAA §164.312 |
| Cloud infrastructure (IAM, storage, network) | SOC 2 CC7.1, ISO 27001 A.8.8, HIPAA §164.308 |
| Compliance control mapping in report | Required by SOC 2 auditors, HIPAA OCR investigations, PCI QSAs |
When you commission a penetration test for compliance, tell the testing firm which frameworks apply. A good firm will structure the report to include findings mapped to the relevant controls, which makes the audit process significantly smoother.
Recommended Annual Testing Timeline
- Plan testing 2–3 months before your compliance audit window closes
- Allow 2–4 weeks for testing, reporting, and the debrief call
- Allow 4–8 weeks for your team to remediate findings before the re-test
- Schedule the re-test before submitting evidence to your auditor
- Retain all reports - auditors may ask for the last 2–3 years of testing history
Ready to Get Compliance-Grade Penetration Testing?
We structure our engagements to satisfy SOC 2, ISO 27001, PCI DSS, and HIPAA simultaneously. Tell us which frameworks apply to your business and we will scope testing that satisfies all of them in a single engagement.
Summary
PCI DSS is the most explicit - it mandates annual penetration testing by a qualified, independent tester, full stop. HIPAA, SOC 2, and ISO 27001 are less prescriptive but functionally require the same thing: evidence that your security controls have been actively tested under adversarial conditions, not just documented and scanned.
The most efficient approach for most SaaS startups is an annual penetration test scoped to cover the attack surface relevant to all applicable frameworks, with a report structured to satisfy each framework's documentation requirements. This turns what could be four separate testing obligations into one well-planned annual engagement.
If you are unsure which frameworks apply to your business or how to scope a test that satisfies all of them, that is exactly what the scoping conversation before any NullStrike engagement is designed to answer.