There is no canonical “SOC 2 controls list”. The auditor tests the controls you say you operate against the criteria you have selected. What you do have is a fixed set of Trust Services Criteria — 9 Common Criteria categories plus 4 additional categories — and a list of points-of-focus that describe what each criterion is actually testing. The work is to map your existing practices to those criteria, name the controls that demonstrate the criteria, and make sure each cited control has evidence the auditor can sample.
This page is a working checklist. Every Common Criteria category (CC1 through CC9) is here, plus the four additional categories most SaaS companies consider. For each we list the criteria points-of-focus and the controls a typical mid-stage SaaS cites, with a sentence on what evidence the auditor will sample. Use the interactive section below to mark scope, capture the current status, and note where each control’s evidence lives. Your progress saves in your browser; export anytime as Markdown or JSON.
Key takeaways
- The Trust Services Criteria are organised into 9 Common Criteria categories (CC1-CC9) plus 4 additional categories (Availability, Confidentiality, Processing Integrity, Privacy). Security is mandatory; the others are optional.
- There is no fixed list of 'the SOC 2 controls'. The auditor tests the controls you say you operate, against the criteria you have selected.
- A typical Series A SaaS SOC 2 engagement cites 60-120 controls; a mature Series C SaaS cites 150-300+.
- Auditors sample evidence for each cited control across the observation window. A control you cannot produce evidence for is a finding.
- The fastest path is to map your existing practices to the criteria, identify the gaps, then close them in the order the auditor samples.
How to read the Trust Services Criteria
The American Institute of CPAs (AICPA) publishes the Trust Services Criteria. There are 9 Common Criteria (CC1 through CC9) covering the universal aspects of any service organisation, and 4 additional categories — Availability, Confidentiality, Processing Integrity, Privacy — covering optional subject matter. Security (the Common Criteria) is the only mandatory category.
Each category contains several criteria (e.g. CC6.1, CC6.2, CC6.3). Each criterion contains one or more points-of-focus that describe what a control designed to meet the criterion typically addresses. You do not have to address every point-of-focus — you decide which controls to operate, and the auditor evaluates whether those controls meet the criterion.
The framing to remember: a policy is the intent (“we perform quarterly access reviews”). A control is the specific procedure with evidence (“the IAM owner runs an access report on the first Monday of each quarter, sends it to system owners for attestation via the GRC tool, and files the signed report in the controls repository”). Auditors test controls, not policies.
Use it: working checklist
Mark each control as in scope, out of scope, or N/A. For in-scope controls, capture the current status and where the evidence lives. Your progress saves locally to this browser.
Common Criteria (CC1–CC9)
Control environment
The foundation. Does leadership set the tone, approve the policies, and hold someone accountable for security?
- CC1.1
Code of conduct and security policies
A written, leadership-approved information security policy and code of conduct, communicated across the company and acknowledged by employees at hire and annually thereafter.
ScopeStatus - CC1.2
Board and management oversight
A defined cadence (typically quarterly) where leadership reviews security posture, risks, incidents, and audit findings. For early-stage startups this is usually the founders; for Series B+ it is a security steering committee.
ScopeStatus - CC1.3
Defined roles and responsibilities
A named security owner (CISO, Head of Security, or DPO) with a written role description. For small teams this is a founder wearing multiple hats; document it explicitly.
ScopeStatus - CC1.4
Background checks and onboarding
Background screening at hire for employees with access to production data. Document the screening scope, the vendor used, and that it was completed before access was granted.
ScopeStatus - CC1.5
Disciplinary process
A documented disciplinary process for policy violations. Auditors rarely test this directly but want to see it exists.
ScopeStatus
Communication and information
How security information flows up, down, and sideways, and how it is captured in working order.
- CC2.1
Internal security communications
A documented cadence (often monthly) for security updates to engineering, leadership, and customer-facing teams. Slack channel, monthly digest, or all-hands section all count.
ScopeStatus - CC2.2
Security awareness training
Annual security training for all employees plus role-specific training for engineering, support, and anyone with production access. Track completion and reminders.
ScopeStatus - CC2.3
Customer-facing security information
A public trust page, security FAQ, and a process for responding to inbound security questions from prospects. This is what enterprise buyers actually look at first.
ScopeStatus
Risk assessment
Identifying, scoring, and treating risks to the service. The spine of the entire report.
- CC3.1
Annual risk assessment
A documented risk assessment performed at least annually, identifying threats, likelihood, impact, and the controls that mitigate each.
ScopeStatus - CC3.2
Risk register
A risk register tracking each identified risk, its owner, treatment plan, and review date. Reviewed at least quarterly.
ScopeStatus - CC3.3
Fraud risk
An assessment of fraud risk — usually relevant only for fintechs, but worth including if you handle payments or financial data.
ScopeStatus - CC3.4
Risk treatment
Documented treatment plans (accept, mitigate, transfer, avoid) for each material risk, with target dates and owners.
ScopeStatus
Monitoring activities
How you select, develop, and run ongoing and separate evaluations of your controls.
- CC4.1
Ongoing monitoring
Continuous monitoring of controls through automated tooling: SSPM, CSPM, SIEM, dependency scanners. The auditor wants evidence the tool ran and someone reviewed the output.
ScopeStatus - CC4.2
Separate evaluations
Periodic independent evaluations — internal audit, third-party assessments, or penetration tests. Most SOC 2 reports reference at least one annual penetration test.
ScopeStatus
Control activities
The specific policies and procedures that operate the controls. Often called the 'P2s'.
- CC5.1
Documented procedures
Written procedures for each control: who does what, when, with what tooling, and what gets recorded. Auditors sample these procedures against evidence.
ScopeStatus - CC5.2
Technology general controls
Procedures for managing the technology that delivers your controls — how identity providers, log aggregation, and access management systems themselves are configured and reviewed.
ScopeStatus - CC5.3
Policy deployment
A mechanism to deploy and update policies across the organisation — typically an HRIS-driven acknowledgement flow plus a wiki or intranet.
ScopeStatus
Logical and physical access
Who can access what, how that is enforced, and how it is reviewed. Usually the highest-volume category.
- CC6.1
Logical access controls
Authentication and authorisation on every system that holds customer data. SSO plus MFA enforced for all production systems and admin consoles.
ScopeStatus - CC6.2
New user provisioning
A documented workflow for granting access at hire or when roles change. The auditor samples new-hire tickets against actual access grants.
ScopeStatus - CC6.3
Access reviews
Quarterly access reviews for systems holding customer data, signed off by system owners. Capture the review, the attendees, and the changes made.
ScopeStatus - CC6.4
Physical access
Physical security at offices and data centres. For cloud-first SaaS, this is almost always a cloud vendor responsibility — inherit the SOC 2 from AWS, GCP, or Azure.
ScopeStatus - CC6.5
Access removal
Offboarding workflow that removes all access within 24 hours of termination. The auditor tests the gap between HR termination date and access revocation.
ScopeStatus - CC6.6
External access boundaries
Network segmentation, firewalls, and the boundaries between your service and the public internet. Cloud security groups, WAFs, and zero-trust network access count.
ScopeStatus - CC6.7
Data in transit and at rest
Encryption in transit (TLS 1.2+, HSTS) and at rest (AES-256 or equivalent) for all customer data.
ScopeStatus - CC6.8
Malicious software prevention
Endpoint protection on employee devices, anti-malware on production hosts, and email security. For SaaS this is usually an EDR agent plus email filtering.
ScopeStatus
System operations
Monitoring, incident detection, and incident response. The auditor's second-favourite place to sample.
- CC7.1
Production change detection
Detection of unauthorised changes to production — usually file integrity monitoring, drift detection, or the combination of code review + deployment logging.
ScopeStatus - CC7.2
Security event logging
Centralised logging of authentication events, privileged actions, and security-relevant activity with at least 90 days of retention.
ScopeStatus - CC7.3
Alerting and triage
Alerting on auth anomalies and privileged actions, with an on-call rotation that responds. Document the rotation, the alert channels, and the mean time to acknowledge.
ScopeStatus - CC7.4
Incident response
A documented incident response plan, tested at least annually through a tabletop exercise. Include severity classification, escalation paths, communications templates, and customer notification criteria.
ScopeStatus - CC7.5
Recovery and continuity
Documented recovery procedures — both for incidents and for disaster recovery. Backup restoration tested annually; failover tested where applicable.
ScopeStatus
Change management
How production changes are requested, approved, tested, and deployed.
- CC8.1
Change request and approval
Production changes go through a documented change request process — usually a pull request with peer review, automated tests, and an approval gate before merge.
ScopeStatus - CC8.2
Tested and approved changes
Changes are tested before production deploy. For SOC 2 the auditor wants evidence the tests ran and passed — automated test results, staging sign-off, or QA records.
ScopeStatus - CC8.3
Emergency changes
A documented process for emergency changes that bypass normal review — typically restricted to named on-call engineers with post-deploy review.
ScopeStatus
Risk mitigation
Vendor management, insurance, and the broader business continuity considerations.
- CC9.1
Vendor identification
A current inventory of vendors (sub-processors) that handle customer data, classified by criticality.
ScopeStatus - CC9.2
Vendor due diligence
Annual collection and review of vendor SOC 2 / ISO 27001 reports for critical vendors. Document the report received, the review date, and any findings accepted.
ScopeStatus
Additional categories
Availability
Optional, but almost always in scope for SaaS. Covers uptime commitments, capacity, and recovery.
- A1.1
Capacity planning
Documented capacity model and monitoring of headroom. Auditors want evidence of monitoring and at least one capacity review during the observation window.
ScopeStatus - A1.2
Environmental protections
Backup power, redundant connectivity, geographic redundancy for production. Inherited from the cloud provider SOC 2 in most cases.
ScopeStatus - A1.3
Disaster recovery testing
Annual DR test that exercises recovery of a production system from backup or failover. Document the test, the RTO/RPO achieved, and any gaps identified.
ScopeStatus
Confidentiality
Optional. Covers the controls around confidential information beyond customer personal data.
- C1.1
Confidential information identification
A data classification scheme that labels confidential information and prescribes handling requirements per classification.
ScopeStatus - C1.2
Confidentiality commitments
Customer-facing commitments to confidentiality — typically in the MSA, DPA, or a public security page.
ScopeStatus
Processing integrity
Optional, rarely in scope for SaaS unless you process financial transactions or other high-integrity data.
- PI1.1
Processing accuracy
Controls that ensure processing is complete, accurate, timely, and authorised. Reconciliations, input validation, and audit trails.
ScopeStatus
Privacy
Optional. Overlaps with GDPR; choose Privacy if you collect personal data and want a single framework for both US and EU requirements.
- P1.1
Privacy notice
A public privacy notice covering collection, use, retention, sharing, and choices.
ScopeStatus - P2.1
Choice and consent
Mechanisms for users to exercise choices around their personal data — opt-in, opt-out, and consent management.
ScopeStatus - P4.1
Data subject access
Process for handling data subject access requests within statutory timelines (typically 30 days under GDPR).
ScopeStatus - P6.1
Data retention and disposal
Documented retention periods per data category and a disposal process that renders data unreadable at end of life.
ScopeStatus
How many controls do you actually need?
There is no minimum. The auditor tests whatever controls you cite. The practical range:
- Early-stage SaaS: 60–120 controls, usually Security plus Availability. The lower end is acceptable when the company is small and the surface area is genuinely limited.
- Mid-stage SaaS: 120–200 controls. Add Confidentiality if you handle customer confidential information beyond personal data, and Privacy if GDPR is a major compliance driver.
- Mature SaaS: 200–400+ controls. Multiple product lines, regions, and integrations naturally inflate the count.
A higher count is not automatically better. The auditor tests every cited control; a control you cannot produce evidence for is a finding. Citing 400 controls you cannot operate is worse than citing 80 controls you actually run.
How to use this checklist
The fastest path from this page to a clean audit:
- Run the free SOC 2 readiness assessment to get a baseline score and identify the categories with the biggest gaps.
- Walk this checklist category by category. For each control mark scope (in, out, or N/A), then capture the current status and where the evidence lives.
- Identify the gaps. Most SaaS companies discover they are missing controls in CC6 (access), CC7 (operations), and CC8 (change management) — usually because the procedures exist but the evidence is scattered or informal.
- Close the gaps. For the technical controls (TLS, headers, exposed services, deployment logging) AppCheck is a fast way to produce the evidence and a shareable certificate.
- Export your progress as Markdown for your GRC tool or Notion, or download the JSON to back it up. Engage a CPA firm for the actual SOC 2 audit using your exported scope and evidence index.
This checklist is a scoping tool, not an audit deliverable. For the technical controls — TLS, security headers, access control on admin endpoints, exposed services, dependency risk, source review — AppCheck produces the evidence auditors accept and issues a shareable certificate, for a flat €500 per audit. Request an audit.
Frequently asked questions
How many SOC 2 controls do I need?
There is no minimum. You cite the controls that map to the criteria you have selected, and the auditor tests what you cite. A typical Series A SaaS cites 60-120 controls across Security plus one or two additional categories. A mature enterprise SaaS cites 150-300+. The right number is the smallest set that genuinely reflects what your company does — citing 400 controls you cannot operate is worse than citing 80 controls you actually run.
Do I have to include all the Trust Services Criteria?
No. Security (the Common Criteria, CC1-CC9) is the only mandatory category. Availability, Confidentiality, Processing Integrity, and Privacy are optional. Most SaaS companies select Security plus Availability, sometimes adding Confidentiality or Privacy if those are material to their offering.
Can I just copy a controls list from a SOC 2 template?
You can start from one, but you cannot end with one. The auditor tests whether your controls are actually operating, and a control that does not reflect how your company actually works will fail at the evidence stage. The fastest path is to map what you already do against the criteria, then write the controls in your own words to match your reality.
What's the difference between a control and a policy?
A policy is the high-level statement of intent — 'we perform quarterly access reviews'. A control is the specific procedure, with evidence — 'the access review owner runs an IAM report on the first Monday of each quarter, sends it to system owners for attestation via our GRC tool, captures signatures, and files the report in the controls repository'. Auditors want controls, not policies.
How does the controls list connect to evidence?
Each cited control needs to point to evidence the auditor can sample. For access reviews, the evidence is the signed review report. For change management, it is the pull request, the deployment record, and the approver. For incident response, it is the incident ticket, the postmortem, and the customer notification if applicable. If you cannot name the evidence, the control is not ready for audit.
Does my progress save?
Yes. Your scope decisions, status, and evidence notes save locally to your browser via localStorage. Nothing is sent to a server. You can also export your progress as Markdown (for Notion, Confluence, or your GRC tool) or download it as JSON to back up or hand off to a teammate.
How does AppCheck fit into this checklist?
AppCheck is not a SOC 2 audit — only a licensed CPA firm can issue a SOC 2 report. AppCheck produces the technical evidence auditors accept across several criteria in this list, particularly CC6.6 (network boundaries), CC6.7 (encryption in transit), CC7.2 (security event logging), CC8.1 (change management via deployment logging), and CC4.2 (separate evaluations). It is a complement, not a substitute, for a SOC 2 audit.