Template

SOC 2 Readiness Assessment Template

Use this checklist to gauge how audit-ready you are before engaging a CPA firm for a SOC 2 Type I or Type II examination. Score each item as In place, Partial, or Not started; anything not fully in place becomes your remediation backlog.

How to use this template

Work through each section and mark every control In place / Partial / Not started.
Treat every Partial or Not started as a remediation item with an owner and a due date.
For Type II, confirm each control has been operating (with evidence) for your full observation window — commonly 3–12 months.
Re-run the assessment ~2 weeks before fieldwork to catch drift.

Scope & governance

Establish what the audit covers before assessing controls.

In-scope systems, products, and data flows are documented (a system description exists).
Selected Trust Services Criteria are decided (Security is required; Availability, Confidentiality, Processing Integrity, Privacy are optional).
Type I vs Type II is chosen, and for Type II the observation window is set.
An audit owner and cross-functional RACI are named.
A CPA firm / auditor is shortlisted (readiness ≠ the audit itself).

CC1 — Control environment

Code of conduct exists and employees acknowledge it.
Org chart and defined roles/responsibilities are maintained.
Background checks are performed for new hires where permitted.
Board / leadership oversight of security is evidenced (e.g., meeting notes).

CC2 / CC3 — Communication & risk assessment

Security policies are published and accessible to all staff.
A documented risk assessment is performed at least annually.
Identified risks are tracked to treatment with owners.
A channel exists for reporting security concerns (internal and external).

CC5 / CC6 — Access control

The section auditors probe hardest.

SSO and MFA are enforced for corporate and production systems.
Access is provisioned via least privilege and role-based access.
Access reviews are performed at least quarterly with evidence retained.
Onboarding and offboarding checklists exist; offboarding revokes access promptly.
Production data access is restricted, logged, and reviewed.
Encryption in transit (TLS) and at rest is enforced for sensitive data.

CC7 — System operations & monitoring

Centralized logging and alerting are in place for in-scope systems.
Vulnerability scanning runs on a defined cadence; findings are remediated to SLA.
An incident response plan exists and has been tested/tabletop-exercised.
Endpoint protection and patch management are deployed and monitored.

CC8 — Change management

Code changes require peer review and pass CI checks before merge.
Production deployments are approved and traceable to a change record.
Separation between development and production environments is enforced.
Infrastructure changes follow the same review/approval flow.

CC9 — Vendor & risk management

A vendor inventory exists with risk tiers for subprocessors.
Critical vendors' SOC 2 / ISO 27001 reports are collected and reviewed.
Data Processing Agreements are in place where required.

Availability, Confidentiality & Processing Integrity (if in scope)

Backups are automated, encrypted, and restore-tested.
A business continuity / disaster recovery plan is documented and tested.
Data classification and handling policies define confidential data treatment.
Data retention and secure disposal procedures exist.
For Processing Integrity: input validation, QA, and processing monitoring are defined.

Evidence readiness

Type II lives or dies on evidence — collect continuously, not the week before.

Policies are versioned, dated, and approved.
Access-review, change, and incident records are retained for the full window.
Screenshots/exports are timestamped and attributable to a system of record.
A control-to-evidence mapping exists (which artifact proves which control).

This template is general guidance to accelerate your compliance program and is not legal advice. Adapt it to your organization and your auditor's requirements.