CC6.1: Logical access controls
Requires demonstrating that access restrictions work, not just that policies exist. A pentest against authentication, authorization, and privilege escalation paths satisfies this. Scanner output alone does not.
pentest · compliance
SOC 2 penetration testing that auditors accept.
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 ask for in fieldwork.
Does SOC 2 require a penetration test?
Not by name. But four Trust Services Criteria routinely require one to pass fieldwork, and the points of focus for CC4.1 list penetration testing as a separate evaluation. Your auditor will ask for evidence under each.
CC6.6: Boundary protection
Requires protection against threats from sources outside the system boundary. An external test of internet-facing apps, APIs, and infrastructure is the direct evidence. TLS and encryption-in-transit findings map to CC6.7, and we report them there.
CC7.1: Vulnerability detection
Requires procedures that identify configuration changes and newly discovered vulnerabilities. A pentest shows those procedures find what matters. Detection of anomalous activity sits under CC7.2; for detection-focused engagements we add a red team readout.
CC8.1: Change management
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.
Source: 2017 Trust Services Criteria (With Revised Points of Focus, 2022), AICPA.
What the report contains.
Every SOC 2 pentest engagement produces the five artifacts auditors ask for by name. Formatted for fieldwork, not for internal use.
- Scope statement tied to your system description The report names the exact systems, services, and IP ranges we tested, cross-referenced against your SOC 2 system description. Auditors reject reports where scope and system description don't match. We catch this before kickoff.
- Named methodology: PTES + OWASP WSTG Auditors now flag "proprietary methodology" language in fieldwork. We cite PTES for overall structure and OWASP WSTG for web and API surface. Auditors stop asking once they see the methodology section.
- CVSS 4.0 severity ratings Every finding carries a CVSS 4.0 vector and numeric score alongside the plain-language severity tier. Auditors cannot evaluate consistency without a scoring system to point at. Severity without a method behind it gets flagged.
- Retest report with closure evidence After remediation, we re-test each finding and issue a clean retest report. Each finding marked resolved, partially resolved, or accepted (with signed risk-acceptance memo). Retest dated within your audit period.
- Attestation letter signed by the testing engineer One-page letter naming the engineer who ran the test, their certifications, the scope, methodology, and engagement window. This is the artifact auditors attach to the CC6.1 control narrative. We issue it at the end of every engagement.
Typical SOC 2 pentest scope.
Scope follows your system description. Most SOC 2 pentests cover application, API, and network layers. Cloud configuration and admin access paths are commonly added.
Web application and API
Authenticated and unauthenticated paths. Authentication logic, session handling, authorization flaws, business logic, third-party integrations. OWASP WSTG aligned.
Admin consoles and internal tooling
Often the highest-risk surface in a SOC 2 scope. Internal tools frequently lack the same review cycle as the customer-facing product.
Network perimeter
Exposed services, port survey, TLS configuration, certificate hygiene. What an external attacker sees before they reach your application.
Cloud configuration
S3 / GCS / Blob storage permissions, IAM policy review, metadata-service exposure, logging gaps. Common finding in SaaS SOC 2 audits.
Secrets and credential exposure
Hardcoded secrets, exposed environment variables, leaked credentials in public repos, overprivileged service accounts. Each one is a CC6.1 finding.
Third-party integrations
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.
When should you run a SOC 2 pentest?
For a Type II, inside the audit period and early enough to finish remediation and retest; for a Type I, within the prior 12 months and at least 6 weeks before kick-off. Getting this wrong costs a month of audit delay.
Type I audit
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.
Type II audit (annual period)
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.
Post-incident or scope change
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.
Ongoing program
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.
SOC 2 pentest questions.
Questions that come up on every SOC 2 scoping call. See our field notes on SOC 2 audit evidence for more detail.
What SOC 2 criteria require penetration testing?
CC6.1 (logical access controls), CC6.6 (boundary protection), CC7.1 (vulnerability detection), and CC8.1 (change management) are the most commonly cited. Your auditor may also reference CC4.1 (separate evaluations, where the points of focus name penetration testing) and CC6.7 (data in transmission) depending on the firm and the trust service categories in scope.
Does SOC 2 require an annual pentest?
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. Auditors now enforce the timing requirement more strictly than in earlier cycles.
What format does the auditor need?
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.
What if we have open findings at audit time?
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.
Can you do a gap analysis alongside the pentest?
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.
How long does a SOC 2 pentest take?
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.
From our engagements.
What SOC 2 auditors actually accept as pentest evidence in 2026
The format has tightened. Six examples of what passes review, what gets flagged, and what your engineering team can prepare ahead of fieldwork.
Last reviewed .
Pentest before your SOC 2 audit?
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.