SOC 2 Penetration Testing
SOC 2 is an AICPA attestation that reports on the controls at a service organisation against the Trust Services Criteria — Security (the Common Criteria), Availability, Processing Integrity, Confidentiality and Privacy. An independent penetration test is the evidence auditors most commonly expect to see when they evaluate how you detect and respond to security weaknesses.
OraSec delivers manual, scoped penetration testing built around your SOC 2 audit. We map findings to the criteria your auditor is testing, rate every issue with CVSS, verify the fixes, and hand you a report — plus a retest letter — that drops cleanly into your evidence package.
Prefer to talk? +1 307 310 7808
Does SOC 2 Require a Penetration Test?
The honest, accurate answer: not as an explicit, line-item requirement. SOC 2 is an attestation defined by the AICPA, and you are assessed against the Trust Services Criteria. No single criterion literally states "you must perform a penetration test." You will sometimes hear vendors claim SOC 2 "requires" a pentest — that overstates it.
What is true is that a penetration test is the practical, widely accepted evidence auditors expect when they evaluate several of the Common Criteria. To conclude that your controls are designed and operating effectively, an auditor needs to see that you periodically and independently test your security posture and act on what you find. A penetration test is the most direct way to demonstrate that. In practice, the large majority of service organisations pursuing SOC 2 commission one, and many auditors will ask for a recent report before they sign off.
So the right framing is: a SOC 2 penetration test is strongly expected, not legally mandated. Treating it as expected — and timing it correctly — is what keeps the audit moving without last-minute findings.
How a Pentest Maps to the Trust Services Criteria
The Security category — the Common Criteria — is mandatory in every SOC 2 report. Several of its criteria are where independent testing evidence does the most work. We tag findings to the specific criteria below so your auditor does not have to build the cross-walk themselves.
CC4.1 — Monitoring of controls
The Common Criteria expect entities to select, develop and perform ongoing and separate evaluations to confirm the components of internal control are present and functioning. An independent penetration test is the separate evaluation auditors most often point to here — it is direct evidence that someone outside the control owner periodically tests whether your security controls actually hold up against attack.
CC7.1 — Detection of vulnerabilities
CC7.1 covers using detection and monitoring procedures to identify changes and susceptibilities to vulnerabilities. A scoped pentest demonstrates that you proactively hunt for exploitable weaknesses across your in-scope systems rather than waiting for a scanner alert or a real incident to surface them.
CC7.2 — Monitoring and remediation
CC7.2 addresses monitoring system components for anomalies and acting on them. The remediation and retest portion of a penetration test — confirmed fixes, a documented closure trail and a retest letter — shows the auditor that identified issues feed a real remediation workflow, not just a backlog.
The other Trust Services categories — Availability, Processing Integrity, Confidentiality and Privacy — are only in scope if you include them in your audit. Where they are, penetration testing findings that touch data exposure, access control or resilience are mapped to the relevant criteria as well.
What We Test
SOC 2 scope is driven by your system description — the applications, APIs and infrastructure that handle in-scope data. We scope the engagement to that boundary. The components below are the most commonly tested for a SOC 2 audit.
Web Application Security Testing
Comprehensive web app penetration testing covering OWASP Top 10 and beyond. Find business logic flaws and auth bypasses automated tools miss.
API Security Testing
Manual API pen testing by certified testers. We find BOLA, BFLA, and logic flaws automated tools miss — covering OWASP API Top 10 across REST, GraphQL, and gRPC.
Cloud Security Assessment
AWS, Azure, and GCP security assessments covering IAM, network configuration, and data protection. Secure your cloud infrastructure.
External Penetration Testing
Simulate real-world attacks on internet-facing infrastructure. Manual pentests find vulnerabilities scanners miss before attackers exploit them.
Network Infrastructure Penetration Testing
Internal and external network penetration testing by certified testers. We uncover misconfigurations, lateral movement paths, and segmentation failures across routers, firewalls, and servers — before attackers do. OraSec.
Deliverables Your Auditor Will Accept
A scanner PDF is not penetration-test evidence. Auditors want to see an independent, methodical engagement with a clear boundary, defensible methodology and a closed remediation loop. Every SOC 2 engagement we run is packaged so it can go straight into your evidence request list.
The retest letter is the piece teams most often forget. Finding issues proves CC7.1; verifying they were fixed and documenting closure is what evidences CC7.2. We include both.
What's in the report
- A defined scope statement listing every in-scope system, application, network range and environment, plus explicit exclusions — so the auditor can confirm the test covered the boundary described in your SOC 2 system description.
- A documented methodology referencing recognised standards (OWASP Testing Guide, OWASP ASVS, the PTES phases) so the engagement is repeatable and defensible.
- Findings rated with CVSS v3.1 / v4.0 base scores, each with reproduction steps, evidence and business impact — not just a raw scanner export.
- Prioritised, actionable remediation guidance written for engineers, mapped to the specific component that needs to change.
- A retest / remediation-verification letter confirming which findings were re-tested and closed after fixes — the artefact auditors use as evidence for CC7.2.
- An executive summary and an attestation letter on company letterhead identifying the testing firm, the dates of testing and the assessment type.
Timing It With Your Audit Window
For a SOC 2 Type I report — which assesses whether controls are suitably designed at a single point in time — a recent penetration test demonstrates the evaluation control exists by the as-of date. For a SOC 2 Type II report — which assesses whether controls operated effectively over a review period, commonly three to twelve months — the test needs to fall inside, or close to, that window so the auditor can treat it as evidence the control actually operated.
The practical rule most auditors apply is an annual penetration test, performed so it lands within the current audit window. The common failure mode is leaving it too late: a test that surfaces a high-severity finding days before the period closes leaves no time to remediate and retest, which can hold up the report.
We work backwards from your period-end. Scoping, active testing, reporting, remediation and the retest all need to fit inside the window — so the earlier in the period the test runs, the more room you have to close findings cleanly. Tell us your audit dates and we will plan the engagement around them.
Scope Your SOC 2 Penetration Test
Tell us your audit dates, the systems in your SOC 2 system description, and whether it is a Type I or Type II report. We will come back with a scoped plan built to land inside your audit window — typically within one business day.
Frequently Asked Questions — SOC 2
Does SOC 2 require a penetration test?+
Not as an explicit, line-item requirement. SOC 2 is an AICPA attestation against the Trust Services Criteria, and no single criterion literally says "perform a penetration test." However, a penetration test is the practical evidence auditors strongly expect to see when evaluating criteria such as CC4.1 (ongoing and separate evaluations of controls) and CC7.1 / CC7.2 (detecting and responding to vulnerabilities). In practice, most auditors will ask for a recent independent penetration test, and many service organisations treat it as a de facto expectation for a clean report. It is strongly expected rather than legally mandated.
SOC 2 Type I vs Type II — when do I need the pentest?+
A SOC 2 Type I report assesses whether controls are suitably designed at a single point in time. A Type II report assesses whether those controls operated effectively over a review period — commonly 3 to 12 months. Penetration test evidence is most relevant to Type II, because the auditor is looking for proof that your vulnerability-detection and evaluation controls actually operated during the window. For a Type II audit, plan to have a penetration test completed within (or recently before) the review period so it falls inside the evidence the auditor reviews.
How often do I need a SOC 2 penetration test?+
An annual penetration test is the common cadence, and many auditors specifically want one performed within the current audit window so it sits inside the period under review. Beyond the annual baseline, it is good practice to test again after any significant change — a major release, a new product surface, an infrastructure migration or a re-architecture — because those changes can introduce new exploitable issues that your last test did not cover.
What does the auditor want to see in the report?+
Auditors typically want a report that clearly states the scope (the systems and boundary tested), the methodology used, findings rated with CVSS severity, remediation guidance, and evidence that issues were retested and closed. They also look for an attestation or summary letter identifying the independent testing firm and the dates of testing. The retest / remediation-verification letter matters because it demonstrates the CC7.2 remediation loop actually closed, not just that vulnerabilities were found.
How long does SOC 2 penetration testing take?+
Most SOC 2-oriented penetration tests run roughly one to two weeks of active testing for a typical web application, API and supporting cloud or external footprint, with scope being the main driver. Add a few business days for reporting and quality review, and additional time for remediation before the retest. Larger or multi-application environments take longer. We confirm a precise timeline once scope is agreed so the engagement lands inside your audit window.