Is there an official SOC 2 checklist?

No. The AICPA publishes the Trust Services Criteria, which describe what has to be achieved, and each company designs its own controls to meet them. A checklist like this one is a way to find gaps before an auditor does; it is not a list the auditor works from.

If I can tick every item, am I ready for an audit?

You are in a much better position, but twenty questions cannot cover every criterion or every scope. Treat a full set of ticks as a reason to talk to a CPA firm about a readiness review and dates, not as a prediction of the outcome. Only the firm that examines you can form an opinion on your controls.

What is the difference between this checklist and the readiness assessment?

They use the same twenty questions. This page lists them with the reasoning and the fix for each, so you can read, print or download them. The readiness assessment lets you answer yes, partly or no and gives you a score, a breakdown by area and a gap list in priority order. Your answers stay in your browser.

Do I need a Type I before a Type II?

No. A Type I is optional. It tests design on a single date and can give a customer something sooner, but many companies go straight to a Type II. Either way the checklist items are the same; what changes is how long the controls must have been running when the auditor looks.

Which items should I do first?

Written and approved policies, a risk assessment and MFA everywhere. Most other controls refer back to one of those three, and they are also what auditors and customer security questionnaires ask about first.

SOC 2 checklist

20 questions that cover the controls auditors test first, grouped into 8 areas. Each one says why it matters and what to do if your answer is no. Use it as a SOC 2 readiness checklist before you talk to an auditor, or score yourself in 3 minutes with the interactive version; your answers stay in your browser.

How to use this checklist

Tick an item only when the control runs today and leaves evidence you could hand over: a dated export, a ticket, a signed review. “We do that, informally” is a partly, not a yes. The gap between what a team does and what it can show is where most first-time SOC 2 work goes.

The items are not the SOC 2 standard itself. SOC 2 is built on the AICPA’s Trust Services Criteria, and every company writes its own controls to meet them (see the SOC 2 controls list for how that works). Each item below links to the criteria it speaks to and to a free policy template that documents the control.

The SOC 2 readiness checklist

Governance and risk

Do you have written security policies that management approved in the last 12 months?
Why it matters: Policies are the first section of every SOC 2 document request, and undated policies read as unapproved.
What to do: Adopt a policy set, have the CEO or another executive approve it, and record the date in each policy's revision history.
Criteria: CC1.1, CC5.3. Template: Information Security Policy
Is one named person accountable for the security program?
Why it matters: Auditors look for clear ownership and reporting lines before they test anything else.
What to do: Name a Security Owner (often the CTO at a startup) in the Information Security Policy and give each policy an owner role.
Criteria: CC1.3. Template: Information Security Policy
Have you completed a documented risk assessment, with a scored risk register, in the last 12 months?
Why it matters: The whole CC3 series is about identifying and responding to risk; the register is the evidence.
What to do: Run a risk assessment: list risks, score likelihood and impact, choose a treatment and an owner for each, and date it.
Criteria: CC3.1, CC3.2, CC3.4. Template: Risk Assessment and Management Policy
Do you check at least yearly that your controls are still working, and track the fixes?
Why it matters: Monitoring activities (CC4) ask for evidence that someone looks at whether controls operate, not just that they exist.
What to do: Schedule an annual internal review of the controls and log each deficiency with an owner and a due date.
Criteria: CC4.1, CC4.2. Template: Information Security Policy

People

Does everyone acknowledge the security policies and complete security training at hire and every year?
Why it matters: Signed acknowledgments and training records are the standard evidence that people know what is expected of them.
What to do: Collect a signed acknowledgment from every employee and contractor, and run short security training at onboarding and annually.
Criteria: CC1.4, CC2.2. Template: Human Resources Security Policy
Do you follow a written onboarding and offboarding checklist, including background checks where lawful?
Why it matters: Auditors sample new hires and leavers and ask for the checklist and the screening record for each.
What to do: Write the joiner and leaver checklists, keep one completed copy per person, and document your screening rule.
Criteria: CC1.4. Template: Human Resources Security Policy

Access

Is multi-factor authentication enforced for everyone on your identity provider, cloud console and source control?
Why it matters: MFA is one of the first things tested under logical access, and an exception list is itself a finding.
What to do: Enforce MFA at the identity provider and in each console that has its own login, then export the settings as evidence.
Criteria: CC6.1. Template: Authentication and Password Policy
Is access granted through single sign-on groups or roles, following least privilege?
Why it matters: Role-based access makes the population auditors sample small and explainable.
What to do: Map roles to groups in your identity provider and grant application access to groups rather than to individuals.
Criteria: CC6.1, CC6.3. Template: Access Control Policy
Do you review who has access to production, source code and admin roles at least quarterly, and keep the record?
Why it matters: Periodic access reviews are among the most commonly sampled controls, and a missed quarter is a visible exception.
What to do: Export user lists each quarter, have each system owner attest to them, remove what is not needed and file the signed review.
Criteria: CC6.2, CC6.3. Template: Access Control Policy
When someone leaves, is their access removed within a defined time you can prove?
Why it matters: A terminated user who stayed active is one of the classic SOC 2 exceptions.
What to do: Set a deadline (for example end of the last working day), deprovision from the identity provider first, and keep the ticket.
Criteria: CC6.2. Template: Access Control Policy

Change and development

Does every production change go through a pull request with an independent review and passing checks?
Why it matters: Change management (CC8.1) is tested by sampling production changes and looking for approval before deployment.
What to do: Turn on branch protection: required review, required status checks, no self-approval, rules applied to admins too.
Criteria: CC8.1. Template: Change Management Policy
Are production deployments done only through your CI/CD pipeline, not by hand?
Why it matters: A pipeline gives a complete, dated record of what was deployed, by whom, from which commit.
What to do: Remove personal deploy credentials, deploy only from the pipeline with a scoped service identity, and keep deployment logs.
Criteria: CC8.1. Template: Change Management Policy

Detection and response

Do you scan code, dependencies and infrastructure for vulnerabilities and fix findings within set timelines?
Why it matters: CC7.1 asks for detection of vulnerabilities; auditors compare fix dates against the timelines your policy sets.
What to do: Enable dependency and cloud posture scanning, define timelines by severity, and track every finding to closure.
Criteria: CC7.1. Template: Vulnerability and Patch Management Policy
Are security-relevant logs collected centrally, retained, and alerted on?
Why it matters: Monitoring for anomalies (CC7.2) needs logs you keep and alerts someone actually reviews.
What to do: Send identity provider, cloud audit and application logs to one place, set retention, and route alerts to an owned channel.
Criteria: CC7.2. Template: Logging and Monitoring Policy
Do you have a written incident response plan that you tested (for example a tabletop) in the last 12 months?
Why it matters: CC7.3 to CC7.5 cover evaluating, responding to and recovering from incidents; a tested plan is the evidence.
What to do: Write the plan with severities, roles and notification duties, then run a one-hour tabletop and file the notes.
Criteria: CC7.3, CC7.4, CC7.5. Template: Incident Response Policy

Vendors

Do you keep a vendor inventory and review the SOC 2 reports of vendors that hold customer data?
Why it matters: CC9.2 asks how you assess and monitor vendor risk; the inventory and the dated reviews are what gets sampled.
What to do: List every vendor with the data it touches, tier them, and review the SOC 2 report of each critical vendor yearly.
Criteria: CC9.2. Template: Vendor and Third-Party Risk Management Policy

Resilience

Are backups automated, and have you restored from one as a test in the last 12 months?
Why it matters: An untested backup is not evidence of recoverability; auditors ask for the restore test record.
What to do: Confirm automated, encrypted backups for every production data store, restore one into a scratch environment and record it.
Criteria: A1.2, A1.3. Template: Backup and Recovery Policy
Do you have a business continuity and disaster recovery plan with recovery time and recovery point objectives?
Why it matters: Availability commitments and CC9.1 expect a plan for disruption, with objectives you can test against.
What to do: Tier your systems, set RTO and RPO per tier, document the recovery steps and test them once a year.
Criteria: CC9.1, A1.3. Template: Business Continuity and Disaster Recovery Policy

Devices and data

Are laptops encrypted, screen-locked and kept up to date, and can you prove it (device management or attestation)?
Why it matters: Endpoints hold credentials and data; auditors ask for evidence across the whole fleet, not a policy statement.
What to do: Enforce disk encryption, screen lock and automatic updates through device management, or collect quarterly attestations.
Criteria: CC6.8. Template: Endpoint and Workstation Security Policy
Is customer data classified, encrypted in transit and at rest, and deleted on a defined schedule?
Why it matters: Confidentiality criteria and CC6.7 cover how data is protected while you hold it and disposed of when you do not need it.
What to do: Define classification levels, confirm encryption on every data store and connection, and set a retention and deletion schedule.
Criteria: CC6.7, C1.1, C1.2. Template: Data Classification and Handling Policy

The phases, in order

A SOC 2 audit checklist is only half the picture; the other half is sequencing. The work usually happens in the order below. How long each phase takes depends on your starting point, your scope and your auditor, so no durations are given here except where a convention exists.

Phase	What happens	Done when
Before scoping	Find out what is actually being asked for. Read the security questionnaire or contract clause that started this, and confirm whether the customer wants a Type I, a Type II, or either.	You know which report type, which Trust Services Categories beyond Security, and roughly when someone needs it.
Scoping	Decide which product, systems, people and vendors are inside the boundary. Smaller is easier to evidence, but it has to match what customers are relying on.	A written scope statement naming the system, the categories in scope and the subservice providers (usually your cloud host).
Policies	Adopt a policy set that describes the controls you run or are about to run, have management approve it, and collect acknowledgments from everyone in scope.	Approved, dated policies with an owner and review cadence each, and a signed acknowledgment per person.
Controls running	Turn the policies into operating controls: MFA enforced, branch protection on, the first access review done, the risk assessment completed, backups restored once. Close the gaps this checklist surfaces.	Every item below is a yes, or a documented decision explains why it does not apply.
Type I examination	A CPA firm tests whether the controls are suitably designed and in place on a single date. Optional: some companies skip it and go straight to a Type II.	A Type I report you can share under NDA, and a list of any design issues to fix before the observation period.
Observation period	The controls run on their stated cadence and leave evidence: quarterly reviews happen each quarter, every change is reviewed, every leaver is removed on time. The length of the window is agreed with your auditor.	A complete evidence trail for the whole window, with no quarter missed.
Type II examination	The auditor samples from the observation period to test whether the controls operated effectively throughout it, then issues the report.	A Type II report covering the period, and a calendar for the next one.

On the observation period: there is no single required length. Windows of three to twelve months are typical, and a first Type II is often on the shorter end. Agree it with your auditor and, where it matters, with the customer asking for the report. See Type I vs Type II for what changes between the two.

The step people most often get wrong is starting the observation period before the controls are running. A quarterly access review that has never happened cannot be sampled, and a policy approved halfway through the window only covers the half after it. Get the checklist to all yeses first, then start the clock.

What this checklist does not cover

Twenty questions are a filter, not an exhaustive list. They leave out things that depend on your scope: processing integrity and privacy criteria, physical security if you run your own premises, and the system description your auditor will ask you to write. They also cannot tell you whether a control is designed well enough for your particular risks; that judgment belongs to the CPA firm. For what auditors ask once the policies exist, read what auditors ask about policies.

Frequently asked questions

Is there an official SOC 2 checklist?: No. The AICPA publishes the Trust Services Criteria, which describe what has to be achieved, and each company designs its own controls to meet them. A checklist like this one is a way to find gaps before an auditor does; it is not a list the auditor works from.
If I can tick every item, am I ready for an audit?: You are in a much better position, but twenty questions cannot cover every criterion or every scope. Treat a full set of ticks as a reason to talk to a CPA firm about a readiness review and dates, not as a prediction of the outcome. Only the firm that examines you can form an opinion on your controls.
What is the difference between this checklist and the readiness assessment?: They use the same twenty questions. This page lists them with the reasoning and the fix for each, so you can read, print or download them. The readiness assessment lets you answer yes, partly or no and gives you a score, a breakdown by area and a gap list in priority order. Your answers stay in your browser.
Do I need a Type I before a Type II?: No. A Type I is optional. It tests design on a single date and can give a customer something sooner, but many companies go straight to a Type II. Either way the checklist items are the same; what changes is how long the controls must have been running when the auditor looks.
Which items should I do first?: Written and approved policies, a risk assessment and MFA everywhere. Most other controls refer back to one of those three, and they are also what auditors and customer security questionnaires ask about first.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.