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.

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 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 your stated commitments.

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

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.

Fix before engaging: Run a structured risk assessment covering your top assets, threats, and mitigating controls. Document it. Date it. Assign ownership. Plan to repeat it at least annually.

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 check for new vendor SOC 2 reports annually.

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 evidence of that happening.

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 and test it's actually followed.

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.

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

7. Run a Vulnerability Management Program

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

Fix before engaging: Run your first vulnerability scan before the audit window opens. Triage findings. Document a remediation SLA (e.g., critical: 30 days, high: 90 days). Fix what you can. Track the rest.

8. Implement Encryption at Rest and in Transit

This is table stakes, but auditors will verify it. All customer data should be encrypted at rest using AES-256 (or equivalent), and all data in transit should use TLS 1.2 or higher.

Fix before engaging: Audit every data store for encryption configuration. Scan your web endpoints with SSL Labs to confirm TLS versions and cipher suites. Fix anything below TLS 1.2.

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.

Fix before engaging: Write an incident response plan. It doesn't have to be 40 pages. It has to answer: How do we detect incidents? Who gets called? What do we contain first? When do we notify customers? 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 this to any contractual commitments in your MSA or DPA.

11. Implement and Test Business Continuity Controls

Availability Trust Service Criteria require that you can demonstrate your service will remain available and recoverable. That means tested backups — not just configured ones.

Fix before engaging: Test your database restore process. Measure your actual RTO and RPO. Document the results. Configure backup monitoring so failures alert before you discover them during an incident.

12. Formalize Your Security Policies

Policies are the foundation auditors test controls against. You need written, approved policies for: Information Security, Acceptable Use, Access Control, Incident Response, Change Management, and Vendor Management — at minimum.

Fix before engaging: Draft the core policy set. Have them reviewed and approved by leadership. Version-control them and establish an annual review cycle. Employees need to have acknowledged them — with evidence.

How Long Does Readiness Take?

For an early-stage SaaS company with no formal security program, six to nine months is realistic. For a company that already has infrastructure in place but lacks documentation and process formalization, three to four months is achievable with focus.

The most common mistake is treating readiness as something you do 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.

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 tracked remediation.

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.