A SOC 2 compliance checklist is most useful when it follows the structure SOC 2 itself uses, which is the Trust Services Criteria, because that is exactly how an auditor evaluates you. SOC 2 is not a fixed list of controls but a framework built on five criteria, only one of which is always required, and preparing against the right ones with the right evidence is what turns a daunting audit into a manageable process. This checklist maps SOC 2 to the Trust Services Criteria, shows the evidence auditors sample for each, and flags the gaps that most often delay a report.
The reason to organize preparation this way is that a SOC 2 report is issued by a licensed CPA firm that examines your controls against these criteria, so aligning your readiness to them is aligning it to how you will actually be judged. A checklist built any other way risks preparing for the wrong thing, while one mapped to the criteria prepares you for the examination as it will really happen.
The Trust Services Criteria
SOC 2 is built on five Trust Services Criteria, and the first decision in any SOC 2 effort is which of them are in scope. Security is always required and forms the backbone of every SOC 2 report, while the other four are included only if they are relevant to the service you provide and the commitments you make to customers.
| Trust Services Criterion | What it covers | Required? |
|---|---|---|
| Security (Common Criteria) | Protection of systems and data against unauthorized access | Always required |
| Availability | Systems are available for operation and use as committed | Optional |
| Processing Integrity | Processing is complete, valid, accurate, and timely | Optional |
| Confidentiality | Information designated confidential is protected | Optional |
| Privacy | Personal information is handled per stated commitments | Optional |
The table makes the scoping decision concrete: every SOC 2 report covers Security, and you add the other criteria based on what matters to your customers. A cloud infrastructure provider often adds Availability, a payment processor may add Processing Integrity, and a service handling personal data adds Privacy. Choosing the criteria deliberately, rather than including all five by default, keeps the audit scoped to what your customers actually care about and controls the effort involved.
The SOC 2 Compliance Checklist by Criterion
With scope set, the checklist works through each in-scope criterion, confirming both that the controls exist and that you can evidence them, because an auditor tests both. Security carries the most weight, since it is required and the broadest.
Security, the Common Criteria
Security, expressed through the Common Criteria, covers the foundational controls every SOC 2 report examines: access controls and authentication, network and system protection, change management, risk assessment, monitoring, and incident response, along with the governance and organizational controls that sit above them. This is where most of the preparation effort goes, because the Common Criteria are comprehensive and apply regardless of which optional criteria you add. The checklist for Security is effectively a checklist for a sound security program, evidenced.
Availability, Processing Integrity, Confidentiality, and Privacy
The optional criteria each add a focused set of requirements on top of Security. Availability adds controls around capacity, monitoring, backup, and recovery that show systems meet their availability commitments. Processing Integrity adds controls ensuring that system processing is complete, accurate, and authorized. Confidentiality adds controls for identifying and protecting confidential information through its lifecycle, and Privacy adds a substantial set of controls governing how personal information is collected, used, retained, and disposed of in line with stated commitments. Each in-scope optional criterion extends the checklist, which is why scoping them to genuine relevance matters.
Evidence Auditors Sample
A SOC 2 examination is an evidence exercise, and knowing what auditors sample lets you prepare the right proof rather than scrambling during fieldwork. Auditors typically request policies and procedures that define your controls, then sample evidence that those controls actually operated: access reviews, system configurations, monitoring and alerting records, change tickets, onboarding and offboarding records, vendor reviews, and incident records among them. The recurring theme is that a control you cannot evidence is treated as a control you do not have, so the evidence trail is as important as the control itself.
The depth of evidence depends on the report type. For a Type II report, which is what most customers now expect, the auditor needs evidence that each control operated consistently across the entire audit period, not just that it existed at a point in time, so gaps in the evidence during the period become findings. Building the habit of retaining this evidence continuously, rather than assembling it before the audit, is what separates a smooth examination from a painful one.
Type I vs Type II
SOC 2 comes in two report types, and knowing which you need shapes the checklist. A Type I report assesses whether your controls are suitably designed at a single point in time, which is faster to achieve and useful as a first step or an interim signal. A Type II report assesses whether those controls operated effectively over a defined period, commonly several months to a year, and it is the report most customers and prospects actually want because it demonstrates sustained operation rather than a snapshot.
The practical implication is that Type II requires your controls to be not just designed but running and evidenced throughout the audit period, which is why organizations often pursue a Type I first and a Type II once controls have operated long enough to demonstrate, a path the guide to SOC 2 for startups covers for earlier-stage companies. Deciding the target report type early is important, because it determines how far in advance you need your controls operating and your evidence accumulating.
Gaps That Delay SOC 2 Reports
The gaps that delay a SOC 2 report are consistent, and most of them are avoidable with the checklist in hand. The most common is missing or incomplete evidence that controls operated across the full period, which is fatal for a Type II report because the auditor cannot attest to operation it cannot see. Incomplete or outdated policies are another, since the examination expects documented controls that match what you actually do. Access reviews that were never performed, or performed inconsistently, are a frequent finding, as is a scope that was set too broadly and created more to evidence than necessary.
A subtler delay comes from controls without clear owners, where no one is accountable for running them or retaining their evidence, so the trail is patchy when the auditor arrives. Each of these is a readiness problem rather than a security one, which is why a readiness effort before the formal examination is so valuable. Elevate’s SOC 2 services prepare organizations for the examination so these gaps are closed before an auditor finds them, and the guide to a SOC 2 readiness assessment covers that preparation in depth.
Conclusion
A SOC 2 compliance checklist works best mapped to the Trust Services Criteria, because that is how the examination is structured and how you will be judged. Scope the criteria to what your customers care about, prepare and evidence the controls under each, decide between a Type I and a Type II early, and watch for the gaps, missing period evidence, stale policies, skipped access reviews, and unowned controls, that most often delay a report. Preparation organized this way turns the audit from an unknown into a managed process.
Because a licensed CPA firm issues the report, the value of readiness preparation is in reaching the examination with the controls operating and the evidence in hand, so the audit confirms what you already know rather than surfacing surprises. To prepare for a SOC 2 examination against the criteria that apply to you, explore Elevate’s SOC 2 services or book a call with an Elevate advisor.
Key Takeaways
A SOC 2 compliance checklist should be mapped to the Trust Services Criteria, since that is how the examination is structured.
- Security is always required: the Common Criteria form the backbone of every SOC 2 report, and Availability, Processing Integrity, Confidentiality, and Privacy are added only when relevant to your service.
- Scope the criteria deliberately: including all five by default inflates the effort, so add optional criteria based on what your customers actually care about.
- Evidence is what auditors test: policies plus proof that controls operated, from access reviews to monitoring records, are what an examination samples, and an unevidenced control is treated as absent.
- Type II needs operation over time: most customers want a Type II report, which requires controls to have operated and been evidenced across the entire audit period, not just designed at a point in time.
- The delaying gaps are consistent: missing period evidence, outdated policies, skipped access reviews, over-broad scope, and unowned controls are the usual causes of a delayed report, and all are avoidable with preparation.
FAQs
Q1. What is a SOC 2 compliance checklist? A SOC 2 compliance checklist is a structured way to prepare for a SOC 2 examination, ideally mapped to the Trust Services Criteria because that is how an auditor evaluates you. It confirms both that the controls under each in-scope criterion exist and that you can evidence them, since an examination tests both design and, for a Type II report, operation over time. Used before the formal audit, it identifies the gaps you need to close so the examination confirms your controls rather than surfacing surprises.
Q2. What are the SOC 2 Trust Services Criteria? SOC 2 is built on five Trust Services Criteria. Security, expressed through the Common Criteria, is always required and covers protection against unauthorized access. The other four are optional and added based on relevance: Availability covers whether systems are available as committed, Processing Integrity covers whether processing is complete and accurate, Confidentiality covers protection of confidential information, and Privacy covers handling of personal information per stated commitments. Every report covers Security, and you scope the others to what matters to your customers.
Q3. What is the difference between SOC 2 Type I and Type II? A Type I report assesses whether your controls are suitably designed at a single point in time, which is faster to achieve and useful as a first step. A Type II report assesses whether those controls operated effectively over a defined period, commonly several months to a year, and is the report most customers actually want because it demonstrates sustained operation rather than a snapshot. Type II requires your controls to be running and evidenced throughout the period, so organizations often pursue Type I first and Type II once controls have operated long enough.
Q4. What evidence do SOC 2 auditors sample? Auditors request the policies and procedures that define your controls, then sample evidence that those controls actually operated, such as access reviews, system configurations, monitoring and alerting records, change tickets, onboarding and offboarding records, vendor reviews, and incident records. For a Type II report, they need evidence that each control operated consistently across the entire audit period, so gaps in the evidence during the period become findings. A control that cannot be evidenced is treated as one that does not exist.
Q5. What causes delays in getting a SOC 2 report? The most common cause is missing or incomplete evidence that controls operated across the full audit period, which is fatal for a Type II report. Other frequent causes include incomplete or outdated policies that do not match actual practice, access reviews that were never performed or done inconsistently, a scope set too broadly, and controls without clear owners so their evidence trail is patchy. These are readiness problems rather than security ones, which is why a readiness effort before the formal examination closes them before an auditor finds them.