Penetration Testing for Compliance: SOC 2, ISO 27001, PCI DSS, and HIPAA Requirements Compared

Every major compliance framework expects some form of security testing, but the specifics vary significantly. SOC 2 strongly expects it without explicitly mandating it. PCI DSS prescribes exact scope and frequency. ISO 27001 requires it as part of your risk treatment plan. HIPAA references it as an addressable safeguard. Understanding these differences is the difference between running one well-scoped engagement that satisfies all your frameworks and paying for redundant tests that still leave gaps.

This guide breaks down exactly what each framework requires, where the overlaps exist, and how to structure penetration testing engagements that check every compliance box efficiently.

The Master Comparison: Pentest Requirements by Framework

SOC 2 Penetration Testing Requirements

SOC 2 does not include a line item that says "thou shalt conduct a penetration test." Instead, the requirement emerges from multiple Common Criteria controls, particularly CC4.1 (the entity selects, develops, and performs ongoing evaluations to ascertain whether the components of internal control are present and functioning) and CC7.1 (the entity uses detection and monitoring procedures to identify changes to configurations and new vulnerabilities).

In practice, every SOC 2 auditor expects to see a penetration test report. The absence of one will generate an inquiry at minimum and may result in a qualification or exception in your report. Auditors view penetration testing as the most credible evidence that your security controls are effective against real-world attack scenarios.

What SOC 2 Auditors Look For in Your Pentest Report

• Testing scope that aligns with your SOC 2 system description and in-scope infrastructure
• Both external and internal testing perspectives where applicable
• Application-layer testing for web applications and APIs in scope
• Findings mapped to risk severity with clear remediation guidance
• Evidence that critical and high-severity findings have been remediated or have documented remediation plans
• A testing methodology that references industry standards (OWASP, PTES, NIST SP 800-115)

ISO 27001 Penetration Testing Requirements

ISO 27001:2022 addresses penetration testing through two primary controls. Annex A 8.8 (Management of technical vulnerabilities) requires organizations to identify and address technical vulnerabilities, with penetration testing as a key validation mechanism. Annex A 5.36 (Compliance with policies, rules, and standards for information security) requires independent review of security practices, which penetration testing directly supports.

Unlike PCI DSS, ISO 27001 does not prescribe exact testing frequency or methodology. Instead, the scope and frequency of penetration testing should be driven by your risk assessment. However, in practice, certification auditors expect to see annual penetration testing covering your ISMS scope, and the risk assessment should justify the testing approach you have chosen.

ISO 27001 Pentest Scope Considerations

• ISMS scope alignment. Your penetration test must cover the systems and processes within your Statement of Applicability. If your ISMS covers your entire organization, the pentest scope should be comprehensive
• Risk-based prioritization. ISO 27001 allows you to focus testing on areas identified as higher risk in your risk assessment. Document the rationale for scope decisions
• Third-party assessment. Certification bodies strongly prefer that penetration tests be conducted by qualified external parties rather than internal teams, as this supports the independence requirement
• Remediation tracking. ISO 27001 requires a formal process for addressing identified vulnerabilities, including timelines and accountability. Your pentest findings must feed into your corrective action process

An ISO 27001-focused penetration test typically starts at $10,000, reflecting the broader scope and detailed reporting required for certification auditors. For organizations pursuing dual SOC 2 and ISO 27001 certification, a single engagement can be scoped to satisfy both frameworks.

PCI DSS v4.0 Penetration Testing Requirements

PCI DSS is the most prescriptive framework when it comes to penetration testing requirements. Requirement 11.4 specifies exactly what must be tested, how often, and what the report must contain.

PCI DSS Pentest Mandatory Requirements

• Annual penetration testing of the cardholder data environment (CDE) and any connected systems
• Testing after any significant infrastructure or application change affecting the CDE
• Both network-layer and application-layer penetration testing
• Testing from both inside and outside the network perimeter
• Segmentation testing every six months (if network segmentation is used to reduce CDE scope)
• Use of an industry-accepted methodology (PTES, OWASP, NIST SP 800-115)
• Remediation and retesting of all exploitable vulnerabilities found

PCI DSS v4.0 also introduced new requirements around authenticated application testing and expanded the scope of what constitutes a "significant change" that triggers re-testing. Organizations processing card data should budget for at least one comprehensive annual test plus ad-hoc testing as infrastructure changes occur.

Common PCI Pentest Failures

• Testing only the web application while ignoring network-layer infrastructure within the CDE
• Failing to test from both internal and external perspectives
• Not performing segmentation validation testing, or performing it only annually instead of every six months
• Using automated vulnerability scanning and labeling it as a penetration test -- QSAs will reject this
• Not retesting remediated findings to confirm they are actually resolved

HIPAA Penetration Testing Requirements

HIPAA's Security Rule (45 CFR 164.308) includes technical evaluation as an addressable implementation specification under the evaluation standard. "Addressable" in HIPAA does not mean optional -- it means the organization must either implement the safeguard or document why an equivalent alternative measure is reasonable and appropriate.

For organizations handling electronic protected health information (ePHI), penetration testing is the most defensible way to satisfy the technical evaluation requirement. The HIPAA security testing guide provides detailed guidance on scoping these assessments.

HIPAA Pentest Scope Recommendations

• ePHI system coverage. All systems that create, receive, maintain, or transmit ePHI should be in scope, including EHR systems, patient portals, medical devices, and integration interfaces
• Access control testing. HIPAA places significant emphasis on access controls. Your pentest should specifically test role-based access, authentication mechanisms, and authorization boundaries around ePHI
• Encryption validation. Test that encryption at rest and in transit is properly implemented for ePHI, including database encryption, API transport security, and backup encryption
• Audit logging verification. Verify that access to ePHI is logged appropriately and that logs cannot be tampered with

While HIPAA does not specify testing frequency, annual penetration testing aligned with your risk analysis cycle is the standard practice accepted by OCR during investigations. Healthcare organizations should also consider testing after significant system changes, particularly EHR migrations or new patient-facing portal deployments.

Satisfying Multiple Frameworks with One Engagement

The most cost-effective approach for organizations subject to multiple compliance frameworks is to scope a single penetration test that covers the broadest required scope and structure the report to map findings to each framework's requirements.

The Unified Compliance Pentest Approach

1. Map the broadest scope. If you need SOC 2, ISO 27001, and PCI DSS coverage, the PCI CDE scope plus your SOC 2 in-scope systems plus your ISO ISMS scope defines the test boundary. In most cases, PCI DSS defines the floor because it is the most prescriptive
2. Include all required test types. Ensure the engagement covers external network testing, internal network testing, application-layer testing, and segmentation testing (if applicable for PCI)
3. Structure the report with framework mappings. Each finding should map to the relevant controls across all applicable frameworks. This allows auditors and assessors from each framework to find their specific evidence without requiring separate reports
4. Plan for remediation and retesting. PCI DSS requires retesting of all exploitable findings. Building this into the engagement timeline ensures you have the verified remediation evidence that all frameworks expect

Lorikeet Security's compliance-focused penetration tests are specifically structured to produce reports that satisfy multiple frameworks simultaneously. The report includes framework-specific mappings, executive summaries formatted for different audiences (auditors, QSAs, board members), and remediation guidance prioritized by both risk severity and compliance impact.

Pentest Frequency: Finding the Right Cadence

Annual penetration testing is the minimum for any compliance-driven organization, but the optimal cadence depends on your risk profile and change velocity.

When Annual Testing Is Sufficient

• Stable infrastructure with infrequent changes to production systems
• Single compliance framework requirement (SOC 2 or ISO 27001 only)
• Low-risk application with minimal attack surface
• Supplemented by continuous vulnerability scanning between annual tests

When More Frequent Testing Is Necessary

• PCI DSS compliance with segmentation (requires semi-annual segmentation testing)
• Rapid development cycles with frequent production deployments
• Multiple compliance frameworks with overlapping but different testing cycles
• Post-incident validation after a security breach or significant vulnerability disclosure
• Major infrastructure changes (cloud migration, new application launch, M&A integration)

The Offensive Security Bundle at $37,500 per year provides the testing cadence that compliance-mature organizations need: two web application penetration tests, one network penetration test, one API assessment, quarterly vulnerability scanning, and continuous attack surface management. This covers annual compliance requirements while providing the additional testing events needed when infrastructure changes occur.

Choosing a Compliance-Focused Pentest Provider

Not all penetration testing providers produce reports that compliance auditors will accept. When evaluating providers for compliance-driven testing, look for these qualifications:

• Experience producing reports that have been accepted by SOC 2 auditors, ISO certification bodies, PCI QSAs, or HIPAA assessors
• Methodology documentation that references OWASP, PTES, NIST SP 800-115, or PCI Penetration Testing Guidance
• Report format that includes executive summary, technical findings with risk ratings, framework-specific control mappings, and remediation guidance
• Remediation retesting included in the engagement to verify that findings are resolved before audit fieldwork
• Willingness to communicate directly with your auditor or QSA if questions arise about findings or methodology

• Avoid providers that deliver only automated scan output labeled as a penetration test
• Avoid providers that cannot explain how their methodology maps to your specific compliance framework requirements
• Avoid providers that do not include retesting -- auditors expect verified remediation, not just a findings list

Lorikeet Security provides compliance-focused penetration testing with report formats specifically designed for auditor consumption. SOC 2 pentests start at $7,599, PCI DSS pentests start at $11,500, and ISO 27001 pentests start at $10,000. Each engagement includes remediation retesting and direct auditor support. For a detailed pricing breakdown across all test types, see our transparent pentest pricing guide.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.