SOC 2 in 8 weeks: the pentester's playbook

Every SOC 2 readiness guide says the same three things. Pick a framework. Buy a compliance platform. Hire a consulting firm. The advice is not wrong, but it skips the only part that actually predicts whether you pass: knowing what your security posture really is before you start chasing an audit date.

I have walked into too many companies on week 4 of a 12-week sprint to find that no one has ever run a vulnerability scan against production, let alone a pentest. The auditor never asked because SOC 2 does not require it. The CTO never asked because the compliance platform was green. That is the moment the audit timeline doubles, the budget doubles, and the team starts wondering what they actually paid the platform vendor for.

This post is the order I run every SOC 2 Sprint. It works because it sequences the work to minimize rework, and because I run a pentest in week 1 instead of pretending the audit will catch what the audit was never designed to catch.

Why the typical 12-week SOC 2 sprint takes 16 weeks

The standard sequence is: pick a framework, gap-assess against it, write the policies, push them out, collect evidence, audit. It looks logical on a Gantt chart. In practice it produces a pile of policies that describe an architecture nobody has actually deployed.

The most expensive failure mode is policy-reality mismatch. Your access management policy says all production access is via SSO with MFA. Your reality is a backend engineer who SSHs into a bastion host with a shared key from 2022. The auditor's evidence request will surface this in week 9 of a 12-week sprint, and now you are rewriting both the policy and the access architecture under deadline pressure.

The fix is to know what is true before you write what should be true.

Week 1 is technical reality, not policy

Before I touch a single Trust Services Criterion, I want a complete picture of what is actually deployed. The week-1 inventory covers everything that could end up in audit scope:

• Every cloud account, including the ones the founder forgot about
• Every code repository, including the personal GitHub account that still hosts the original prototype
• Every SaaS vendor with access to production data
• Every endpoint that ever holds a customer record, including developer laptops
• Every human or service principal that can reach production

One day with the engineering lead and a screen-share is usually enough. The output is a single document I call the in-scope inventory. Everything we write in weeks 2 through 8 traces back to it.

This is also where I run the week-1 pentest. Eight to twelve hours of focused offensive testing against the authentication flow, the API surface, and the most common web application vulnerabilities. The point is not a full engagement. The point is to find the things that would otherwise show up in week 9 as a critical finding from a customer's third-party assessment.

Week 2 is policy gap analysis, not policy writing

Now that the inventory is real, the policy work is mechanical. The Trust Services Criteria break down into roughly 60 testable controls. For each one, the question is: do we already do this, do we partially do this, or do we not do this. Three buckets, no narrative.

Most firms produce a 200-page gap analysis at this stage. I produce a five-page one because the only thing that matters is the bucket. We do not need rich prose to know that the access review has not happened in two years.

The output is a remediation backlog ordered by risk and effort, not by control number, not by criterion, not by what the platform's UI orders them in. Ordered by what is most likely to fail an audit and how long it will take to fix.

Weeks 3 through 5: remediation in priority order

This is where most teams want to start, and where most teams burn time. If you start remediation before the inventory and the gap analysis are done, you will fix things that nobody is going to test, and you will miss things that absolutely will be tested.

Remediation work in this phase falls into three categories:

• Technical fixes: turn on MFA, rotate stale credentials, enforce CIS benchmarks on cloud accounts
• Process fixes: stand up access review, set up vendor risk reviews, document the change-management workflow
• Evidence fixes: configure logging that you can actually point an auditor at in 90 days

I run remediation in two-week sprints with a twice-weekly standup, because the goal is to ship the fix and prove it ships, not to write a status report. The auditor does not care about status. The auditor cares about whether the control was operating during the audit period.

Weeks 6 and 7: evidence is what gets you the report

The thing nobody tells founders is that SOC 2 is not about whether you have controls. It is about whether you can prove the controls operated for the entire audit period. If your access review policy says quarterly and the auditor wants to see four quarters but you started doing them last month, you have an audit finding even if the control is real.

This is why I push evidence collection as early as possible, ideally week 5 not week 7. Anything I can prove was operating in week 1 is six weeks of audit period in the bag. Anything I cannot prove until week 7 is one week of audit period and a likely qualified opinion.

For each control, I make sure there is a single source of truth for evidence. Access reviews go in a signed PDF in the GRC platform. Logging is a retention policy in CloudWatch with a screenshot of the configuration. Vendor risk is an updated vendor inventory with risk ratings and review dates. Boring, repeatable, provable.

Week 8 is the fire drill

Something always goes wrong in the last week. A missing MFA enforcement on an admin panel nobody remembered. A terminated employee still in GitHub or AWS IAM. A vendor BAA that expired six months ago. An incident in March that was never logged in the incident tracker because it did not seem like an incident at the time.

I leave a week for this on purpose. Without a fire drill week, you find these in audit fieldwork instead, and they cost ten times as much to remediate under deadline pressure.

The three things that will blow up your audit

Across every Sprint I have run, the same three issues turn up over and over. Fix all three before week 1 if you can.

An undocumented production access path

There is always a way into production that is not on the access management policy. The DevOps engineer who SSHs from a personal laptop. The shared root password in 1Password that three engineers have access to. The legacy support tool that bypasses SSO entirely. Find this before the auditor finds it.

A backup strategy nobody has ever restored from

You take backups. You probably even verify the backups complete successfully. But you have almost certainly never restored from one in production. The auditor will ask. The reality is that a meaningful share of restore attempts fail the first time. Test it now, fail in your own test environment, fix it, then put the test in your runbook on a quarterly cadence.

An incident response plan that has never been tested

Your IR plan calls for the security lead to be reached on a phone number that has been disconnected since the last reorg. The Slack channel for incident coordination is in a workspace half the responders do not have access to. The legal escalation path goes to a former in-house counsel. None of this surfaces in a policy review. All of it surfaces in an actual incident or a realistic tabletop. Run a 2-hour tabletop. Find the gaps. Fix them.

Where the pentester's perspective actually matters

Here is why I think more SOC 2 readiness firms should employ pentesters, and why I price my Sprint at $2,500 instead of the $1,500 most readiness-only assessments charge.

The auditor checks whether you have a vulnerability management policy. The pentester checks whether your vulnerability management policy is being followed. Only one of those matters if you get breached.

When I run the week-1 pentest, I find things that would be invisible to a paper-based readiness assessment. Authentication flaws no policy review would surface. Access control issues in the API that the architecture diagram does not reveal. Default credentials in a system the inventory missed. These find their way into the remediation backlog where they belong, instead of into a customer's pentest report after a 6-month deal cycle.

Including the pentest also means the Sprint deliverable is evidence of more than compliance. It is evidence of capability. The next enterprise prospect that asks for proof of security gets a SOC 2 readiness report and a pentest summary. Same engagement, same firm, no separate procurement.

When 8 weeks is not enough

Eight weeks is the minimum to do this well. It is not the right timeline for everyone. If your engineering team is shipping product features full-time and security work has to fit in around them, expect 12 to 14 weeks. If your auditor wants a longer audit period for a Type 2, plan accordingly. If your compliance platform is in a state of chaos because nobody has owned it for a year, the first two weeks turn into hygiene rather than discovery.

I have run Sprints in 6 weeks. Those engagements work because the team had already done the technical-reality work I described in week 1, and we used the Sprint for policy alignment and audit prep only. They are the exception, not the model.

What to do this week

If you are 90 days from your target audit date and starting from zero, here is the smallest useful thing you can do this week. Build the in-scope inventory. Cloud accounts, repos, vendors, people. One Google Doc, five hours of work. Without this, the next eight weeks will produce documents that describe a system that does not exist.