Cybersecurity · Security Testing
The auditor's evidence request lands and one line stands out: describe how vulnerabilities are identified and addressed. The AICPA's Trust Services Criteria never name a penetration test, and we won't pretend they do; a SOC 2 examination reports on your controls rather than a checklist of products to buy. A recent, retest-verified pentest is simply the answer auditors accept most readily, and this page is honest about that difference.
Independent quality engineering & cybersecurity since 2020, with 100+ security & quality engineers, delivering on platforms we build and run ourselves.
Audit evidence ages. A Type 2 report covers a review period, so controls have to operate across the whole window rather than merely exist on the day fieldwork starts, and a testing gap discovered mid-examination stalls the enterprise deal the SOC 2 report was meant to unblock.
See a redacted sample report
The structure, depth, and remediation detail your team will receive, with client identity and evidence removed. No form, no email: the download is open.
SOC 2 does not strictly mandate penetration testing. The Trust Services Criteria are control criteria your auditor evaluates your system against. How you demonstrate them is between you and your auditor, and a pentest is the demonstration auditors most often ask to see when the topic is vulnerability identification.
Findings ranked by exploitability with reproduction steps, an executive summary written for non-engineers, and a final report your auditor can consume directly, scoped to the system your SOC 2 report describes.
Remediation is verified and the report reissued with findings closed, so the version your auditor receives already answers the follow-up question.
A Type 1 report addresses control design at a point in time; a Type 2 covers operating effectiveness across a review period. We scope one-time assessments for a Type 1 and recurring cycles that keep evidence current across a Type 2 window and annual renewals.
01
Targets, rules of engagement, and the evidence your examination needs, agreed directly with the engineers who will test.
02
Manual assessment aligned to OWASP, PTES, and NIST SP 800-115; critical findings reach you the day they're demonstrated.
03
Findings ranked by exploitability and impact, each with reproduction steps and remediation guidance.
04
Fixes verified and the report updated, timed so what your auditor sees is closure.
Engagement
Buy it as a scoped project, embed it in your team, or run it as a managed service. The engineers and the governance stay the same, whichever shape fits.
One scoped assessment with a full report and one retest: for a release gate, a customer or audit requirement, or an annual baseline.
Recurring cycles matched to your release cadence, each closed by a retest, so the newest report is never far behind the newest release.
A new application, API, or environment joins the existing program without re-contracting; scoping starts in days.
No, and a vendor who tells you otherwise is misquoting the framework. The AICPA's Trust Services Criteria don't prescribe specific security products or tests; a SOC 2 examination evaluates whether your controls meet the criteria, and your auditor decides what evidence demonstrates that. In practice, auditors regularly ask how vulnerabilities are identified and addressed, and a recent penetration test with verified remediation is the clearest way to answer.
It depends on the report type. A Type 1 examination addresses control design at a point in time, so a completed pentest with retest before that date is what matters. A Type 2 covers operating effectiveness over a review period, so testing should land inside the window, and a standing program keeps evidence current across annual renewals.
Remediation of reported findings is verified and the report updated to 'remediated and retested', the wording auditors expect. Retest scope and window are set in the engagement agreement.
Senior engineers from our own bench: 63% hold industry certifications (CISSP, CEH, eCPPT, ISTQB, AWS). The people who scope your engagement are the people who run it; there is no rotating offshore bench behind the proposal.
Engagements run under NDA, and engineers who handle client data undergo background checks. Findings and reports are shared through channels agreed at scoping and are not retained beyond the period needed to deliver and support the engagement. Data-handling specifics (storage, encryption, retention, and destruction) are documented in your service agreement; see the Trust page for our posture.
This is one stage of a single assurance loop: findings become regression tests, and their indicators become live detections, so a problem, once fixed, can’t quietly come back. A stack of separate vendors has no way to close that loop. See how the loop connects →
Tell us whether it's a Type 1 or a Type 2 and when fieldwork starts. The engagement is scoped so what your auditor reads is closure.