They Trust Us
What SOC 2 actually requires from you
SOC 2 never lists the words "penetration test". What it does require, through the Trust Services Criteria, is proof that you detect vulnerabilities and fix them: CC4.1 (ongoing monitoring that your controls work) and CC7.1 (detection of vulnerabilities and configuration changes).
In practice, virtually every auditor expects an annual independent pentest as that proof, plus evidence that the findings were fixed. So in real terms, you need:
- An independent, manual pentest of the systems inside your SOC 2 scope, usually once a year
- A report an external auditor can read, not a scanner export
- Documented remediation of every finding, with retest evidence
- Coverage that matches your system boundary: web app, API, and cloud infrastructure
How our pentest maps to SOC 2 controls
Every finding in your report references the exact Trust Services Criterion it affects, so your auditor traces evidence without translation work.
| What the auditor asks | What our report gives them |
|---|---|
| Independent testing of controls CC4.1 | Manual pentest by an external research team, with scope and methodology documented |
| Vulnerability detection CC7.1 | Full-scope testing of web app, API and cloud, including business logic that scanners miss |
| Access and boundary protections CC6.1, CC6.6 | Targeted testing of authentication, authorization, tenant isolation and network boundaries |
| Findings get fixed CC7.3 | Remediation guidance per finding, plus unlimited retests and a report confirming closure |
How long until your auditor has the report
- Week 0Scoping call. We map your SOC 2 system boundary and agree on targets.
- Weeks 1-2Manual testing by senior researchers. You get critical findings as we find them, not at the end.
- Weeks 2-4Audit-ready report delivered: executive summary for the auditor, technical detail for your developers.
- After fixesUnlimited retests and a closure confirmation your auditor accepts as remediation evidence.
2-4 weeks from kickoff to an audit-ready report.
See what the auditor gets
- Every finding ranked by severity, mapped to the Trust Services Criteria
- Remediation guidance your developers can act on
- Unlimited retests, plus a closure note for the audit file
Access control was enforced only in the UI. Any authenticated user could list other projects' files, read restricted comment threads, and call admin-level endpoints directly.
- High3
- Medium2
- Low2
- Informational1
Real researchers, not scanners
Our research team is credited with three CVEs in Kaspersky's TinyCheck, two of them rated critical. That depth is what your pentest gets: people who find what automated tools miss.
Not ready for a call?
Start with the SOC 2 pentest checklist: what auditors ask for, what to put in scope, and how to prepare your remediation evidence. One page, no fluff.
Get your SOC 2 pentest quote
Tell us what you are protecting and when the audit is.
Common questions
Is a penetration test required for SOC 2?
Not by name. SOC 2 requires proof that you detect and remediate vulnerabilities (CC4.1, CC7.1), and an annual independent pentest is the standard way auditors expect to see it done.
How often do we need to retest?
Once a year covers most audits. Test again after major changes to your system boundary, like a new product or a cloud migration.
Does the pentest cover Type I and Type II?
Both. For Type II, schedule the test early in your observation period so the remediation evidence exists inside the audit window.
What does the report itself look like?
See for yourself: we publish real, redacted deliverables, including a web pentest report and a cloud audit. Browse our case studies and show them to your auditor before you commit to anything.





