SOC 2 Compliance Checklist: Every Requirement, Control and Evidence Item

Photo: Unsplash

SOC 2 compliance checklist

Most SOC 2 checklists you find online list about fifteen generic tasks and stop. That is not what an auditor works from. A SOC 2 audit tests your controls against the Trust Services Criteria, and the Security category alone contains 33 individual criteria across nine series (CC1 to CC9). Every one of them needs a control, an owner, and evidence that the control actually operated.

This page is the working checklist: what each series asks for, what your auditor will request as proof, and where teams lose months.

Key takeaways

• SOC 2 has no fixed control list. You design controls, your auditor tests whether they meet the criteria. Two companies with valid reports can have very different controls.
• Security (the Common Criteria, CC1 to CC9) is mandatory in every SOC 2 report. Availability, Confidentiality, Processing Integrity and Privacy are optional and should only be added when you can evidence them.
• Type II is the report buyers ask for, and it tests whether controls operated across an observation window, normally three to twelve months. Evidence has to exist throughout that window, not just on the last day.
• The most common delay is not a missing control. It is a control that exists on paper with no operating record to sample.

---

What a SOC 2 compliance checklist actually covers

SOC 2 is an attestation, not a certification. A licensed CPA firm issues an opinion on whether your controls meet the Trust Services Criteria for the categories you chose. That structure has three consequences for your checklist:

1. You write the controls. The criteria describe an objective ("the entity restricts logical access"). You decide the control that meets it (SSO with enforced MFA, quarterly access reviews). Your checklist is a mapping exercise, not a fill-in-the-blanks form.
2. Scope is your decision and your risk. Include a category you cannot evidence and you invite a qualified opinion.
3. Evidence is sampled from a population. Auditors pick items from across your observation period. A single screenshot dated the week before fieldwork proves nothing.

Step 1: make the four scoping decisions

Get these wrong and the rest of the checklist is rework.

Decision	What to settle	Why it matters
System boundary	Which product, environments, and infrastructure are in scope. Name the AWS or GCP accounts, the repos, the data stores.	Everything inside the boundary gets tested. A boundary drawn too wide adds controls you do not need for the sale.
Trust Services categories	Security is required. Add others only if a customer contract or your system description commits you to them.	Each added category brings its own criteria and its own evidence burden.
Report type	Type I (design at a point in time) or Type II (operating effectiveness over a period).	Buyers almost always want Type II. Type I is a stepping stone, not a destination.
Observation period	Usually three months for a first Type II, six or twelve thereafter.	Evidence must cover the whole window. Pick the start date before you begin collecting.

Write these four into a one-page system description and have your auditor review it before you start remediation. A scoping correction in month one costs a meeting. In month five it costs the audit.

Step 2: work the nine Common Criteria series

The Security category is organised into nine series. Here is what each asks for and the proof auditors request.

CC1: Control environment (5 criteria)

Governance and tone from the top. Auditors look for structure, not sentiment.

• Code of conduct, acknowledged by every employee, with re-acknowledgement on a cadence
• An org chart with security responsibilities named, plus role descriptions
• Evidence of board or leadership oversight of security: meeting minutes where security was actually discussed
• Hiring and competence records for people in security-relevant roles
• Accountability: performance objectives or reviews that reference security responsibilities

CC2: Communication and information (3 criteria)

• Policies distributed and acknowledged, with completion rates you can show
• Security awareness training records
• An external channel: a trust page, a security contact, a documented customer notification path

CC3: Risk assessment (4 criteria)

• A documented risk methodology, not just a spreadsheet of worries
• A risk register with likelihood, impact, owner, treatment and review date
• Explicit consideration of fraud risk
• Assessment of significant change: new products, new infrastructure, acquisitions

CC4: Monitoring activities (2 criteria)

• A plan for evaluating whether your controls work, and the results of doing so
• A deficiency log: what you found, who owns the fix, when it closed

CC5: Control activities (3 criteria)

• A control matrix mapping each criterion to your control
• General IT controls over access, change and operations
• Approved policies with owners and review dates

CC6: Logical and physical access (8 criteria)

The largest series and the one auditors probe hardest.

• Identity and access management configuration: SSO, enforced MFA, a documented permission model
• Access request tickets showing documented approval before access was granted
• Least privilege and segregation of duties, evidenced by role definitions and quarterly user access reviews with sign-off
• Physical access: badge logs for your own offices, or your data centre provider's SOC 2 report for cloud infrastructure
• Media sanitisation and disposal records
• Boundary protection: firewall and security group rules, WAF, VPN
• Encryption in transit and at rest, plus controls on data egress
• Malware and unauthorised software protection: endpoint coverage reports, dependency scanning

CC7: System operations (5 criteria)

• Vulnerability scanning with remediation tracked against a stated SLA
• Monitoring and alerting configuration, plus records of alerts being triaged
• Documented severity criteria for deciding when an event becomes an incident
• Incident tickets with timeline, actions taken and communications sent
• Postmortems with root cause and corrective actions that closed

CC8: Change management (1 criterion)

One criterion, heavily sampled. Auditors pull a set of changes from your observation period and check each one has peer review, testing, approval and a rollback path. Branch protection rules and CI logs do most of this work for you.

CC9: Risk mitigation (2 criteria)

• Business continuity and disaster recovery planning, with a business impact analysis behind it
• Vendor risk management: a register with risk tiers, due diligence on file, annual reviews, and data processing agreements where personal data is involved

Step 3: decide on the four optional categories

Category	Criteria	Add it when	Core evidence
Availability	3	You commit to uptime in contracts or an SLA	Capacity monitoring, backup schedule, and a completed DR test with RTO and RPO results
Confidentiality	2	You handle customer data classified as confidential	Data classification applied to real stores, retention schedule, proof of deletion
Processing Integrity	5	You process transactions where accuracy is the product	Input validation, reconciliation reports, error queues, output checks
Privacy	18	You handle personal information and want to evidence it	Privacy notice, consent records, record of processing activities, DSAR log, breach notification procedure

Privacy carries by far the heaviest load, with roughly as many criteria as CC1 through CC5 combined. Most teams doing a first SOC 2 scope Security only, add Availability and Confidentiality in year two, and use a separate framework for privacy obligations.

Step 4: get the evidence rules right

This is where checklists usually fail, because the control list looks complete while the evidence is unsampleable.

• Link the artefact, not the policy. "Our access control policy requires quarterly reviews" is not evidence. The completed Q2 review with the reviewer's sign-off is.
• Cover the whole window. For a six-month Type II, a quarterly control needs two instances. A monthly control needs six. Count them before fieldwork.
• Keep the population intact. Auditors sample, which means they need the full list to sample from. Export the complete change log, not the twelve changes you think look good.
• Date everything. Undated screenshots get rejected.
• Automate what recurs. Access reviews, vulnerability scans and backup verification are the three that most often have gaps mid-window, because someone was on holiday.

If you want a structured place to track control ownership and evidence status while you work through this, our SOC 2 readiness checklist template is a free Excel workbook with owner, evidence and status fields per control.

Type I vs Type II: what changes on the checklist

	Type I	Type II
Tests	Whether controls are designed appropriately	Whether controls operated effectively over a period
Evidence	Current state at one date	Records spanning the observation period
Timeline	Achievable once controls are in place	Add the observation window on top
Buyer reaction	Often accepted as interim proof	What enterprise security reviews actually ask for

The checklist is the same. The evidence burden is not. Every recurring control on the list above needs multiple dated instances for Type II.

A realistic timeline

For a SaaS company with no formal programme, a first Type II usually runs six to nine months:

1. Weeks 1 to 3: scoping, auditor selection, system description
2. Weeks 3 to 10: gap assessment and remediation, policy set approved, tooling connected
3. Weeks 8 to 12: controls start operating, observation period begins
4. Months 3 to 6: observation window, with evidence accumulating and access reviews running on cadence
5. Final 4 to 8 weeks: fieldwork, auditor sampling, report issued

The observation period is the part you cannot compress. Starting it earlier is the single biggest lever on your timeline, which is why scoping in week one matters so much.

The eight gaps that delay SOC 2 reports

1. Access reviews missed mid-window. A quarterly control with one instance in a six-month window is a finding.
2. Policies approved but never distributed. No acknowledgement records means no evidence of communication.
3. Change management bypassed for hotfixes. Auditors sample; the emergency deploy with no review will surface.
4. Onboarding and offboarding gaps. A departed employee with live access is the finding auditors remember.
5. Vendor register that stops at the name. No risk tier, no review date, no agreement on file.
6. No DR test. Teams scope Availability, then discover they have a backup schedule and no restore evidence.
7. Scoping a category they cannot evidence. Usually Privacy, added optimistically.
8. Evidence stored in Slack threads and personal drives. Nothing can be sampled from a population that does not exist as a list.

How SecureSlate helps

SecureSlate maps your controls to the Trust Services Criteria, collects evidence from your cloud, identity and code systems on a schedule, and keeps the population intact so your auditor can sample it. Access reviews, vendor reviews and policy acknowledgements run on cadence rather than being reconstructed before fieldwork.

Get started for free

Related guides:

• SOC 2 readiness checklist template
• SOC 2 self-assessment checklist
• SOC 2 controls full list and what auditors expect
• How much does a SOC 2 audit cost
• ISO 27001 checklist

FAQ

How many controls are in SOC 2?
There is no fixed number. SOC 2 defines criteria, not controls: 33 Common Criteria for Security, plus 3 Availability, 2 Confidentiality, 5 Processing Integrity and 18 Privacy criteria. Your control count depends on how you design controls to meet them, and typically lands somewhere between 60 and 150.

Is there an official SOC 2 checklist?
No. The AICPA publishes the Trust Services Criteria, which auditors test against, but there is no official checklist and no official control list. Any checklist, including this one, is an interpretation.

Can we do SOC 2 without an auditor?
You can run a self-assessment to find gaps, but a SOC 2 report can only be issued by a licensed CPA firm. Self-assessments are for readiness, not for sending to customers.

Which categories should a first-time SaaS company scope?
Security only, in most cases. Add Availability if you have contractual uptime commitments and can show a completed DR test. Leave Privacy until you have a mature data governance programme.

How long does evidence need to be retained?
Keep it for the full observation period plus the audit, and in practice keep the prior year too, since your next report's auditor will want to see continuity.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory, or professional advice. SOC 2 requirements are interpreted by your auditor and vary by system, industry, and jurisdiction. Consult a licensed CPA firm and qualified advisors for your specific obligations.