SOC 2 Penetration Testing
Expert manual penetration testing that gives your SOC 2 auditor exactly what they ask for: defined scope, credentialed testers, a defensible report, and a documented remediation trail.
The Honest Answer
Does SOC 2 require a penetration test?
Strictly speaking, the SOC 2 framework never uses the words "penetration test." The Trust Services Criteria ask you to evaluate and monitor your controls (most relevantly in CC4.1 and CC7.1), and they leave the "how" to you and your auditor.
In practice, that distinction rarely helps you. Most auditors expect a penetration test as evidence that your monitoring and vulnerability management controls actually work, and the enterprise customers who asked for your SOC 2 report in the first place usually expect to see a recent pentest alongside it. A Type II report that leans only on automated scans is a report that invites follow-up questions.
So the practical requirement is real: an annual penetration test, performed by a qualified independent firm, with evidence an auditor can trace. That is the engagement we run.
Documented scope and methodology
Auditors want to see what was tested, how, and against what standard. Every TrustFoundry engagement produces a defined scope, an industry-standard methodology, and named, credentialed testers.
A report built for evidence requests
Findings with severity, impact, reproduction steps, and remediation guidance, in a report you can hand to an auditor or a customer's security team without editing.
Remediation and retest records
SOC 2 cares about what happened after the findings. Our platform tracks remediation status and one-click retests, so the fix history is documented instead of reconstructed.
A field-level audit trail
Who found what, when it was approved, when it was fixed, and who verified it. The changelog exists because we run our own assessments through the same platform.
Fitting Your Audit Window
Timed to your observation period, not ours
For a Type II report, the test should land inside your observation window, with enough runway to remediate and retest the findings that matter before the auditor closes the period. We scope engagements around that calendar: test, remediate, retest, and hand your auditor a clean evidence chain. If you run testing annually, we keep scope and methodology consistent year-over-year so your reports are comparable.
Typical cadence: a full penetration test annually or after significant changes, with retests as fixes land. Because findings, retests, and risk acceptance live in our platform, the evidence your auditor requests in month eleven takes minutes to produce, not a week of email archaeology. See how our PTaaS delivery works.
FAQ
SOC 2 penetration testing questions
Does SOC 2 explicitly require a penetration test?
No. The Trust Services Criteria never name penetration testing; they require you to evaluate and monitor controls (see CC4.1 and CC7.1). In practice, most auditors expect a recent penetration test as evidence those controls work, and the customers who requested your SOC 2 report usually expect one too. Treating it as required is the safe, and now standard, interpretation.
How often should we test for SOC 2?
Annually at minimum, plus after significant changes to in-scope systems. For a Type II report, schedule the test inside your observation window with enough time left to remediate and retest important findings before the period closes.
Will the report satisfy my auditor?
That's the design goal. Reports include scope, methodology, tester qualifications, findings with severity and evidence, and remediation guidance. Because engagements run through our platform, remediation status, retest results, and risk acceptance decisions are all documented and exportable when the auditor asks.
Can you retest after we fix findings?
Yes, retesting is built into the engagement rather than sold as a new project. Your team fixes a finding, requests a retest from the portal, and the verification lands in the same record an auditor will review.
We also need PCI or HIPAA coverage. Same engagement?
Often, yes. Scope can be designed so one testing program produces evidence for multiple frameworks. See our PCI DSS penetration testing page and our healthcare security program for the specifics of each.
Get audit-ready on schedule
Tell us your observation window and what's in scope. We'll come back with a plan that fits the audit, not the other way around.