If you’re a Founder or CTO, SOC 2 can quickly turn into a game of telephone: sales says “we need SOC 2,” a customer says “we need a pen test,” an auditor asks for “security testing evidence,” and suddenly you’re buying a report without knowing what it’s supposed to prove.
This post will help you scope a penetration test that (1) supports a SOC 2 audit and customer due diligence, and (2) produces findings your engineers can actually fix.
If you’re building this into an ongoing program (not a once-a-year scramble), you’ll also want a plan for how testing, remediation, and ownership work over time. Our longer take is in Building an AppSec Program.
Does SOC 2 Require Penetration Testing?
SOC 2 is not like PCI DSS. PCI is prescriptive and explicitly calls out penetration testing requirements for certain environments (see our breakdown of PCI DSS pentesting requirements). SOC 2 is principle- and risk-based.
That means you can’t rely on a single line that says “SOC 2 requires an annual penetration test.” But you also can’t ignore security testing entirely and expect a smooth audit or customer review process. In practice, most SOC 2 programs end up needing some combination of:
- Vulnerability management (ongoing scanning + remediation)
- Targeted penetration testing (manual validation of higher-risk systems and attack paths)
- Change-driven testing (after meaningful changes that alter the attack surface)
If you’re stuck on the decision of what to buy, start here: Penetration testing vs vulnerability scanning.
What Auditors Typically Expect to See (Evidence That Tells a Coherent Story)
Auditors generally aren’t grading you on how “cool” your pen test is. They’re looking for evidence that your controls are designed and operating effectively, and that you follow through when you identify risk.
Here’s what typically makes an auditor (and enterprise customers) happy:
1. A reasonable testing strategy tied to risk
You should be able to explain, in plain English:
- What you test (apps, APIs, infrastructure, cloud, internal network)
- How often you test (cadence)
- Why the scope makes sense for your business and data
- How you decide what’s in/out (scope rationale)
2. A report that is clearly in-scope and reproducible
A useful penetration test report usually includes:
- Scope (systems, environments, dates, constraints)
- Methodology (high level approach; manual testing vs scanning; validation practices)
- Findings with evidence and impact (not just “potential issues”)
- Remediation guidance (developer-ready, stack-aware)
- Retest / validation of fixes (or a clear plan for when/how it will happen)
3. Proof that you acted on results
This is where teams get burned. A report by itself is not “control operation.” Auditors and customers often want to see:
- A remediation plan / ticket trail
- Ownership and timelines
- Evidence that high-risk issues were fixed or mitigated
- Retest results (or compensating controls if you can’t fix immediately)
Pen Test vs Vulnerability Scanning (Where Each Fits in a SOC 2 Program)
These get confused constantly:
- Vulnerability scanning is broad, repeatable, and great for hygiene. It’s not designed to prove impact.
- Penetration testing is manual, judgment-based, and designed to validate exploitability and prioritize what matters.
Most SOC 2 programs need both. If your budget is tight, prioritize based on risk:
- If you ship a customer-facing application with auth and sensitive data, an application/API pen test usually creates the most value.
- If your footprint is huge and you’re missing baseline hygiene, scanning + remediation may be the right first move.
How to Scope a SOC 2-Aligned Pen Test (Founder/CTO Playbook)
The scope you choose determines whether the engagement produces signal or noise. The goal is not “test everything.” The goal is “test the things that would hurt if breached.”
1. Start with crown jewels and attack paths
Make a short list:
- What data would be catastrophic to leak? (customer data, secrets, financials)
- What actions would be catastrophic to perform? (admin actions, payouts, provisioning)
- What systems control access? (SSO, auth service, identity provider, CI/CD, cloud IAM)
- What integrations could be abused? (webhooks, third-party apps, support tools)
Then scope testing around the attack paths to those assets.
2. Pick the right testing types
Most SOC 2-driven engagements fall into these buckets:
- Application/API penetration testing: business logic, authorization, session handling, data access boundaries.
- If this is your primary risk, consider application penetration testing.
- Cloud penetration testing: IAM, permissions, metadata, secrets, storage exposure, lateral movement.
- If you’re cloud-heavy, consider cloud penetration testing.
- External network testing: internet-exposed assets, edge services, misconfigurations.
- Internal testing (sometimes): relevant if you have meaningful internal attack surface and need to model an assumed breach.
A “SOC 2 pen test” is usually a mix of the above—picked based on where your real risk is.
3. Decide environments: production vs staging
Balanced guidance:
- Production is where you find the real issues, but it requires strict rules of engagement.
- Staging is safer, but only useful if it’s truly representative (same auth, same data flows, same configs).
If your staging is “kind of like prod,” you can end up with a clean report that doesn’t match reality.
4. Define cadence (and what “after significant change” means)
SOC 2 doesn’t hand you a cadence, so set one you can defend.
A practical approach:
- Annual testing for your core product (common expectation in buyer due diligence).
- Change-driven testing when the attack surface materially changes, for example:
- major auth/SSO changes
- new high-risk features (billing, admin, role model changes)
- new infrastructure patterns (Kubernetes migration, new cloud account structure)
- major new integrations or data flows
The goal is to be able to explain “we test again when risk changes,” not to test endlessly.
5. Scope deliverables and communication up front
Set expectations before kickoff:
- How critical findings are escalated during the test
- Whether you get direct access to testers for questions
- When you’ll receive a report and whether a readout is included
- Whether retesting is included and the time window
If you want a practical prep checklist you can hand your team, use: How to prepare for a penetration test.
Common Mistakes That Create Audit (and Customer) Pain
- Buying a scanner report and calling it a pen test. You’ll get volume, not validated risk.
- Over-scoping without remediation capacity. A 60-finding report isn’t “more secure” if nothing gets fixed.
- No retest / validation plan. Customers and auditors care that issues were addressed.
- Unclear scope rationale. If you can’t explain why something is in/out, someone will question it.
- Staging that doesn’t match production. Leads to misleading “clean” results.
None of these are fatal. They’re just expensive.
Copy/Paste: SOC 2 Pen Test Scoping Checklist
Use this as a starting point for an SOW or internal scoping doc:
- Objective: what question are we answering (e.g., “can an external attacker access customer data?”)
- In-scope assets: apps/APIs, URLs, IP ranges, repos/services
- Environments: prod vs staging; constraints and test windows
- Auth model: SSO/IdP, roles, test accounts, MFA constraints
- Integrations: third parties, webhooks, support/admin tooling
- Cloud/IAM (if applicable): accounts/projects, IAM boundaries, CI/CD, secrets stores
- Deliverables: report contents, evidence expectations, readout, retest terms
- Comms: escalation path for critical findings; points of contact
- Rules of engagement: no-go systems, safe exploitation boundaries, data handling
Conclusion
SOC 2 goes smoother when your security testing tells a coherent story: you picked a scope based on risk, you tested in a way that produces real signal, and you followed through on remediation.
If you want help scoping a SOC 2-aligned engagement that’s useful to engineers and audit-friendly, take a look at our penetration testing services or contact us.