SOC 2 prep timing

When to get a penetration test before SOC 2

SOC 2 doesn't list a penetration test as a required control, but almost every auditor asks for one anyway. Get the timing wrong and you lose the one thing you can't buy back once fieldwork starts: time to actually fix what the test finds.

Schedule your penetration test 60-90 days before your SOC 2 audit start date, not the week before. That gap gives you time to fix whatever the test finds and get remediation evidence or a re-test done before your auditor looks. For Type II audits, run the test before the observation period begins so you’re proving a clean baseline instead of explaining mid-period findings. If an auditor has already asked for a report you don’t have, a real manual test still takes about a week to run, so with three or more weeks left you can usually still close the gap.

Work backward from your audit start date, not forward from today

Why “we’ll get to it before the audit” is the mistake

Most teams don’t skip the pentest on purpose. They just treat it like any other pre-audit item — something to slot in “sometime before fieldwork starts.” The problem is that a useful pentest report isn’t a checkbox you tick by booking a call. It generates findings. High or critical findings — an exposed admin panel, an IDOR that leaks another customer’s data — are exactly what an auditor flags when they see them sitting in a report with no remediation note next to them.

If you test two weeks before your audit starts, you get a report full of open findings and no runway to close them. Either you hand the auditor a report with unresolved critical issues, or you push your audit start date back. Either way, the timing mistake — not the vulnerabilities themselves — is what costs you the extra weeks.

The 60-90 day window, and why that specific range

Work backward from your confirmed audit start date: the fieldwork date for Type I, or the date your observation period begins for Type II. The test itself is the fast part — typically about a week. What eats the calendar is everything after: triaging findings by severity, actually fixing the high and critical ones, and getting a re-test or written remediation evidence for what you closed.

A rough breakdown: about a week for the test itself, a few days to triage and prioritize, one to three weeks to fix high and critical findings, and another week for re-test or remediation evidence. Lean toward the 90-day end if a finding is likely to touch a third-party integration, a payment flow, or anything needing its own code review to fix safely.

Type I vs. Type II changes the calculus

Type I: a point-in-time snapshot, so test right before it

A SOC 2 Type I report attests that your controls were suitably designed and in place as of a single date. Testing 60-90 days out, fixing what’s found, and landing on a clean or remediated report right around the snapshot date is the goal. If you’ve meaningfully changed your auth flow, added a new customer-facing surface, or moved infrastructure providers since the test, treat that as a reason to re-test rather than lean on the old report.

Type II: the observation period is where people get it wrong

Type II is harder to time well because you’re proving your controls operated effectively across an entire window, usually 3 to 12 months. If the test surfaces high or critical findings dated mid-period, your auditor now has to evaluate whether your vulnerability management control was actually working during the window before you fixed it — a harder conversation than “here’s a clean baseline going in.”

The cleaner pattern: run the manual test before the observation period opens, remediate what needs remediating, and let the period start clean. Broader fit-and-frequency questions for a longer Type II window are covered on security audit for startups.

What happens when the auditor asks and you don’t have a report yet

This is the exact scenario people describe on Reddit

It’s common enough that it shows up regularly in threads on r/msp and r/AskNetsec: fieldwork starts, the auditor’s evidence request list includes “most recent penetration test report,” and the team realizes they don’t have one. It’s rarely a deliberate skip — nobody put a firm date on the calendar early enough. The fix isn’t a faster pentest under pressure, it’s an earlier one, planned before anyone’s asking.

Your real options, and how much time changes them

With three-plus weeks before fieldwork, you can usually commission a real manual test, get the report, and fix the most severe findings before the auditor looks — tight, but workable. With less than two weeks, be upfront with your auditor rather than trying to hide the gap. Most auditors will accept a signed statement of work and a firm test date as an interim answer. What doesn’t hold up well is substituting an automated vulnerability scan and calling it a penetration test — auditors who’ve seen a few of these can usually tell the difference. See what a report actually needs to contain if you’re not sure what “real” looks like here.

Building the actual prep timeline

Worth being direct: a penetration test is technical evidence you hand your SOC 2 auditor — it is not a compliance attestation on its own. Only your CPA firm’s auditor can issue the actual SOC 2 report; Bug Circuit doesn’t issue SOC 2, ISO 27001, PCI-DSS, or HIPAA certifications, and we’re not a PCI-DSS Qualified Security Assessor or a HIPAA compliance auditor. A manual pentest finds real, exploitable vulnerabilities — genuinely useful groundwork — but it doesn’t certify compliance by itself.

Here’s the sequence we walk startup customers through, counting backward from the audit start date:

90 days out: confirm your exact audit start date with your auditor and scope the pentest around it
75-80 days out: sign the Authorization to Test and kick off the manual audit
65-70 days out: receive the written report with severity-ranked findings, evidence, and fix steps
55-65 days out: remediate high and critical findings first; track everything else for a normal fix cycle
35-45 days out: request a re-test or written remediation evidence for what you fixed
2 weeks out: package the report, fixes, and re-test confirmation into your evidence set for the auditor
Audit start: hand over a report that shows found-and-fixed, not an open list of vulnerabilities

Common questions

Is penetration testing required for SOC 2?

Not by name. No SOC 2 Trust Services Criteria line item says "you must complete a penetration test." In practice, most auditors treat one as expected evidence for the vulnerability detection and risk mitigation criteria, and will ask for a recent report even though it’s not spelled out as mandatory.

What do people actually say about pentest timing before SOC 2 on Reddit?

Threads on r/msp and r/AskNetsec that ask this question tend to land on the same practical answer: don’t wait for the auditor to ask. The teams describing a scramble almost always waited until fieldwork or the observation period was already underway. The advice that holds up is to treat the pentest as a scheduled milestone with its own lead time for remediation.

What are the SOC 2 penetration testing requirements, exactly?

SOC 2 doesn’t publish a requirements checklist for penetration testing specifically — no mandated scope, frequency, or tester qualification is written into the Trust Services Criteria. What auditors generally expect is a recent test (commonly within the last 12 months), covering your production environment, performed by an independent party, with findings that show resolution or a documented remediation plan.

Does ISO 27001 require a penetration test?

No, similar to SOC 2. ISO 27001’s control set is often pointed to as the reason auditors expect testing, but it doesn’t spell out "penetration test" by name or dictate timing. Certification bodies expect to see technical security testing evidence even though no clause forces a pentest specifically.

What’s the difference between a SOC 2 audit and a penetration test?

A SOC 2 audit is a compliance review: a CPA firm evaluates whether your documented controls exist and, for Type II, operated effectively over a period of time. A penetration test is a technical exercise: a human tester actually tries to break into your systems. They’re related but not interchangeable — the pentest is one piece of technical evidence that can feed into the audit.

What are the 5 stages of a penetration test?

Most manual methodologies follow: reconnaissance, scanning and enumeration, exploitation (confirming real impact, not just theoretical risk), reporting (severity-ranked findings with evidence and fix steps), and remediation verification (a re-test confirming fixes actually closed the gap) — that last stage is often skipped by cheaper providers but is exactly what a SOC 2 auditor wants to see.

How far before my SOC 2 audit should I schedule the pentest?

60 to 90 days before your audit start date (fieldwork for Type I, or the start of the observation period for Type II) is the realistic floor. That covers roughly a week for the test, a few days to triage findings, one to three weeks to fix the high and critical ones, and another week for re-test or remediation evidence.

What if my auditor asks for a pentest report and we don’t have one yet?

Be honest with your auditor rather than scrambling silently. With three or more weeks before fieldwork, you can usually still commission a real manual test and fix the worst findings in time. With less runway, most auditors will accept a signed statement of work and a firm test date as an interim answer. Avoid substituting an automated scan for a real pentest.

Keep reading

Security audits for startupsThe broader SOC 2 fit-and-frequency questions, answered in depth.When a customer asks for a pentest reportWhat a report needs to actually contain.How much a penetration test costsBudget realistically for the test itself.How fast a penetration test runsRealistic turnaround so you can work backward from your audit date.Bug Circuit pricingCircuit and Signal tiers, and what’s included in each.

Need a manual pentest report your SOC 2 auditor will actually accept?

Bug Circuit runs a real manual audit with severity, evidence, and exact fix steps per finding, typically turned around in about a week.

Ready for the full manual audit? See transparent pricing →