SOC 2 Penetration Testing Requirements: What Auditors Actually Expect and How to Exceed Them

Pentest Requirements Across Compliance Frameworks

The Trust Services Criteria That Drive Pentest Requirements

SOC 2 is organized around five Trust Services Categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is mandatory for every SOC 2 engagement; the others are selected based on the organization's service commitments. Penetration testing maps most directly to the Security category, but it also provides evidence for Confidentiality and Availability controls.

The criteria most commonly satisfied by penetration testing include:

• CC4.1 — COSO Principle 16: The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether components of internal control are present and functioning. A penetration test is a separate evaluation that validates whether security controls actually work as intended — not just that they exist on paper.
• CC7.1: The entity uses detection and monitoring procedures to identify changes to configurations that result in the introduction of new vulnerabilities, and susceptibilities to newly discovered vulnerabilities. Penetration testing identifies vulnerabilities that configuration monitoring and scanning miss.
• CC7.2: The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives. Pentest results demonstrate the organization's ability to detect and respond to simulated attacks.

What Auditors Actually Review in Your Pentest Report

Having conducted hundreds of penetration tests that were subsequently reviewed by SOC 2 auditors, we can identify the specific elements auditors look for — and what causes them to request additional evidence or issue management letter comments.

Scope Alignment

The auditor compares the scope of the penetration test against the system description in your SOC 2 report. If your system description lists a web application, API, and cloud infrastructure as in-scope components, but your pentest only tested the web application, the auditor will note the gap. Every component in the system description should be covered by some form of security testing — and the pentest is the primary evidence for application-layer and network-layer controls.

Timing and Currency

The pentest must fall within the examination period for a Type II report. A test conducted 14 months ago does not satisfy an auditor reviewing your current audit period. Best practice is to schedule the penetration test early enough in the audit period that remediation and retesting can be completed before the examination window closes — typically within the first six months of a 12-month audit period.

Remediation Evidence

A pentest report showing critical and high-severity findings is not a problem — findings are expected. What auditors care about is remediation. They want to see that critical and high-severity findings were addressed within a defined timeline, that remediation was tracked in a ticketing system (Jira, Linear, Asana) with assignees and due dates, and that retesting confirmed the fixes were effective. Unresolved critical findings within the audit period will almost certainly result in an exception in the auditor's report.

Scope Requirements: What to Include

The minimum scope that satisfies most SOC 2 auditors includes external network penetration testing of internet-facing infrastructure, web application penetration testing of customer-facing applications, and API security testing for any APIs referenced in the system description. Organizations with more mature security programs — or those pursuing SOC 2+ — should also include internal network testing, cloud configuration review, and social engineering assessments.

A common mistake is scoping the penetration test to a production environment but maintaining a staging environment with weaker controls that has access to production data. Auditors are increasingly aware of this gap and may ask about non-production environment security, especially if your system description references development or staging infrastructure.

Cloud Infrastructure Considerations

For organizations running on AWS, GCP, or Azure, the penetration test scope should include cloud configuration review — IAM policies, security group rules, storage bucket permissions, encryption configuration, and logging settings. A web application penetration test alone does not satisfy the infrastructure security controls in your SOC 2. Cloud-specific testing requires the pentester to understand the shared responsibility model and test your half of it, not the cloud provider's.

Going Beyond Checkbox Compliance

The organizations that get the most value from SOC 2 penetration testing treat it as a security improvement exercise rather than a compliance checkbox. This means several things in practice:

• Test more than the minimum. Include business logic testing, authentication and authorization testing, and API abuse scenarios — not just the OWASP Top 10 scan-and-report that many low-cost providers deliver.
• Map findings to Trust Services Criteria. When your pentest report maps each finding to the specific TSC it affects, the auditor's job becomes easier and your remediation priorities become clearer. A SQL injection finding maps to CC6.1 (logical access controls) and CC6.6 (system boundaries). An exposed admin panel maps to CC6.1 and CC6.3 (role-based access).
• Maintain a remediation SLA. Define and enforce timelines: critical findings remediated within 7 days, high within 30, medium within 90. Document these SLAs and demonstrate adherence. Auditors love seeing a policy that matches reality.
• Test continuously. An annual penetration test provides a point-in-time snapshot. Organizations deploying code weekly or daily have a significant gap between annual tests. Continuous penetration testing or a PTaaS model closes this gap and provides ongoing evidence for CC7.1 and CC7.2.

Evidence Collection Best Practices

Prepare your pentest evidence before the auditor asks for it. The evidence package should include the signed statement of work defining the engagement scope, the full penetration test report with methodology, findings, and severity ratings, remediation tickets showing assignment, timeline, and completion status, retest results confirming remediation effectiveness, and a risk acceptance document for any findings that were not remediated with justification and compensating controls.

Store this evidence in your GRC platform (Drata, Vanta, Secureframe, or equivalent) and link it to the specific Trust Services Criteria it supports. When the auditor requests pentest evidence, you should be able to provide a complete package within hours, not days. The speed and organization of your evidence response signals the maturity of your security program.

For SOC 2-ready penetration testing that maps findings directly to Trust Services Criteria and includes remediation retesting — schedule a consultation with Lorikeet Security. We work with your auditor's timeline to ensure testing and remediation fall within your examination period.

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.