Why Readiness Matters More Than Speed

There's a common pattern in SaaS: a big enterprise prospect sends over a security questionnaire, your sales team panics, and suddenly everyone wants SOC 2 Type II done in 90 days. The pressure to move fast is real. The cost of moving too fast is realer. Working with a SOC 2 compliance consultant or running readiness internally, the answer is the same: build the controls first, then bring in the auditor.

A typical SOC 2 audit engagement runs $30,000–$80,000 depending on scope and auditor. Start the clock before your controls are in place and you're either delaying the report (and the deal) or scrambling to remediate gaps while being observed. Neither outcome is good.

This checklist covers the 12 areas that matter most in the months before you engage your auditor.

The 12-Point Pre-Audit Checklist

1. Define Your Service Commitments and System Description

Your SOC 2 report begins with a description of your system — what it does, who uses it, what infrastructure it runs on, and what commitments you make to customers. This isn't boilerplate. Auditors will test whether your controls actually support what you claim to provide.

Fix before engaging: Draft your system description and have it reviewed by someone who has actually read a SOC 2 report. Map each Trust Service Criteria category (Security, Availability, Confidentiality, etc.) to the commitments you're making to customers in your contracts — not to what you intend to offer someday.

2. Establish a Formal Risk Assessment Process

SOC 2 CC3.1–CC3.4 require you to identify and assess risks to your system objectives. A spreadsheet with "High/Medium/Low" ratings that nobody updates doesn't qualify — and auditors can spot a freshly populated risk register pretty easily.

Before the clock starts: Run a structured risk assessment covering your top assets, threats, and mitigating controls. Document it. Date it. Assign an owner. Plan to repeat it at least annually, because the auditor will ask when the last one happened.

3. Map Your Vendor and Subprocessor Inventory

If your system relies on AWS, Stripe, Twilio, or any other third-party service that handles customer data, auditors will ask how you assess and monitor those vendors. "We trust AWS because everyone uses AWS" is not a vendor management program.

Fix before engaging: Build a complete subprocessor inventory. Document what data each vendor touches, which compliance certifications they hold (SOC 2, ISO 27001, etc.), and how you review their reports. Add a recurring calendar event to pull updated vendor SOC 2 reports annually — this review needs to happen on a schedule, not when someone remembers.

4. Implement Logical Access Controls With Evidence

This is where most early-stage SaaS companies fail hardest. Access controls must be documented and enforced — meaning you can pull a report showing who has access to what, when it was provisioned, and when it was last reviewed.

Fix before engaging: Implement user access reviews (quarterly at minimum). Document your provisioning and deprovisioning process. Enforce MFA on all critical systems. Make sure terminated employees' access is revoked within 24 hours — and that you have a paper trail proving it happened.

5. Establish Change Management Procedures

CC8.1 requires controls over how changes to infrastructure and applications are managed. "We push to main when it's ready" is not a change management process.

Fix before engaging: Implement code review requirements (pull requests with at least one reviewer). Separate production from development environments. Document your deployment process — then verify it's actually being followed, not just described on paper.

6. Configure Security Monitoring and Alerting

Auditors look for evidence that you're actually watching what happens in your environment — login attempts, privilege escalations, configuration changes. If you're not logging them, you can't demonstrate you're monitoring them. "We'd notice if something happened" doesn't satisfy this criterion.

What to configure: Enable CloudTrail (if on AWS), set up centralized log aggregation, and configure alerts for critical security events. Document your incident response procedure so there's something to test when an alert fires.

7. Run a Vulnerability Management Program

SOC 2 doesn't require zero vulnerabilities. It requires evidence that you know what exists, have assessed the risk, and are remediating according to a defined timeline.

What auditors actually want to see: A scan run before the audit window opened, triaged findings with severity ratings, a documented remediation SLA (critical: 30 days, high: 90 days is a defensible baseline), and a tracking log showing what was fixed and when. Fix what you can. Track the rest.

8. Implement Encryption at Rest and in Transit

You probably have this — most teams do. But auditors verify it with evidence, and gaps show up more often than you'd expect, usually in a forgotten data store or an internal service that predates the encryption policy.

Fix before engaging: Audit every data store for encryption configuration. Scan your public endpoints with SSL Labs to confirm TLS versions and cipher suites. Fix anything below TLS 1.2, and document what's encrypted and how.

9. Establish a Formal Incident Response Plan

CC7.3–CC7.5 require a defined process for responding to security events — detection, containment, notification, root cause analysis, and remediation.

The minimum it needs to cover: How do you detect incidents? Who gets called first? What do you contain before anything else? When do customers get notified? Write it down. It doesn't have to be 40 pages — it has to be specific enough that someone could follow it at 2am. Tabletop test it once before your audit window opens.

10. Define Data Retention and Disposal Policies

Auditors will ask what you do with customer data when a contract ends, and how long you keep various data classes. If your answer is "forever, in the same database," that's a gap.

Fix before engaging: Document data retention periods by data class. Implement a tested deletion or anonymization process for offboarded customer data. Map it to any retention commitments in your MSA or DPA — your contracts may already be making promises your system can't keep.

11. Implement and Test Business Continuity Controls

Configured backups are not tested backups. The Availability criteria require evidence of a real restore test — not a screenshot of your backup job completing successfully.

Test it, don't just configure it: Run an actual restore. Measure your real RTO and RPO, not the theoretical numbers from your architecture diagram. Document the results. Set up monitoring so backup failures alert before you discover them during an actual incident.

12. Formalize Your Security Policies

Policies are what auditors test controls against — if a control exists but there's no policy requiring it, that's a gap. You need written, approved policies covering Information Security, Acceptable Use, Access Control, Incident Response, Change Management, and Vendor Management at minimum.

Fix before engaging: Draft the core policy set. Get them reviewed and approved by leadership — not just written by IT and filed away. Version-control them, set an annual review cycle, and collect employee acknowledgments. "We have policies" is not the same as "we can prove employees read them."

How Long Does Readiness Take?

If you're starting from nothing — no formal policies, no access review cadence, no evidence collection — budget six to nine months. If you already have the technical infrastructure in place and just need documentation and process formalization, three to four months is realistic with focus.

The most common mistake is treating readiness as something you run in parallel with the audit. Auditors observe a period of time — typically 3, 6, or 12 months. Controls that weren't in place at the start of that window can't retroactively satisfy the criteria. You can't compress the calendar.

When You're Actually Ready

You're ready to engage an auditor when you can answer "yes" to all 12 items above — and more importantly, when you have evidence for each one. Policies in a shared drive. Access review records in a spreadsheet. CloudTrail logs in S3. Vulnerability scan reports with remediation tracked.

If you'd rather have someone help you get there faster — and make sure you don't spend months preparing for the wrong scope — that's what a fractional vCISO engagement is designed for.

Not sure which SOC report you actually need? See SOC 1 vs SOC 2 vs SOC 3: Which Report Does Your Company Actually Need? For PE-backed companies navigating exit timelines, SOC 2 Type I vs Type II: What PE-Backed Companies Actually Need covers the sequencing question in detail.