SOC 2 Pentest Prep: A SaaS Founder's Guide for 2026

A SOC 2 pentest is not a real attacker simulation. It is an evidence-production exercise wrapped around a real engagement. The auditor needs three things: a scope that matches your system description, a methodology document, and a closed remediation loop. Everything else — the depth of testing, the chained findings, the business logic flaws — that is what makes you actually more secure. The auditor does not see it.

This guide separates the two concerns: what you need to satisfy SOC 2, and what you should actually do to harden the product. I have worked with SaaS founders going through both SOC 2 Type I and Type II audits and watched the same scoping mistakes happen at every stage. Here is the playbook.

Auditors do not read the pentest report cover to cover. They look for five specific artifacts.

1. Methodology document. What standard was followed (OWASP, NIST 800-115, MITRE ATT&CK). What testing types were performed. Hours logged.
2. Scope statement. Which production assets were tested. The scope must match (or be a defensible subset of) the system description in the SOC 2 report.
3. Findings summary. Severity counts and short titles. Auditors look for a structured severity rubric (Critical, High, Medium, Low, Informational).
4. Remediation evidence. For each Critical and High, a documented owner, due date, and verification — typically the retest result.
5. Date of test and date of retest. The interval matters. A 9-month gap between finding and verification is a red flag.

Scope is the most expensive variable in a SOC 2 pentest. Over-scope and you spend $50K on assets the auditor does not care about. Under-scope and the auditor flags it during fieldwork. Here is the minimum viable scope for a typical Series A SaaS:

• Production web application with authentication flow
• Production API (REST or GraphQL) with the same auth
• One representative tenant on each role tier (admin, member, viewer)
• Authentication infrastructure (SSO, OAuth, MFA paths)
• Public-facing infrastructure (the production domain plus subdomains)

For more on what a web app pentest entails, see the service page. For SOC 2, you will also want the general pentest service overview.

1. Hiring a scan-only vendor. The Nessus output with a logo. Will not satisfy a real auditor.
2. Scoping out the API. If the web app is in scope, the API the web app calls is in scope too. Auditors notice.
3. Scoping out the admin panel. If employees access production through it, it is in scope.
4. Testing one role only. Multi-tenant SaaS needs role-based testing. Test admin, member, and viewer at minimum.
5. Running the pentest after the audit period starts. For Type II, the control needs to operate during the period.
6. Treating the report as the deliverable. The deliverable is the remediation cycle. Findings without fix evidence will get flagged.
7. Missing the retest. Most auditors want the retest within 60 to 90 days for Critical findings.
8. Skipping the methodology document. The 2-page methodology is the artifact the auditor reads first.
9. No documented severity rubric. Auditors want a structured Critical/High/Medium/Low scale, not a narrative.
10. Mismatched system description. If the SOC 2 description says "all production services" but the pentest scope says "the marketing site," that is a flag.
11. Letting the contract auto-renew without retest. A 12-month-old pentest is stale. Plan the cadence.
12. Not aligning to ATT&CK. Auditors are increasingly looking for ATT&CK technique IDs in findings — it shows methodology depth.
13. No documented exception process. Some findings cannot be fixed in the audit window. You need a documented exception with rationale, mitigation, and timeline.
14. Wrong vendor for the stage. A Big-4 firm for a seed-stage SaaS is overkill and signals immaturity. A solo Fiverr tester for a Series B is the opposite signal.

Type II is about control operation over time. The auditor wants to see that when a finding lands, a process exists and runs. Here is the remediation cycle that satisfies every Type II auditor we have worked with:

1. Critical: triage within 5 business days, fix and retest within 30 days.
2. High: triage within 10 business days, fix and retest within 60 days.
3. Medium: triage within 30 days, fix or document risk-accept within 90 days.
4. Low: triage within 30 days, batch into the next quarterly release.
5. Informational: document and close.

The remediation timeline lives in a ticket system (Jira, Linear) with owner, due date, and evidence link. The evidence is usually the retest result and a code review or infrastructure change PR. Without this loop, the control is theatre.

You do not want the pentester to file 40 findings for issues you could have fixed yourself in a weekend. Quick pre-engagement hygiene that pays back:

• Run the web app pentest checklist as a pre-engagement self-audit.
• Enable security headers (CSP, HSTS, X-Frame-Options, Referrer-Policy).
• Rotate or disable any test accounts in production.
• Patch dependencies. Run `npm audit` or `pip-audit` and clear high-severity CVEs.
• Enable MFA on every production admin account.
• Audit RBAC: any cross-tenant data access should require a separate auth check, not just URL guessing.
• Rate-limit auth endpoints, password reset, and resource enumeration.
• Document the system architecture diagram for the pentester.

Not every pentest vendor is built for SOC 2 evidence production. Six questions to ask:

• Will your report include an ATT&CK technique ID for each finding?
• Will you include a written methodology that maps to NIST 800-115 or OWASP?
• What is your turnaround on retest evidence?
• What is your standard severity rubric?
• Have you worked with my SOC 2 auditor before? (Vanta, Drata, Secureframe, Thoropass)
• Do you offer a free executive summary suitable for sharing with prospects under NDA?

For comparison, see our breakdown of the best penetration testing companies in Georgia (2026).

A representative engagement: a 12-seat B2B SaaS with a single multi-tenant web app, REST API, and AWS infrastructure. SOC 2 Type II observation period starts in 90 days. Scope: web app, API, and AWS configuration review. Cost: $28K including report and retest. Timeline: 3-week engagement plus 60 days remediation window before the period starts. Findings: 1 critical (cross-tenant data leak via an unscoped list endpoint), 4 high, 11 medium. All criticals and highs closed within the remediation window. The Type II report came back clean a year later.

For more on how we work with SaaS founders, see our SaaS industry page. For an example of the kind of operations-platform engagement that often runs in parallel, see the regional medical billing case study.