SOC 2 readiness checklist

This is the SOC 2 readiness guide we wish we’d had on our first audit. It assumes you know what SOC 2 is and that you’ve decided to pursue it. Everything below is the operational work — what to do, in what order, with the gotchas called out.

Aim: a clean Type I report at the end of month 3, and a defensible six-month Type II observation window starting immediately after.

Decide your scope first

Before any work, decide three things.

Trust Services Criteria (TSC) in scope. Every SOC 2 covers Security; you also pick from Availability, Processing Integrity, Confidentiality, and Privacy. Most B2B SaaS companies start with Security only. Adding more TSCs later is straightforward — but adding them mid-engagement is painful.

Type I or Type II first. Type I is point-in-time; Type II covers a 6- or 12-month observation window. (A 3-month “bridge” window exists but most auditors won’t issue one as an initial Type II — it’s usually used to span a gap between two longer windows.) Most teams go Type I → Type II in sequence: Type I lets you sell the report and prove design effectiveness, then Type II proves operating effectiveness over the observation window.

Auditor. The big firms (Big Four, mid-tier) are pricier and slower; boutique SOC 2 firms are faster and cheaper. Both produce reports your customers will accept. The question is what your buyers expect — enterprise procurement teams sometimes care; mid-market rarely does.

If you’re unsure on auditor: ask three customers what their procurement team has accepted recently. The list will be short and consistent.

Subservice organizations. If you run on AWS, GCP, Azure, or any other cloud — they’re a subservice organization, and you have to decide how to handle them in your report:

• Carve-out method (the common choice): your report explicitly excludes the subservice org’s controls. You describe what you rely on them for, and readers are expected to review the subservice org’s own SOC 2 report.
• Inclusive method: their controls are tested as part of your audit. Almost no one does this — it requires the subservice org’s cooperation and inflates scope dramatically.

Pick carve-out unless you have a specific reason not to. Inventory every subservice organization you depend on and what services you use them for; you’ll list these in your system description.

Complementary User Entity Controls (CUECs). What do your customers have to do for your controls to actually work end-to-end? Examples: manage their own user accounts inside your product, configure SSO correctly, rotate their API keys. These get listed in your report and aren’t optional — auditors expect to see them.

Month 1: scope, controls, gaps

The goal of month 1 is to know exactly where you stand.

Week 1 — kickoff

• Pick your scope. TSCs in scope, systems in scope (your product, supporting infrastructure, key SaaS tools), and the personnel boundary (which employees touch in-scope systems).
• Inventory your controls. Use a SOC 2 control matrix as your starting point — most auditors will give you theirs, or use the AICPA TSC criteria. You’re looking for evidence that you have a control for each criterion, not whether the control is currently working.
• Assign control ownership. Every control needs a single accountable owner. Distinguish between operator (who does the work) and owner (who’s accountable for the result).
• Kick off your risk assessment. SOC 2 requires a documented risk assessment (CC3 — identification, analysis, response). It must be reviewed at least annually. If you don’t have one, draft it now: scope, assets, threats, likelihood/impact, mitigations, owners. A structured spreadsheet is fine for a first pass — what matters is that it’s reviewed, approved by leadership, and updated when the business changes. Auditors will ask to see the artifact and evidence that you actually used it (e.g., risks logged, accepted, or escalated during the period).

Week 2 — gap analysis

• Test each control as designed. For each criterion, ask: “If an auditor asked us to demonstrate this, what would we show them?” Score each as Implemented / Partial / Missing.
• Categorize the gaps. Three buckets: (1) we have the control but no evidence; (2) we have the control but it’s not working consistently; (3) we don’t have the control.

The first bucket is the easiest — collect evidence. The second is the hardest — that’s where remediation projects come from.

Week 3 — remediation plan

• Prioritize the missing controls. Focus on access management, change management, and incident response first — these are heavily tested and tend to have cascading dependencies.
• Set due dates. Every gap gets an owner and a target close date inside month 2.
• Identify any controls that need to be in place before your Type II observation window starts. Once that window opens, every assertion must hold continuously — a control implemented mid-window leaves a gap auditors will flag as a deficiency. If you’re targeting a 6-month window starting right after Type I, you want every in-scope control demonstrably operating by the time Type I closes.

Week 4 — close the easy gaps

Anything that’s just missing documentation or evidence: do it now. Examples:

• Write down your incident response procedure if you don’t have one written.
• Document who has admin access to your production systems.
• Capture screenshots of your MFA enforcement settings.
• Get an inventory of vendors with the data they handle.

Don’t write more than you need. SOC 2 expects controls and evidence; it doesn’t expect a 50-page incident response runbook if a 2-page version reflects your actual practice.

Month 2: implement, evidence, vendor agreements

Month 2 is the heaviest operational work.

Implementation

For each missing or partial control, implement the change. Common items:

• Access reviews. Quarterly access reviews of production systems. Document who reviewed, when, what was changed.
• Background checks (if your policy commits to them). SOC 2 doesn’t strictly require background checks, but if your security or HR policy says you do them — and most do — auditors will test against that assertion. Pre-employment checks for in-scope personnel are the common pattern. Document the policy and capture evidence per hire.
• Onboarding/offboarding. Standardized procedures with a checklist. Auditors love checklists with timestamps.
• Vulnerability management. A regular scan cadence (weekly or monthly), a severity-based remediation SLA, and evidence that you actually meet the SLA.
• Vendor due diligence. A risk-based approach — Tier 1 vendors (touch customer data) get full assessments; lower tiers get lighter touch.
• Change management. All production changes go through code review and approval, with a documented process and traceable tickets (commit → ticket → reviewer → deploy). Emergency-change path is separate, with post-incident review. CC8 is its own Common Criterion — auditors will pull a sample of deploys and walk them.
• Logging and monitoring. Centralized log collection from production systems, a documented retention period (commonly 12 months), alerting on security-relevant events (failed auth, privileged actions, config changes), and evidence that someone actually reviews alerts. “We have logs” is not a control; “someone investigated alerts X, Y, Z and dispositioned them” is.
• Encryption. Data encrypted in transit (TLS 1.2+ everywhere — internal traffic too, not just at the edge) and at rest (provider-managed KMS, customer-managed keys, or both). Document the standard, list the systems, and capture configuration evidence.
• Penetration testing. Annual third-party pentest is the de facto standard. Schedule it early enough in the cycle that any high-severity findings can be remediated and re-tested before audit fieldwork. Keep the report, the remediation tickets, and the closure evidence linked.

System description

The system description is the narrative section of your SOC 2 report — what your service does, who it serves, what’s in scope, and what controls you’ve implemented. Auditors expect it to cover:

• Services provided
• System components (infrastructure, software, people, data, processes)
• Boundaries (what’s in, what’s explicitly out)
• Subservice organizations and how you handle them (carve-out details)
• Complementary User Entity Controls (CUECs)
• Risk assessment process
• Significant changes during the period

Don’t leave this until the last week. Start a draft in month 2. The first version is usually rough; iterating with your auditor saves you painful rewrites at audit time.

Evidence collection

This is where most teams struggle. Evidence is not the policy document. Evidence is what proves the control is operating.

Examples of weak vs. strong evidence:

If an auditor can’t verify the evidence stands on its own — without your verbal explanation — it isn’t strong enough.

Vendor agreements

For every Tier 1 vendor (those touching customer data), confirm you have a current Data Processing Agreement (DPA) or vendor security exhibit covering encryption, breach notification, sub-processors, and audit rights. (BAAs are HIPAA-specific — only required if you handle PHI, not for SOC 2 generally.) Vendor agreement gaps are a frequent finding on first-time SOC 2 audits.

Use this checklist: Vendor name → Tier → Contract → Security exhibit/DPA → Last reviewed date → Review owner.

Month 3: dry run, fix, audit

Week 1 — internal dry run

Walk through every control with the team. For each:

• Read the control statement aloud.
• Have the owner produce the evidence.
• Note any gaps in evidence quality, freshness, or completeness.

Most teams find 5–10 issues during dry run that would have become audit findings.

Week 2 — readiness assessment (optional but recommended)

Ask your auditor to do a paid readiness assessment before the formal audit. They’ll surface anything you’ve missed and give you a list of issues to fix before the actual audit starts. The cost is usually 25–40% of the audit fee and well worth it.

Week 3 — fix the readiness findings

Whatever the readiness assessment surfaces — fix it. This is also when you lock the final version of your system description (drafted in month 2) with your auditor — make sure scope, CUECs, and subservice org handling all match what fieldwork will actually test against.

Week 4 — audit fieldwork

Auditors will walk through controls with you and collect evidence. They’ll ask follow-up questions; have a single point of contact who manages the responses. Expect questions you didn’t anticipate — that’s normal. The goal is clear, prompt answers backed by the evidence you’ve collected.

After fieldwork, the auditor will draft the report. Review it carefully — once it’s finalized, errors are expensive to correct.

Common mistakes (in order of how much they cost)

Underscoping. Including only your production app and forgetting that your CI/CD, internal admin tools, customer support tooling, and monitoring infrastructure are also in-scope. Auditors will ask. Decide up front; don’t be surprised at week 8.

Underestimating evidence collection. Writing the policy is 20% of the work. Making the policy operational, generating ongoing evidence, and storing it where you can find it later — that’s the other 80%.

Treating the audit as a project with a discrete end. SOC 2 is recurring. Every assertion you make in Type I has to remain true through your Type II window — and through every subsequent renewal. Build for the recurring case from day one, not just the first audit.

Hand-rolling evidence collection. Spreadsheets and shared folders work at 5 employees. They break at 25 and become an active hazard at 50. Tooling pays for itself before your second audit.

Ignoring vendor management until late. Vendor agreements and assessments accumulate findings if left for the last month. Start week 1.

What happens after Type I

You receive your Type I report. Congratulations — you can now hand it to customers under NDA and start unlocking enterprise deals.

Two things should happen immediately:

1. The Type II observation window starts. Whatever controls you’ve asserted in Type I must remain effective continuously through this window. Drift becomes a finding.
2. You institutionalize the operational rhythm. Quarterly access reviews. Monthly patching reviews. Annual policy reviews. Whatever cadence the controls require — it has to actually happen, with evidence, across the window.

Tooling that automates evidence collection on a schedule earns its keep here. So does a dashboard that surfaces upcoming control activities and missed evidence.

What Talarity does for SOC 2

Talarity ships with a SOC 2 control library — 255 Talarity controls mapped to the 2017 Trust Services Criteria and 2022 Points of Focus — automated evidence collection from common sources (AWS/GCP/Azure, identity providers, vulnerability scanners, MDM, ticketing systems), a dedicated auditor workspace with read-only access to evidence, and cross-mapping to ISO 27001, HIPAA, and NIST CSF — so the work you do for SOC 2 satisfies your other frameworks too.

(For reference: SOC 2 itself is structured as Trust Services Criteria — ~33 Common Criteria plus additional criteria across Availability, Confidentiality, Processing Integrity, and Privacy, each with multiple Points of Focus. The “255” is the size of Talarity’s pre-built control library that covers those criteria, not the number of criteria SOC 2 defines.)

A 30-minute walkthrough will show you the workflow end-to-end. Or start a 7-day trial and import your existing control matrix to see how it lands in Talarity.