SOC 2 Readiness Checklist Template: Free Excel Download

Photo: Unsplash

SOC 2 readiness checklist template: free Excel download

A SOC 2 readiness checklist turns the Trust Services Criteria (TSC) your auditor will test into actionable rows—with owners, evidence links, test frequency, and status tracking—so you know exactly where you stand before the observation period starts. This free workbook gives you a structured starting point across Security (CC), Availability (A), Confidentiality (C), Processing Integrity (PI), and Privacy (P) without rebuilding the spreadsheet from scratch.

SOC 2 Type II is not a policy exercise. Auditors sample controls over time and ask for proof that they operated consistently during your audit window. A readiness checklist is how most SaaS security and compliance leads translate "we have security practices" into a defensible, auditable control inventory.

This guide covers:

• What a SOC 2 readiness checklist is and how it fits your audit timeline
• A before-you-start prep list (scope, TSC selection, owners, observation period)
• How this checklist differs from a gap analysis and a full control matrix
• Tab-by-tab instructions for the Excel workbook
• A practical 90-day workflow to complete readiness before fieldwork
• Domain-by-domain guidance for each Trust Services Category in scope
• Type I vs Type II auditor expectations and evidence mapping
• Sample N/A justifications for criteria you legitimately exclude
• Common mistakes that delay SOC 2 audits and enterprise deals

GIF via GIPHY

Related guides:

• Learn SOC 2: beginners guide
• SOC 2 requirements
• How to create a SOC 2 project plan
• SOC 2 gap analysis assessment
• Understanding SOC 2 Trust Services Criteria
• SOC 2 evidence collection

Key takeaways

• A SOC 2 readiness checklist maps Trust Services Criteria to actionable control rows with owners, evidence examples, status, and test dates—the fields auditors commonly sample.
• This template includes 25 starter controls across five TSC domains: 14 Security (CC), 3 Availability, 2 Confidentiality, 2 Processing Integrity, and 4 Privacy.
• The Dashboard tab tracks readiness percentage per domain for leadership and steering committee updates.
• Security (CC) is mandatory for every SOC 2 report; add Availability, Confidentiality, Processing Integrity, or Privacy only when your customer commitments and system description require them.
• Treat the checklist as a living workbook—update status and Last Tested dates throughout the Type II observation period, not just before audit week.
• SecureSlate automates evidence collection, control monitoring, and auditor-ready exports for SOC 2.

---

What is a SOC 2 readiness checklist?

A SOC 2 readiness checklist is an operational inventory of controls aligned to the Trust Services Criteria your CPA firm will test during a SOC 2 examination. It answers four questions for every control in scope:

1. What must operate (control description tied to TSC)?
2. Who owns it (named accountable owner)?
3. How do you prove it (evidence location and examples)?
4. When was it last validated (test frequency and Last Tested date)?

Unlike a policy library or a vendor questionnaire response, a readiness checklist is designed for internal tracking and audit coordination. Your auditor will use their own detailed criteria mapping (often hundreds of points of focus for Security alone), but your checklist is the workbook your team uses to:

• Assign ownership before remediation sprints
• Track implementation status week by week
• Link evidence before mock audits
• Demonstrate operating effectiveness during the Type II observation window

For first-time SOC 2 teams, the checklist is typically the first artifact that makes "compliance" concrete. For repeat audits, it becomes the continuity record between observation periods.

---

Before you start

Do not fill every row on day one. A readiness checklist reflects decisions you have already made about scope, TSC categories, and system boundary. Complete this prep first:

SOC 2 readiness prep checklist

• Confirm your system description boundary (products, environments, data types, subprocessors, and explicit exclusions)
• Decide which Trust Services Categories are in scope—Security (CC) is required; others depend on customer contracts and your trust center
• Choose Type I vs Type II and set your observation period start date (Type II typically requires 3–12 months of operating evidence)
• Assign a checklist owner (typically GRC lead or security/compliance manager) and control owners per domain
• Gather existing policies, configs, tickets, and exports before marking anything Implemented
• Align status definitions with your team (see workflow section below) and communicate them in a kickoff
• Schedule working sessions with engineering (access, change, vuln mgmt), IT (identity, logging), HR (background checks, training), and legal/privacy (if Privacy is in scope)
• Set a target readiness review date and work backward—many first-time teams need 3 to 6 months before the observation period

Owners and links (fill these in)

• Checklist owner: [Name / Role]
• Target audit type: [Type I / Type II]
• Observation period start: [Date] (Type II)
• Links:
  • [System description draft]
  • [SOC 2 project plan]
  • [Risk register]
  • [Policy repository]

---

Readiness checklist vs gap analysis vs control matrix

These artifacts work together. Teams that confuse them often duplicate work or miss remediation priorities.

Artifact	Primary purpose	Typical owner	When to use it
Readiness checklist (this template)	Track control implementation status, owners, evidence links, and test dates	GRC / security lead	Ongoing readiness and observation-period maintenance
Gap analysis	Compare current state vs TSC requirements; score Met / Partial / Not met; prioritize fixes	Security + engineering	Before committing to an audit date or enterprise deal
Control matrix	Detailed mapping of every TSC point of focus to control activities (auditor-facing)	GRC lead with auditor input	Final audit package; often built from checklist + gap closure

Rule of thumb: Run a SOC 2 gap analysis assessment first to find what is broken. Use this readiness checklist to track closure and operating evidence through the observation period. Expand rows or add a separate matrix when your auditor provides their criteria mapping.

---

What makes this template useful

• TSC-aligned domain tabs: Separate sheets for CC (Security), Availability, Confidentiality, Processing Integrity, and Privacy—include only tabs that match your report scope.
• Control-by-control rows: Control ID, name, description, evidence examples, owner, frequency, status, evidence location, last tested, and notes.
• Status tracking: Dropdown-friendly values—Not Started, In Progress, Implemented, and N/A for legitimately scoped-out criteria.
• Dashboard summary: Readiness % per domain with counts for Implemented, In Progress, Not Started, and Gap Identified.
• Document control: Overview and Version & Approval tabs for ownership, version history, and management sign-off.
• Evidence-first design: Each row includes example evidence types so owners know what auditors typically request—not just "have a policy."

Note on scope: This workbook includes 25 summary-level controls as a practical starting framework. Full SOC 2 examinations test against the complete AICPA Trust Services Criteria points of focus (especially within CC). Use this template to establish ownership and evidence habits, then expand rows or import your auditor's criteria mapping as you mature.

---

Download the template

• Download (Excel): SOC 2 Readiness Checklist (XLSX)

Complete document control on the Overview tab and confirm TSC scope before assigning rows to control owners. Security (CC) is required for every SOC 2 report; only activate Availability, Confidentiality, Processing Integrity, or Privacy tabs when your system description and customer commitments require them.

---

Tab-by-tab walkthrough

Overview

Document control header: organization name, department, document owner, author, version, status, and review dates. This tab establishes the checklist as controlled documented information—not an ad hoc spreadsheet shared in Slack.

Fill this in before distributing the workbook to control owners. Record your observation period start date here for Type II audits.

Version & Approval

Version history and management sign-off. Auditors and enterprise buyers commonly ask who approved your control framework and when it was last updated. Record approver name, role, date, and version number.

Dashboard

Auto-calculated summary by Trust Services domain:

Domain	Controls in template
CC – Security	14
A – Availability	3
C – Confidentiality	2
PI – Processing Integrity	2
P – Privacy	4

Columns track total controls, implemented count, in progress, not started, gap identified, and % ready. Use this tab in weekly readiness standups and monthly leadership updates.

Domain tabs (CC – Security, A – Availability, C – Confidentiality, PI – Processing Integrity, P – Privacy)

The main working tabs. Columns:

Column	What to enter
Control ID	Pre-filled (e.g., CC6.1, A1.2, P4.1)
Control Name	Pre-filled summary label aligned to TSC theme
Description	What must operate—edit if your auditor's mapping differs
Evidence Examples	Pre-filled suggestions; replace with your actual artifact types
Evidence Owner	Named person accountable for the control
Frequency	How often the control is tested (e.g., Quarterly, Annual, Continuous)
Status	Not Started, In Progress, Implemented, or N/A
Evidence Location	URL, ticket ID, or file path auditors can access
Last Tested	Date the control was last validated with evidence
Notes	Scope caveats, remediation tickets, auditor comments

Work domain by domain. Do not let one person guess across engineering, IT, HR, and legal.

---

90-day SOC 2 readiness workflow

Most first-time teams can reach audit-ready status in roughly 90 days when executive sponsorship and engineering time are secured. Type II observation periods add 3–12 months on top for operating evidence—start this workflow before the observation window opens.

Weeks 1–2: Scope and TSC selection

• Finalize system description and subprocessor list
• Confirm TSC categories in scope with sales, legal, and leadership
• Open the template; complete Overview and Version & Approval
• Run a gap analysis and import findings into checklist status

Weeks 3–4: Security — governance and risk (CC1–CC3, CC5, CC9)

• Map board oversight, security policies, and risk assessment to existing documents
• Assign owners for governance rows (CC1.1, CC1.2, CC2.1, CC3.1, CC5.1, CC9.1)
• Mark status honestly—In Progress is acceptable if remediation plans exist

Weeks 5–6: Security — logical access (CC6.x)

• Engineering and IT own access provisioning, MFA, RBAC, and network boundaries
• Link to IAM configs, access review exports, and firewall rule documentation
• Schedule your first quarterly access review before observation period starts

Weeks 7–8: Security — monitoring and change (CC7.x, CC8.x)

• Connect vulnerability scans, SIEM alerts, and change management tickets
• Ensure production changes have approval records auditors can sample
• Document patch SLAs and exception handling

Weeks 9–10: Optional TSC domains (A, C, PI, P)

• Availability: Link SLAs, capacity planning, and DR test results
• Confidentiality: Map data classification and handling procedures
• Processing Integrity: Document reconciliation and error-handling workflows
• Privacy: Coordinate with legal on notice, consent, retention, and DSAR processes

Weeks 11–12: Review, mock audit, and approve

• Checklist owner validates every Implemented row has a working evidence link
• Run an internal mock audit using your SOC 2 project plan timeline
• Obtain management approval and freeze version before auditor kickoff
• For Type II: begin logging Last Tested dates that fall inside the observation period

Status definitions (use consistently)

Status	Meaning	Acceptable before Type I?	Acceptable during Type II observation?
Not Started	Control is in scope but no implementation work has begun	Usually not—shows a gap	No—auditors will test operating effectiveness
In Progress	Policy, tooling, or process exists but is incomplete	Often acceptable with remediation plan	Risky if still In Progress when observation starts
Implemented	Control operates as designed with linked evidence	Required for Type I	Required—with Last Tested dates inside observation window
N/A	Criterion legitimately outside report scope	Yes, with documented justification	Yes, with documented justification

---

Domain-by-domain guidance (TSC)

CC – Security (14 controls)

Security is mandatory for every SOC 2 report. This tab covers the COSO-aligned Common Criteria themes auditors expect: control environment, communication, risk assessment, control activities, logical access, system operations, change management, and risk mitigation.

Control ID	Theme	Typical owner	Evidence examples
CC1.1–CC1.2	Governance & accountability	CISO / CEO	Board minutes, security charter, org chart
CC2.1	Policy communication	CISO	Policy acknowledgment records, intranet posts
CC3.1	Risk assessment	Security	Risk register, last assessment report
CC5.1	Control activities	Security	Policy repository, control library
CC6.1–CC6.7	Logical access & boundaries	IT / Engineering	MFA config, access tickets, network diagrams, TLS settings
CC7.1–CC7.2	Monitoring	Security / IT	Vuln scan reports, SIEM dashboards
CC8.1	Change management	Engineering	Change tickets, CAB minutes
CC9.1	Risk mitigation	Security	Risk register with treatment plans

Common pitfall: Marking access controls Implemented when MFA is enabled for admins only but not enforced org-wide.

A – Availability (3 controls)

Include Availability only when your customer contracts, SLAs, or trust center commit to uptime and recovery. Auditors will test whether you monitor capacity, meet availability commitments, and can recover from incidents.

Typical owners: Engineering, SRE, or infrastructure lead.

Evidence examples: SLA documents, capacity reports, DR/BCP test results (pair with our BCP template if needed).

Common pitfall: Scoping Availability because "we are a SaaS" without documented uptime commitments to customers.

C – Confidentiality (2 controls)

Include Confidentiality when you commit to protecting confidential information beyond general security controls—for example, customer data designated as confidential, trade secrets, or regulated data classes.

Typical owners: Security and data governance.

Evidence examples: Data classification policy, DLP configuration, handling procedures for confidential tiers.

Common pitfall: Treating Confidentiality as redundant with Security—auditors look for classification and handling specific to confidential data types.

PI – Processing Integrity (2 controls)

Include Processing Integrity when your service processes data on behalf of customers and completeness or accuracy is part of your commitment—for example, billing, payroll, or transaction processing systems.

Typical owners: Engineering and product.

Evidence examples: Transaction logs, reconciliation reports, error alerting and resolution tickets.

Common pitfall: Scoping PI for a standard CRUD SaaS with no processing-accuracy commitments in contracts.

P – Privacy (4 controls)

Include Privacy when you collect, use, retain, or disclose personal information and your report covers privacy criteria (often required for B2C or HR data-heavy products).

Typical owners: Legal, privacy lead, or DPO with security support.

Evidence examples: Privacy policy, consent records, retention schedule, DSAR response log.

Common pitfall: Scoping Privacy without a documented privacy program—P1.1 through P8.1 require operational proof, not just a policy URL.

---

What auditors expect at Type I vs Type II

Audit type	Checklist focus	What "good" looks like
Type I (point in time)	Design effectiveness: do controls exist and are they suitably designed?	Statuses are honest, evidence links work, owners can explain their rows, gaps have remediation plans
Type II (over time)	Operating effectiveness: did controls run consistently during the observation period?	Last Tested dates fall inside the observation window, evidence is sampled across the full period, no "implemented on audit eve" timestamps
Re-examination / bridge period	Changes since last report: new products, vendors, infrastructure	Checklist updated, Version & Approval reflects changes, new controls added for scope shifts

Type I is not a free pass on weak controls—but Type II is where teams most often fail because they cannot prove consistent operation. Start logging test dates and evidence early in the observation period, not in the final month.

For deeper context, see SOC 2 Type 1 vs Type 2 and SOC 2 evidence collection.

---

Sample justifications for N/A criteria

Marking a Trust Services Category or control N/A is valid when it truly falls outside your report scope—but the justification must be specific and tied to your system description, not convenience.

TSC domain	Scenario	Sample justification
A – Availability	No uptime SLA in customer contracts	N/A. System description does not include availability commitments; infrastructure hosted on [provider] with standard shared SLA. Security (CC) covers incident response.
PI – Processing Integrity	SaaS stores data but does not process transactions	N/A. Service provides data storage and retrieval only; no processing completeness or accuracy commitments in MSA or trust center.
C – Confidentiality	All customer data treated uniformly under Security	N/A. No confidential data classification tier beyond standard customer data protected under CC6.x access controls. Legal review dated [date].
P – Privacy	B2B SaaS with no personal data	N/A. System processes business contact data only under customer direction; no collection of consumer personal information. Privacy criteria excluded per system description v[X].
CC6.6 – Boundary Protection	Fully managed PaaS, no self-managed network	Partially applicable. Network boundaries managed by [cloud provider]; organizational controls documented in vendor risk assessment and shared responsibility matrix.

If you mark a row N/A, be prepared for the auditor to ask: Show me where this is reflected in your system description and customer commitments.

---

How to use it as audit evidence

Auditor question	Template field	Where to point
How do you track control implementation?	Status + Dashboard	Dashboard tab and domain tabs with current counts
Who owns each control?	Evidence Owner column	Named owner per row—must match interviewees
What evidence supports this control?	Evidence Examples + Evidence Location	Working links, not placeholders
When was it last tested?	Last Tested + Frequency	Dates inside Type II observation period
How do you manage scope changes?	Notes + Version & Approval	Version history and updated rows
Which TSC categories are in scope?	Active domain tabs + N/A justifications	Tabs in use vs marked N/A with Notes

Practical tip: Export a PDF snapshot of the checklist and Dashboard before mock audits, after remediation sprints, and at observation-period midpoint. Store snapshots alongside your evidence collection folder as a versioned set.

---

Common mistakes

• Implemented without evidence: Status says Implemented but Evidence Location is empty or links to a draft policy
• Scoping TSC categories without customer backing: Availability or Privacy in the report but no contractual or trust-center commitment to support them
• No Last Tested dates during Type II: Controls marked Implemented but tested only once, outside the observation window
• One person fills every row: Control owners were never consulted; audit interviews expose gaps immediately
• Checklist abandoned after Type I: Type II observation starts but nobody updates statuses or collects recurring evidence
• Confusing checklist with full criteria mapping: 25 summary rows treated as complete when the auditor tests dozens of points of focus within CC alone
• Evidence links that break: Shared drive permissions, expired URLs, or revoked API tokens during audit week
• Status inflation before sales calls: Rows marked Implemented to satisfy procurement while engineering knows controls are not operational

---

How SecureSlate helps

Spreadsheets work for your first readiness draft. They break down when you need continuous evidence, owner reminders, and audit exports across dozens of controls and a multi-month observation period.

SecureSlate helps teams:

• Map SOC 2 Trust Services Criteria to automated evidence from cloud, identity, HR, and ticketing systems
• Track implementation gaps with owners, due dates, and remediation workflows
• Collect and refresh Type II evidence on a schedule—access reviews, vuln scans, training completion, and more
• Export auditor-ready packages with timestamps and audit trails
• Maintain readiness between annual SOC 2 examinations without rebuilding spreadsheets each quarter

Get started for free

---

FAQ

Which Trust Services Criteria should we include?
Security (CC) is mandatory for every SOC 2 report. Add Availability, Confidentiality, Processing Integrity, or Privacy based on what you promise customers in contracts, your trust center, and your system description.

How is this different from a SOC 2 gap analysis?
A gap analysis scores your current state against requirements and prioritizes remediation. This readiness checklist tracks ongoing implementation status, owners, evidence, and test dates—especially through the Type II observation period.

How long before audit should we start this checklist?
Many teams begin 3 to 6 months before the observation period. First-time SOC 2 audits often need longer for policy creation, tooling configuration, and access review cadence.

Does this template include every SOC 2 control?
No. It includes 25 summary-level controls as a practical starting framework aligned to TSC domains. Your auditor will test against the full AICPA criteria mapping—expand this workbook or pair it with your auditor's control matrix as you mature.

What is the difference between Type I and Type II for this checklist?
Type I tests control design at a point in time. Type II tests operating effectiveness over an observation period (typically 3–12 months). Last Tested dates and recurring evidence matter far more for Type II.

Can we mark controls In Progress during readiness?
Yes, especially early in the project. Before fieldwork, every in-scope control should be Implemented with evidence—or have a documented remediation plan leadership accepts.

Who should own the checklist?
Typically the GRC lead, security manager, or compliance owner. Individual control owners validate rows for their domain (engineering, IT, HR, legal).

How often should we update the checklist?
Weekly during active readiness sprints; monthly during the Type II observation period; and immediately after scope changes (new product, acquisition, major vendor shift).

Can this template replace a GRC platform?
It is a strong starting point for first-time SOC 2. As control count, evidence volume, and observation-period monitoring grow, teams commonly move to a platform for automation and continuous compliance.

What evidence do auditors request most often?
Access reviews, MFA enforcement, vulnerability scan and remediation records, change management tickets, security awareness training completion, and background check records. See SOC 2 evidence collection for a full breakdown.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory, or professional advice. Requirements vary by framework, industry, and jurisdiction. Consult qualified advisors for your specific obligations.