A pentest scoped to your SOC 2 system description, run by a named senior engineer, with CVSS-rated findings, retest evidence, and an attestation letter. The format auditors have asked for since the 2024 trust-services-criteria update.
SOC 2 does not mandate a pentest by name, but four Trust Services Criteria routinely require one to pass fieldwork. Your auditor will ask for evidence under each.
Requires demonstrating that access restrictions actually work, not just that policies exist. A pentest against authentication, authorization, and privilege escalation paths satisfies this. Scanner output alone does not.
Data transmitted externally must be protected against unauthorized access. Encryption testing, TLS configuration review, and API security findings cover this criterion directly.
Requires validation that monitoring and detection controls catch what they claim to catch. Covered by our engagement timeline documentation and, for detection-focused engagements, a red team readout.
Changes must be tested before production. A pre-launch pentest satisfies this directly. For ongoing SOC 2 programs, annual retesting closes the control gap each period.
Every SOC 2 pentest engagement produces the five artifacts auditors ask for by name. Formatted for fieldwork, not for internal use.
Scope follows your system description. Most SOC 2 pentests cover application, API, and network layers. Cloud configuration and admin access paths are commonly added.
Authenticated and unauthenticated paths. Authentication logic, session handling, authorization flaws, business logic, third-party integrations. OWASP WSTG aligned.
Often the highest-risk surface in a SOC 2 scope. Internal tools frequently lack the same review cycle as the customer-facing product.
Exposed services, port survey, TLS configuration, certificate hygiene. What an external attacker sees before they reach your application.
S3 / GCS / Blob storage permissions, IAM policy review, metadata-service exposure, logging gaps. Common finding in SaaS SOC 2 audits.
Hardcoded secrets, exposed environment variables, leaked credentials in public repos, overprivileged service accounts. Each one is a CC6.1 finding.
OAuth flows, webhook trust, outbound API key storage and rotation. Third-party access is in scope for CC6.1 and often missed in vendor-led assessments.
Timing matters for SOC 2. Getting this wrong costs a month of audit delay.
Auditors typically accept a pentest from within the past 12 months, sometimes 18 months if nothing material changed. Run it at least 6 weeks before your audit kick-off so remediation and retest can complete.
The pentest must fall within the audit period. Most Type II windows are 6 or 12 months. If your period is January–December, the test should run between February and October to leave room for retest.
Auditors expect a new test when the system description changes materially (new product, new data types, acquired infrastructure). Don't reuse last year's report on a different system.
Some clients run us annually on a fixed window. We track what changed since the previous test, reuse context efficiently, and issue a clean report each year. Engagement cost goes down over time as the surface stabilizes.
Questions that come up on every SOC 2 scoping call. See our field notes on SOC 2 audit evidence for more detail.
CC6.1 (logical access controls), CC7.1 (anomaly detection), and CC8.1 (change management) are the most commonly cited. Your auditor may also reference CC6.6 (external transmission) and CC9.1 (risk assessment) depending on the firm and the trust service categories in scope.
Not explicitly by name. But most auditors expect one within the audit period for a Type II. Type I audits sometimes accept a recent test from before the period. As of 2025–2026, auditors are enforcing the timing requirement more strictly than in previous cycles.
Named methodology, named engineer, scope matched to your system description, CVSS-based severity ratings, retest evidence, and an attestation letter. All six. Missing any one of them can delay issuance by weeks. We cover all six in every engagement.
Open findings are not automatically a problem if they are documented with a risk-acceptance memo signed by an executive and a remediation timeline. What auditors reject is undocumented open findings with no owner. We help you structure accepted-risk documentation that passes review.
Yes. We often pair a pentest with a compliance gap analysis for teams going through their first SOC 2. The gap analysis maps all TSC controls, the pentest covers the technical testing evidence. Both deliverables go to the auditor together.
Most web and API SOC 2 pentests run 2 to 3 weeks. Add a week for retest after remediation. End to end from kickoff to clean retest report: 4 to 6 weeks. Scope calls usually run a week before kickoff. Plan 7 to 8 weeks before your audit fieldwork starts.
30-minute scoping call covers your audit deadline, system description scope, and what your auditor will ask for. Free. No NDA required for the first call.