A SOC 2 checklist is the list of work that gets a company from deciding it needs a report to an auditor issuing one. In order: define the scope and the Trust Services Criteria in it, run a gap assessment against those criteria, write and approve the policies, implement the controls that are missing, set up evidence collection for every control, choose an auditor and agree the review period, operate the controls throughout that period, and support the auditor through fieldwork. The criteria describe outcomes rather than prescribing controls, so the checklist below lists the controls most SOC 2 reports contain, not a fixed set the AICPA requires.
SOC 2 does not come with a checklist from the AICPA. The Trust Services Criteria describe what controls must achieve and leave it to each company to decide how. That flexibility is why every vendor's checklist looks different, and why the useful version is ordered by when the work happens rather than by criterion number.
1. Define the scope
- The system the report covers: the product or service, its infrastructure and the boundary around it.
- The data it handles and where that data lives.
- The Trust Services Criteria categories in scope: Security always, and Availability, Processing Integrity, Confidentiality or Privacy where your commitments call for them.
- The report type, Type 1 or Type 2, and for a Type 2 the length of the first review period.
- The subservice organizations the system depends on, such as your cloud provider.
The Trust Services Criteria guide covers how to choose the categories.
2. Run a gap assessment
Walk through each criterion in scope and record how you meet it today, if at all. The output is a list of missing controls, controls that happen informally but leave no record, and policies that exist only in people's heads. That list is the readiness plan.
3. Write and approve the policies
Most SOC 2 reports rest on a similar set of policies. Each needs an owner, management approval, a review date and, for the ones that apply to everyone, an acknowledgement from staff.
- Information security policy, setting out roles and responsibilities.
- Access control, covering provisioning, removal, reviews and authentication.
- Change management, covering how code and infrastructure changes are approved and deployed.
- Incident response, covering detection, escalation, communication and review.
- Risk assessment, covering how risks are identified, rated and treated.
- Vendor management, covering how suppliers are assessed and monitored.
- Business continuity and disaster recovery, covering backups and restoration.
- Acceptable use, data classification and retention, and human resources security.
4. Implement the missing controls
The controls below appear in most SOC 2 reports for a SaaS company. Treat it as a starting point and check each one against what your own criteria and commitments require.
| Area | Common controls |
|---|---|
| Governance (CC1–CC5) | Security responsibilities assigned, management oversight, risk assessment performed and reviewed, background checks, security awareness training |
| Access (CC6) | Single sign-on and MFA, role-based access, prompt removal of leavers, periodic access reviews, encryption in transit and at rest |
| Operations (CC7) | Logging and monitoring with alerting, vulnerability scanning, penetration testing, incident response with records of each incident |
| Change management (CC8) | Reviewed and approved changes, separation between who writes and who deploys, tested releases, emergency change process |
| Risk mitigation (CC9) | Vendor risk assessments, review of subservice organization reports, business continuity planning |
| Availability (A1), if in scope | Capacity monitoring, backups with restore tests, disaster recovery plan and test |
5. Start collecting evidence
Every control needs a record each time it runs: the access review with its date and reviewer, the change ticket with its approval, the restore test with its result. Set this up before the review period begins, and prefer evidence pulled from the systems themselves over screenshots taken on request. The SOC 2 evidence list goes control by control.
6. Pick an auditor and agree the review period
Choose a CPA firm with SOC 2 experience in companies like yours, confirm the scope and report type, and agree the review period's start date in writing. The SOC 2 audit timeline covers how long each phase takes.
7. Run the review period
Operate every control throughout the window. The work in this phase is mostly noticing drift early: a missed access review or an unapproved change found the same week is a small fix, while one found in fieldwork is an exception in the report.
8. Support fieldwork
The auditor asks for populations, such as every change or every new hire in the period, picks samples, and asks for the evidence behind each. Answer quickly, make control owners available, and if an exception is found, understand it and write a factual management response. The guide to audit exceptions and opinions covers what happens next.