SOC 2 penetration testing.
Penetration testing scoped to satisfy what your SOC 2 auditor — and your enterprise customers' security reviews — actually expect to see.
What SOC 2 actually requires.
Here's the part most vendors won't tell you plainly: SOC 2 does not formally require penetration testing. The Trust Services Criteria are outcome-based — they define what your controls need to accomplish, not the specific mechanism you use to prove it.
In practice, that distinction matters less than it sounds like it should. Trust Services Criteria CC4.1 calls for "ongoing and separate evaluations" of your controls, and the AICPA's own supplemental guidance explicitly names penetration testing as an example. Auditors routinely expect it as evidence for CC4.1 and for your vulnerability management controls generally — and increasingly, so do the enterprise customers running their own vendor security reviews before they'll sign a contract with you.
So: not required on paper, but functionally expected in almost every real SOC 2 Type II audit and every serious procurement review that follows one.
How this maps to what we do.
Penetration Testing
A report your auditor recognizes as real evidence for CC4.1 — and one you can hand directly to a prospect's security questionnaire.
IT Audits
Access control and configuration review that supports the broader control environment your SOC 2 report describes.
Phishing & Awareness
Evidence of an active security awareness program — increasingly asked about directly in enterprise due-diligence questionnaires.
Audit window coming up, or a customer asking for a pentest report?
Tell us your timeline — a scoped pentest report is one of the faster things we can turn around.