Criteria, controls and evidence: what a SOC 2 controls list is
People searching for a SOC 2 controls list usually want a checklist they can copy. SOC 2 does not come with one. It is built from three layers, and keeping them apart makes the rest of the work much easier:
| Layer | What it is | Who writes it | Example |
|---|---|---|---|
| Criteria | What must be achieved | The AICPA (the 2017 Trust Services Criteria) | Access is granted on authorization and removed when it is no longer needed (CC6.2) |
| Controls | What you do to achieve it | You | Engineering leadership reviews access to production systems every quarter and removes what is not needed |
| Evidence | Proof that you did it | Your systems and your people | The exported user lists, the reviewer's sign-off and the tickets for the removed accounts |
The criteria describe outcomes. Your controls are the specific activities and safeguards that produce those outcomes in your company. Evidence is the record each control leaves behind. A SOC 2 controls list is therefore your own list: the controls you designed, each tied to the criteria it supports.
Why there is no mandated list of SOC 2 controls
The criteria are deliberately general so they fit a five-person startup and a large enterprise alike. You decide how to meet each one, describe your controls in the system description that goes into your report, and the auditor tests them. A Type 1 report looks at whether the controls are suitably designed at a point in time. A Type 2 report also tests whether they operated over an observation period, commonly 3 to 12 months (your auditor sets yours). See SOC 2 Type 1 vs Type 2 for the difference.
That freedom cuts both ways. Whether a control is good enough to meet a criterion is the auditor's judgment, so agree your list with them early. And you are tested against what you wrote: a control you describe but don't perform becomes an exception.
A control your auditor can test answers five questions: who does it, what exactly they do, how often or on what trigger, which systems it covers, and what evidence it leaves. For example:
Note: Example control. AC-04 User access review. Each quarter, the Head of Engineering reviews accounts in the identity provider, the cloud console and the production database. Access that is no longer needed is removed within five business days. Evidence: exported user lists, the reviewer's sign-off and the removal tickets.
Give each control a short ID like this. It makes the controls matrix, evidence requests and auditor conversations much easier to follow.
Policy-type, recurring and event-driven controls
Most controls fall into one of three kinds. They are triggered differently, so they leave different evidence and get tested differently.
| Kind | Triggered by | Examples | Typical evidence |
|---|---|---|---|
| Policy-type | A standing rule or configuration | An approved access control policy, MFA required everywhere, encryption at rest | The approved policy version, acknowledgements, configuration screenshots or exports |
| Recurring | The calendar | Quarterly access review, monthly scan review, annual risk assessment | One record per period, signed off |
| Event-driven | Something happening | Onboarding, offboarding, production changes, incidents, new vendors | A ticket or record per event, showing it was handled as the control says |
Event-driven controls are easy to underestimate. For a Type 2 audit, auditors often ask for the full population of events in the period (every hire, every leaver, every production change) and then pick a sample to test. Your onboarding and offboarding checklists, change approvals and incident records need to be complete for every event, not only the ones you remember. Recurring controls have their own rhythm; the SOC 2 compliance calendar lays them out by cadence.
SOC 2 controls examples for a small SaaS company
The tables below are a common starting set for a small SaaS company running on a cloud provider. Treat them as examples, not requirements. The frequencies are common choices: your policies set them, and your auditor decides what evidence is enough. Criteria references follow the 2017 Trust Services Criteria and are indicative. The policies behind these controls are covered in which SOC 2 policies you need.
Governance and people (CC1, CC2)
| Control | How often | Example evidence |
|---|---|---|
| Security policies are approved by management and reviewed | Annually, and on change | Approved policy versions with approver and date |
| Employees acknowledge the policies that apply to them | At hire and when a policy changes materially | Acknowledgement records per person and version |
| Background checks where lawful | At hire | Completed check confirmation in the HR record |
| Security awareness training | At hire and annually | Training material and completion roster |
| Management reviews security risks, incidents and gaps | Quarterly | Agenda, attendees and decisions |
| Roles and reporting lines are defined; performance is reviewed | Annually | Current org chart, review completion record |
Risk (CC3)
| Control | How often | Example evidence |
|---|---|---|
| Risks are identified, rated and treated, including fraud risk | Annually | Risk register snapshot and treatment decisions |
| Significant changes (new product, new region, acquisition) are assessed for risk | On change | Updated register entry or meeting notes |
Access (CC6)
| Control | How often | Example evidence |
|---|---|---|
| Unique accounts with SSO or MFA on in-scope systems | Continuous | Identity provider settings showing MFA enforced |
| Access is granted only with approval | Each new hire or access request | Access request ticket with approver |
| Access is removed promptly when people leave | Each leaver | Offboarding ticket with completion time |
| User access is reviewed | Quarterly | User lists, reviewer sign-off, removals (see how to run a user access review) |
| Data is encrypted at rest and in transit | Continuous | Storage and TLS configuration exports |
| Asset inventory and firewall rules are reviewed | Semi-annually | Inventory export, rule review and changes made |
Change management (CC8)
| Control | How often | Example evidence |
|---|---|---|
| Code changes are peer reviewed and approved before merging | Each change | Pull requests showing a reviewer other than the author |
| Automated tests run before deployment | Each change | CI pipeline configuration and run history |
| Emergency changes are reviewed after the fact | Each emergency change | Ticket with the retrospective approval |
Operations and monitoring (CC4, CC7)
| Control | How often | Example evidence |
|---|---|---|
| Security-relevant events are logged and alert the right people | Continuous | Alert rules and a sample of alerts handled |
| Vulnerability scan results are triaged | Monthly | Scan results and triage decisions |
| An independent penetration test is performed | Annually | Report, findings and remediation tickets |
Incident response (CC7)
| Control | How often | Example evidence |
|---|---|---|
| Incidents are logged, classified and tracked to closure | Each incident | Incident tickets with timeline |
| Significant incidents get a post-incident review | Each significant incident | Review notes and follow-up actions |
| The incident response plan is exercised | Annually | Tabletop scenario, participants and lessons learned (see how to run a tabletop) |
Vendors (CC9)
| Control | How often | Example evidence |
|---|---|---|
| New vendors handling your data are assessed before use | Each new vendor | Completed assessment and approval |
| Critical vendors are reviewed | Annually | Vendor list, their SOC reports, risk ratings |
Availability (A1, if in scope)
| Control | How often | Example evidence |
|---|---|---|
| Capacity and performance are monitored | Continuous | Monitoring dashboards and alert rules |
| Backups run and are restored as a test | Backups daily; restore test quarterly | Backup configuration, restore record with integrity check |
| Disaster recovery is tested | Annually | Test plan, recovery times achieved, issues found |
For how to keep all of this findable, see SOC 2 evidence collection.
How a controls matrix maps controls to criteria
A controls matrix is a table that maps each criterion to the controls that meet it, and each control to its evidence. The mapping is many-to-many: one quarterly access review supports several access criteria, and one criterion is usually met by a policy plus one or two activities.
| Criterion | Controls | Evidence |
|---|---|---|
| CC6.2, CC6.3 | Access Control Policy; access requests; offboarding; quarterly access review | Approved policy, tickets, review records |
| CC8.1 | Change Management Policy; peer-reviewed pull requests; CI tests | Approved policy, sampled pull requests, pipeline history |
Auditors like a matrix because it answers their first questions at a glance: is every criterion in scope covered by something, which control do they test for each one, and where is the evidence. It also shows you the gaps before they do: a criterion with nothing mapped to it is a problem you can still fix. Many auditors build their own testing workpapers from your control list, so the format is theirs to decide, but a clean matrix makes that step faster.
Running your SOC 2 controls in Confluence
If your team works in Confluence Cloud, Compliance in a Box sets up the policy-type and recurring parts of this list in a dedicated compliance space, with every page mapped to SOC 2 criteria:
- Policies. 20 policy pages for Security, and up to 24 with the optional categories. Each one is approved by its approvers, bound to the exact page version they saw, reviewed every 12 months by default, and, where the policy calls for it, acknowledged by employees with one click. People who join a policy's audience later are asked to acknowledge the current version.
- Recurring activities. 13 activities for Security, 15 with Availability, each with an owner, approvers and a Monthly, Quarterly, Semi-annual or Annual schedule. Before each period is due, the app creates an evidence page with a checklist of what to collect, and the owner submits it for approval.
- A generated controls matrix. The Controls Matrix page lists every criterion in the categories you selected, with the mapped policies and activities, a link to each and its current status. Each criterion rolls up to Covered, Attention or Gap, and the top of the page totals them.
A criterion is Covered when every mapped policy is approved and every mapped activity has an approved period with nothing overdue. It needs Attention while work is in progress, such as changes pending or a skipped period. It is a Gap when a mapped policy was never approved or is overdue for review, an activity period is overdue, or nothing is mapped at all.
The matrix is rebuilt from the app's records daily, and a Compliance Admin can click Refresh now under Settings before an audit. It is restricted to Compliance Admins and the optional Auditors group. See the guide on the controls matrix and the full SOC 2 control mappings.
Tip: The mappings are a starting point, not audit advice. Walk your auditor through the matrix early, and adjust your controls to what they expect.
FAQ
What controls does SOC 2 require?
None by name. SOC 2 requires that your controls meet the Trust Services Criteria in scope. You choose the controls, and your auditor judges whether they are designed well enough and, for a Type 2 report, whether they operated.
How many controls does a SOC 2 audit have?
There is no fixed number. It depends on your scope, your systems and how finely you split your controls. Fewer, clearly described controls that you actually perform are better than a long list you can't keep up with.
Is a controls list the same as a policies list?
No. Policies are one kind of control: they set the rules. Most controls are activities, recurring or event-driven, that show the rules are followed. You need both.
Can one control cover several criteria?
Yes, and that is normal. A quarterly access review commonly supports several access criteria. The controls matrix is where you record those links.