Where Penetration Testing Fits in SOC 2
SOC 2 is not a checklist. It is a framework built on five Trust Service Criteria defined by the AICPA: Security, Availability, Processing Integrity, Confidentiality and Privacy. Of these five, Security is always in scope. The rest are optional depending on what your customers require.
Within the Security criterion, two common controls directly implicate penetration testing:
- CC7.1 - Detection and Monitoring
- 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. Translation: you must actively identify vulnerabilities in your environment. A penetration test does exactly this by simulating real attack paths against your infrastructure and applications.
- CC7.2 - Anomaly Detection
- 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. A penetration test validates whether your monitoring controls actually detect simulated attacks. If the pentest team moves laterally through your network and your SIEM generates zero alerts, the auditor has a finding.
The Trust Service Criteria never use the phrase "penetration test." That ambiguity is what causes confusion. But in practice, nearly every SOC 2 auditor expects to see one. The test is your evidence that CC7.1 and CC7.2 controls are functioning as designed.
Type I vs Type II: Why the Distinction Matters for Pentesting
A SOC 2 Type I report evaluates your controls at a single point in time. The auditor looks at the design of your controls and determines whether they are suitably designed to meet the criteria. A pentest is helpful for Type I but not strictly required because the auditor is only evaluating design, not operating effectiveness.
A SOC 2 Type II report is different. It evaluates the operating effectiveness of your controls over a period of time, typically 6 or 12 months. The auditor needs evidence that your controls were not just designed properly but actually worked throughout the observation period. This is where penetration testing becomes essential.
| Attribute | Type I | Type II |
|---|---|---|
| Evaluation scope | Control design at a point in time | Operating effectiveness over 6-12 months |
| Pentest expectation | Recommended but not always required | Expected by nearly all auditors |
| Timing requirement | Before or on the report date | Must fall within the observation window |
| Retest evidence | Rarely requested | Required for critical and high findings |
| Customer acceptance | Limited; often treated as a stepping stone | Industry standard for vendor risk management |
If you are pursuing Type II certification, schedule your penetration test within the observation window. A test conducted outside the window does not count as evidence of operating effectiveness during the period under review.
What Auditors Actually Read in Your Pentest Report
Auditors are not penetration testers. They are CPAs with a security specialization. They do not care about the technical details of how your tester exploited a misconfigured S3 bucket. They care about five specific things:
Scope alignment. The scope of the penetration test must align with the system description in your SOC 2 report. If your system description covers a SaaS platform hosted on AWS, the pentest must cover that SaaS platform on AWS. A pentest of your corporate network when the SOC 2 scope is a cloud application is irrelevant evidence.
Methodology. Auditors want to see a recognized methodology. PTES (Penetration Testing Execution Standard), OWASP Testing Guide or NIST SP 800-115 are all acceptable. The methodology tells the auditor that the test was structured and repeatable, not ad hoc.
Risk-rated findings. Every finding must have a severity rating. CVSS scores are the standard. The auditor will focus on critical and high findings and verify that each one has a documented remediation plan or compensating control.
Remediation evidence. For critical and high findings the auditor expects to see retest evidence showing that the vulnerability was remediated. A finding without remediation evidence becomes a gap in your control environment. Multiple unresolved critical findings can result in a qualified opinion.
Statement of limitations. The auditor needs to know what was excluded from testing and why. If internal network testing was excluded because of a change freeze, document that. Undisclosed limitations create risk for the auditor and they will push back.
Common Fails That Create Audit Findings
These are the mistakes that turn a clean pentest into an audit problem. Every one of these has caused a real SOC 2 observation or exception in the past 12 months.
- Narrow scope that does not match the system description
- The most frequent fail. A company scopes the pentest to cover only external infrastructure while their SOC 2 system description includes internal systems and a web application. The auditor flags a gap because the test does not provide evidence for the full control environment. Match the pentest scope to the system description before the engagement starts.
- No retest of critical and high findings
- The pentest identifies a critical SQL injection vulnerability. The development team fixes it. But nobody retests to confirm the fix works. The auditor sees a critical finding with no closure evidence. This becomes an exception in the SOC 2 report that every customer and prospect will read.
- Unmapped findings
- The pentest report lists findings by technical severity but does not map them to SOC 2 controls. The auditor has to guess which finding relates to which criterion. This slows the audit and increases the likelihood that the auditor will request additional evidence or issue an observation.
- Test conducted outside the observation window
- A company completes their pentest in January. Their SOC 2 Type II observation period runs from April to March of the following year. The January test falls outside the window. The auditor cannot accept it as evidence of operating effectiveness during the observation period. The company has to pay for a second test.
- Vulnerability scan passed off as a penetration test
- Running Nessus or Qualys against your infrastructure is a vulnerability scan, not a penetration test. A scan identifies known vulnerabilities from a database. A penetration test attempts to exploit those vulnerabilities and chains them together to demonstrate real impact. Auditors know the difference. Submitting a scan report as pentest evidence will result in a request for clarification at best and an exception at worst.
How to Structure the Report for SOC 2
Your penetration testing vendor should deliver a report that an auditor can consume without translation. Here is the structure that satisfies auditor expectations.
| Report Section | What to Include | Why Auditors Need It |
|---|---|---|
| Executive summary | Overall risk rating, total findings by severity, scope summary and test dates | First page the auditor reads. Must confirm the test covered the right systems during the right timeframe. |
| Scope and methodology | IP ranges, application URLs, testing methodology (PTES/OWASP), rules of engagement | Proves the test was structured and aligned with the SOC 2 system description. |
| Findings detail | Each finding with CVSS score, affected asset, evidence (screenshots/logs), remediation recommendation | Provides the auditor with specific control gaps to evaluate against Trust Service Criteria. |
| Control mapping | Each finding mapped to the relevant SOC 2 control (CC7.1, CC7.2 or others) | Eliminates guesswork for the auditor. Demonstrates that the tester understands the compliance context. |
| Remediation status | Current status of each finding: remediated, in progress, accepted risk | Shows the auditor that findings are being tracked and addressed systematically. |
| Retest evidence | Verification that critical and high findings were retested after remediation | Closes the loop. Without this the auditor treats the finding as open. |
| Limitations | Systems excluded, time constraints, testing restrictions | Auditors need full transparency about what the test did and did not cover. |
Timeline Relative to the Audit Window
Timing is everything. Schedule the pentest wrong and you either waste money or create an audit gap. Here is the timeline that works.
Month 1-2 of the observation period: Conduct the penetration test. This gives you maximum time to remediate findings before the auditor begins fieldwork. If the observation window is April through March, schedule the test for May or June.
Month 2-4: Remediate critical and high findings. Assign owners. Track progress in your GRC platform or a simple spreadsheet. The auditor will want to see a remediation tracker.
Month 3-5: Retest remediated findings. Your pentest vendor should offer retesting as part of the engagement or as a fixed-fee add-on. Get the retest results documented in a formal addendum to the original report.
Month 8-10: Auditor fieldwork begins. The pentest report, remediation tracker and retest evidence should be ready before the auditor asks for them. Proactive delivery signals maturity and reduces the number of follow-up requests.
If you are running your first SOC 2 Type II audit, consider a readiness assessment three months before the observation period starts. This identifies control gaps early so you can address them before the clock starts running.
One Pentest, Multiple Compliance Checkboxes
A well-scoped penetration test does not serve only SOC 2. The same report can satisfy requirements across multiple frameworks simultaneously.
| Framework | Relevant Requirement | Covered by Pentest |
|---|---|---|
| SOC 2 | CC7.1 and CC7.2 | Yes |
| PCI DSS 4.0 | Requirement 11.4 | Yes (with PCI-specific scoping) |
| ISO 27001:2022 | Annex A Control A.8.8 | Yes |
| HIPAA | Technical safeguard evaluation (164.308(a)(8)) | Yes |
| Cyber insurance | Annual third-party pentest requirement | Yes |
| FedRAMP | CA-8 Penetration Testing | Yes (with FedRAMP-specific methodology) |
If you need to satisfy more than one framework, tell your pentest vendor before the engagement starts. They can adjust the scope, methodology and report format to cover multiple requirements in a single test. This saves you from paying for separate assessments and gives your auditor a comprehensive evidence package.
Frequently Asked Questions
- Does SOC 2 require a penetration test?
- The Trust Service Criteria do not explicitly require a penetration test. However, CC7.1 and CC7.2 require vulnerability identification and anomaly detection. Auditors interpret these as requiring periodic pentesting. In practice, if you show up to a Type II audit without a pentest, expect the auditor to request one.
- How often do you need a penetration test for SOC 2?
- At minimum, annually. The test must fall within the observation period for Type II audits. Some organizations with higher risk profiles or shorter observation windows test semi-annually.
- What should a SOC 2 penetration test report include?
- Scope mapped to the system description, a recognized methodology, risk-rated findings with CVSS scores, remediation recommendations, retest evidence for critical and high findings and a statement of limitations.