The word "readiness" in "SOC 2 audit readiness" gets used to mean two different things, and conflating them is what makes first-time audits so painful.
The first meaning is documentation readiness: do you have the policies, procedures, system descriptions, and org charts that a SOC 2 audit requires? The second is operational readiness: were the controls those documents describe actually operating throughout your audit period? You can have every policy document in place and still fail a SOC 2 Type II because the controls weren't running as described.
Most "audit readiness" content focuses heavily on the first type and barely touches the second. This checklist is organized to address both — and to be explicit about where early-stage SaaS teams typically have gaps in each category.
Before You Start: Scoping Decisions That Affect Everything Else
The scope of your SOC 2 audit determines what controls you need to have in place and what evidence you need to collect. Two decisions made before your audit period begins shape your entire readiness posture.
Which Trust Service Categories are in scope? Security (Common Criteria) is always included. Availability, Confidentiality, Processing Integrity, and Privacy are optional. Most early-stage B2B SaaS companies pursue Security + Availability. If your customers are healthcare companies, Confidentiality and Privacy may be required. Adding categories adds criteria, and each additional criterion is more controls to demonstrate, more evidence to collect.
What systems are in scope? The audit covers your "system" as defined in your system description. If you host customer data across three AWS accounts and a third-party payment processor, you need to decide which components are in scope and how to handle the payment processor (typically through a subservice organization carve-in or carve-out). Scope creep at the last minute — "oh, we should probably include that data warehouse" — is one of the most common sources of first-audit pain.
These decisions should be made before your audit window opens, ideally with input from the CPA firm that will be doing the audit. Most firms offer a pre-audit scope consultation, and the money spent there is well worth it.
Documentation Readiness: The Policy and Procedure Layer
The following documents need to exist, be current (reviewed within the last 12 months), and be accessible to your audit team. None of these need to be long — a five-page information security policy is better than a fifty-page one that nobody has read, because a short policy is more likely to actually be followed.
- Information Security Policy. Covers data classification, acceptable use, incident response responsibilities. References your other policies by title. Ownership: usually CEO or Head of Security for a small team.
- Access Control Policy. How access to systems is provisioned, who can approve it, how it's revoked when employment ends, and how privileged access is managed differently from standard access.
- Change Management Policy. What counts as a "change" that requires formal tracking, what the approval process is, and what the testing requirements are before changes reach production.
- Incident Response Plan. How the team identifies, responds to, and documents security incidents. Needs to include escalation paths, communication templates, and a post-mortem process. The plan doesn't need to be elaborate — it needs to be practiced at least once (a tabletop exercise qualifies).
- Vendor Risk Management Policy. How the company evaluates security posture of vendors with access to its systems or customer data. Ties into CC9.2 requirements.
- Business Continuity and Disaster Recovery Plan. Relevant primarily for Availability category, but increasingly auditors review BC/DR for Security as well. For a small team, this can be relatively lightweight — what happens if your primary data center region goes down?
- Risk Assessment documentation. See our separate post on risk registers for what this needs to contain. Must show evidence of ongoing review, not just an initial creation date.
Operational Readiness: The Controls That Actually Need to Be Running
This is the harder half. For a SOC 2 Type II with a 12-month audit period, you need evidence that each of these controls was operating throughout that period — not just on the day of the audit.
Access provisioning and deprovisioning. Every new employee or contractor who received access to production systems during the audit period should have a provisioning record showing who approved the access. Every departure should have a corresponding access revocation. The standard that auditors test against: was access removed within one business day of employment ending? Longer than that invites a finding under CC6.2.
Multi-factor authentication. MFA should be enforced for all users with access to production systems, administrative interfaces, and cloud infrastructure. "Enforced" means technically required — not just recommended. An IdP configuration export showing MFA enforcement across your user base is the evidence. Check this configuration regularly; MFA requirements can be accidentally bypassed during SSO integrations or when new services are added to scope.
Quarterly access reviews. CC6.3 requires periodic reviews of who has access to what. Industry practice is quarterly. The review needs to be documented: a list of reviewers, users reviewed, date completed, and any accounts that were removed as a result. A review where nothing was removed is still a valid review — it shows the list was examined and found appropriate. A review with no documentation isn't a review for audit purposes.
Encryption at rest and in transit. For cloud infrastructure: evidence that storage volumes, databases, and backups are encrypted at rest; evidence that data in transit is encrypted via TLS 1.2 or higher. The evidence is typically a configuration export from your cloud provider. For new services added during the audit period, verify that encryption defaults are set correctly at provisioning time.
Logging and monitoring. CloudTrail (or equivalent) enabled and retained, application logs captured, and some process for reviewing logs for anomalies. Auditors test this by asking: if a suspicious event occurred on a specific date in your audit window, could you produce the relevant logs? If the answer is "logs are retained for 30 days and the event was four months ago," that's a gap.
Vulnerability management. A process for identifying and remediating vulnerabilities in your codebase and infrastructure. This doesn't require a dedicated security engineering team — it requires evidence that you ran scans, reviewed results, and addressed material findings within a defined timeframe.
A Note on Audit Window Timing
We're not saying you need all of this in place from day one of your company's existence. We're saying you need it in place before your audit period begins. If your audit window is January 1 through December 31, your access review cadence needs to have started before January 1. Your logging retention needs to go back to at least January 1. Your policies need to have been in effect before January 1.
The implication: if you decide in September that you want a SOC 2 report and you engage an auditor to cover October through September of the following year, you have until October to get your controls in place. Not October to start getting them in place — October for them to be operating. That's a meaningful distinction and one that causes timeline surprises for teams that haven't done this before.
What Good Looks Like at 18 Months In
A typical scenario: a B2B workflow automation SaaS, around $1.8M ARR, seven employees, preparing for their first Type II audit with an October window start. They had all their documentation in place by September but discovered in October that their access review process had never been formally documented — they'd been doing informal reviews in a spreadsheet that nobody had saved. They had to reconstruct evidence from Slack messages and email threads, which the auditor accepted but flagged as a process improvement recommendation.
By their second audit, they had a structured quarterly access review process with a Jira ticket template, a one-click export from their IdP for the user list, and a completed review document filed in a shared drive within five days of each review date. The auditor's CC6.3 sample took fifteen minutes instead of a day.
That's what audit readiness actually looks like — not a checklist completed once before an audit, but a set of processes running continuously throughout your audit period, producing evidence automatically rather than by reconstruction.