How to Prepare for a SOC 2 Audit: 90-Day Plan

Overview

A 90-day SOC 2 preparation plan is achievable for most B2B SaaS companies with 10–100 employees. It gets you to SOC 2 Type I — an auditor's opinion on whether your controls are suitably designed. To reach SOC 2 Type II (controls operating effectively over time), you need an additional 6-month observation period.

The 90-day plan assumes: you are starting with minimal formal security documentation, your infrastructure runs on AWS (or similar), and you have dedicated internal ownership (typically a Head of Engineering, CTO, or compliance-focused operations lead).

Weeks 1–2: Gap Analysis

Start by mapping your current state against the SOC 2 Security Trust Services Criteria (CC1–CC9). For each criterion, answer: "Do we have a documented control? Is it implemented? Is there evidence?" This produces your gap list.

Typical gaps at this stage: no formal access review process, no documented incident response plan, no vendor risk review procedure, no penetration testing history, and no formal change management documentation.

Use a spreadsheet or compliance automation tool (AuditPath includes a gap analysis dashboard) to track each gap with an owner and target completion date. Prioritise based on audit risk — access management and logging gaps are typically higher priority than procedural gaps.

Weeks 3–6: Policy Writing and Control Implementation

Policy writing is typically the most time-consuming phase. You need a minimum of these policies for a SOC 2 Type I: Information Security Policy, Access Control Policy, Change Management Policy, Incident Response Policy, Vendor Management Policy, Risk Assessment Policy, and Acceptable Use Policy.

Each policy should be 2–5 pages, written in plain language, approved by a senior leader, and stored in a version-controlled location accessible to auditors. Do not copy-paste generic templates without customising them — auditors will ask questions that require specific knowledge of your policies.

Simultaneously implement missing controls: enable MFA on all accounts (AWS, GitHub, Google Workspace), configure CloudTrail in all regions, enable GuardDuty, set up a formal access review calendar, and establish your change management process in your ticketing system (Jira, Linear, etc.).

Weeks 7–10: Evidence Collection

Begin collecting evidence as soon as controls are live. For a Type I audit, you need evidence that demonstrates controls exist and are designed effectively at the audit date. For Type II (ongoing), you need evidence from throughout the observation period.

Key evidence types: access control screenshots (IAM user list with MFA status, GitHub SSO settings), logging configuration (CloudTrail enabled, log retention settings), security scan results (Prowler or AWS Security Hub CIS report), incident response test run documentation, and access review completion records.

Organise evidence by control in your compliance tool. Each control needs: the control description, one or more evidence items, an evidence owner, and the last updated date. Do not create a dump folder of screenshots — auditors need evidence mapped to specific controls.

Weeks 11–12: Auditor Readiness

Schedule a pre-audit walkthrough with your auditor. Walk through each criterion and confirm: what is your control, who owns it, what evidence demonstrates it? Flag any areas where your documentation is incomplete.

Brief your engineering team on what to expect during fieldwork. Auditors will send evidence requests (typically via a shared folder or your compliance tool), conduct brief interviews (15–30 minutes) with engineers and operations staff about specific controls, and may review system configurations directly.

Prepare your system description document (Section III of the SOC 2 report). This 3–8 page document describes your service, infrastructure components, and the boundaries of your system. Your auditor will review and use this as the basis for their report.

Tools and Automation

Compliance automation tools like AuditPath significantly reduce the time required for evidence collection and control tracking. Integration with AWS automatically pulls IAM user status, CloudTrail configuration, GuardDuty alerts, and S3 bucket policies — replacing hours of manual screenshot-taking.

For documentation: use Google Docs or Confluence for policies (with version history), GitHub for runbooks, and your compliance tool for evidence storage and control tracking.

For access reviews: a simple quarterly Jira ticket with a checklist of active users to verify is sufficient at early stage. Document the reviewer, date, and any changes made as a result.

Common Mistakes

Mistake 1: Writing policies that do not match your actual practices. Auditors will compare your policies to your actual evidence. If your access control policy says "MFA required for all users" but your AWS IAM shows 3 users without MFA, that is a control gap that appears in the report.

Mistake 2: Starting the observation period too late. For Type II, every day you delay starting the observation period is a day your report delivery gets pushed back. Start operating controls and documenting evidence from day one.

Mistake 3: Treating SOC 2 as a one-time project. It is an ongoing programme. Build sustainable processes that can be repeated — because you will need to repeat them every year.