The SOC 2 readiness checklist: what auditors actually look for

SOC 2 is less a test you pass and more a story you have to be able to tell with receipts: here is what we promised about security, here is how we operate it, and here is the evidence it actually happened. "Readiness" is the work of making sure that story holds together before an auditor starts pulling on threads.

This is the checklist we wish more first-time teams had in front of them. It will not make the work small — but it will stop you discovering, three weeks before fieldwork, that you have no evidence for half of it.

Step 0 — decide Type I or Type II first

This choice changes everything about how you prepare, so make it before you do anything else.

• Type I attests that your controls are suitably designed at a single point in time. Faster to reach; useful when a customer needs something now.
• Type II attests that those controls operated effectively over a period — typically 3 to 12 months. This is what most enterprise buyers actually want, because design without operation proves nothing.

Step 1 — scope your Trust Services Criteria

SOC 2 is built on five Trust Services Criteria. You do not have to be assessed against all five — you pick the ones relevant to what you do, and you will be held to exactly what you select.

• Security (the Common Criteria) — mandatory, always. This is the bulk of the audit.
• Availability — include if you make uptime or SLA commitments.
• Confidentiality — include if you handle data customers consider confidential (most B2B SaaS).
• Processing Integrity — include if you process transactions where completeness/accuracy matters.
• Privacy — include if you handle personal information and make privacy commitments.

Most early-stage SaaS scope Security + Availability + Confidentiality. Do not add criteria for show — every one you select is something you must then evidence for the entire period.

Step 2 — the nine control areas auditors actually test

Almost everything in a SOC 2 examination falls into these buckets. Walk each one and ask: do we have a documented policy, is it actually operating, and can we prove it for the whole window?

1. Governance and risk assessment

• A documented information security policy, approved by leadership and reviewed at least annually.
• A risk assessment performed at least annually, with identified risks tracked to treatment.
• Defined security roles and responsibilities — who owns what.

2. Logical access control

• MFA enforced on all production and administrative access.
• Role-based, least-privilege access — and access reviews performed on a stated cadence (quarterly is typical), with evidence each one happened.
• A joiner/mover/leaver process with same-day (ideally same-hour) deprovisioning on termination.

3. Change management

• Code changes go through peer review and are tracked (pull requests are usually sufficient evidence).
• A separation between who writes and who deploys, or compensating controls if not.
• Production changes are logged and traceable.

4. Encryption and data protection

• Data encrypted at rest (AES-256 or equivalent) and in transit (TLS 1.2+).
• Key management documented.
• Data classification and retention policy in place.

5. Logging and monitoring

• Centralised logging with a stated retention period.
• Alerting on security-relevant events.
• Evidence that someone actually reviews alerts — monitoring nobody watches is not a control.

6. Vendor / third-party risk management

• An inventory of sub-processors and critical vendors.
• Security review of vendors before onboarding (their SOC 2 / ISO 27001, a questionnaire) and on a recurring cadence.
• Concerning findings tracked as risks, not left in a folder.

7. Incident response

• A documented incident response plan with defined roles and severity levels.
• A tested process — a tabletop exercise within the period is strong evidence.
• Breach-notification commitments you can actually meet.

8. Business continuity and backups

• Backups taken on a defined schedule and — critically — restoration-tested, not just assumed.
• A business continuity / disaster recovery plan with stated RTO/RPO.

9. HR and security awareness

• Background checks at hire (where lawful).
• Security awareness training at onboarding and annually, with completion records.
• Signed acceptable-use / confidentiality agreements.

Step 3 — collect evidence as you go, not at the end

The single biggest failure mode in first-time SOC 2 is treating evidence as something you gather the week before fieldwork. For Type II, the auditor samples across the whole period. An access review that only started last month cannot evidence a six-month window. Wire evidence collection to run continuously — automated where possible — so the proof accumulates on its own.

The gaps that quietly fail first-time programmes

• Access reviews that were never actually performed — only intended. Design without operation fails Type II.
• Offboarding that lags — a terminated employee whose access lingered for two weeks is a finding.
• Backups that are taken but never restoration-tested.
• Vendor risk that lives in an inbox, with no record of review or re-review.
• Monitoring with no evidence anyone looked at the alerts.
• Scoping too many Trust Services Criteria for ambition, then being unable to evidence them all.

Where Raize Orion fits

A readiness checklist is the easy part to write and the hard part to operate over months. Raize Orion is built to make the operating continuous: connectors pull live state from your systems daily so access, MFA, backups and configuration are evidenced automatically; evidence is linked to controls (and mapped across to ISO 27001, PCI and the rest, so the work is reusable); freshness and drift are tracked so a stale or lapsed control surfaces immediately rather than at fieldwork; and vendor assessments feed your risk register instead of dying in a folder.

We are deliberately auditor-agnostic — Raize does not perform your audit. It gives you and your chosen auditor the same evidence base, control map and read-only portal, so the examination is a review of work already done rather than a scramble. If you are starting a SOC 2 programme and want to see what "ready" looks like operationally, book a demo.