SOC 2 controls are the policies, processes, technical safeguards, and operational activities your organization uses to satisfy the SOC 2 Trust Services Criteria in your audit scope. There is no official universal SOC 2 controls checklist. The AICPA’s Trust Services Criteria are criteria for evaluating controls over the security, availability, processing integrity, confidentiality, or privacy of systems and information used to provide services. Not a fixed catalog of required controls.
That distinction matters. A useful SOC 2 control set is not copied from a template and declared complete. It is designed around your systems, risks, services, customer commitments, data, vendors, and selected Trust Services Criteria. The practical goal is to turn criteria into controls with clear owners, evidence, cadence, and operation that an auditor can test.
What SOC 2 Controls Are — And What They Are Not
SOC 2 controls are your organization’s implementation of the relevant Trust Services Criteria. They may include:
- Policies, such as access control, incident response, vendor management, and change management policies
- Technical safeguards, such as MFA, encryption, logging, alerting, and backup configuration
- Operational processes, such as access reviews, risk assessments, vendor reviews, and vulnerability remediation
- Evidence-producing activities, such as approvals, tickets, logs, review records, and test results
A SOC 2 engagement is an assertion-based examination of a service organization’s system description and controls relevant to selected Trust Services Criteria. Customers and business partners may request a SOC 2 report to understand control design, operation, and effectiveness, but the report is scoped to the system and criteria examined rather than a general proof of security.
The AICPA’s Trust Services Criteria require judgment in application. Organizations design controls for their circumstances; the criteria do not prescribe one universal set of controls. That means control count is not basically the right starting question. A small SaaS company, a data platform, and a managed service provider may all need different control sets because their systems, commitments, risks, and in-scope criteria differ.
A starter list is still useful. It helps you identify the control areas most SOC 2 readiness projects need to evaluate. But the list only becomes audit-ready when each control is scoped, assigned, performed, evidenced, and aligned with the criteria and commitments in your report.
How SOC 2 Criteria Become Controls, Evidence, And Auditor Tests
SOC 2 control design starts with the Trust Services Criteria, then moves through interpretation, implementation, evidence, and testing. That is the simple version. More accurately, it can move back and forth a little as the control language gets matched to the organization.
The core layers are:
- Trust Services Criteria — The AICPA criteria used to evaluate controls over security, availability, processing integrity, confidentiality, or privacy.
- Common Criteria — Criteria that address controls relevant across the Trust Services Criteria.
- Points of focus — Characteristics that can help management and practitioners design and evaluate controls. They are not a requirement to assess every point of focus and may be customized, irrelevant, or supplemented based on the entity and engagement.
- Controls — The organization-specific activities designed to meet the applicable criteria.
- Evidence — Records showing the control exists and, where applicable, operated as described.
- Auditor testing — Procedures performed by the service auditor to evaluate controls and report test results in a Type 2 engagement.
For example, a logical access criterion may lead to a control such as quarterly access reviews for production systems. The evidence may include user listings, review records, approval timestamps, and remediation tickets for inappropriate access. The auditor’s testing may evaluate whether the control was designed as described and whether it operated during the examination period.
The Type 1 and Type 2 distinction affects how much operating evidence you need. A Type 1 SOC 2 report addresses the relevant subject matter at a specified date and does not include an opinion on operating effectiveness. A Type 2 report addresses design and operating effectiveness throughout a specified period and includes tests of controls and their results. For Type 2 readiness, evidence should support not only that the control exists, but that it operated consistently during the period.
Practical SOC 2 Starter Controls Matrix
The matrix below is an illustrative, scope-dependent starter matrix for a small to midmarket SaaS environment. It is not an official, complete, or universally sufficient SOC 2 checklist. Treat the criteria column as “criteria to verify,” not a one-to-one mapping. Your auditor, system description, selected Trust Services Criteria, and risk assessment should determine the final control set.
| Control area | Illustrative control | Related Trust Services Criteria / Common Criteria to verify | Example owner | Evidence examples an organization may maintain | Example frequency | Example auditor test approach |
|---|---|---|---|---|---|---|
| Governance | Maintain approved information security policies and review them for alignment with current operations. | Security / Common Criteria; other selected criteria depending on policy scope | Security or GRC lead | Approved policies, review history, change log, management approval | Annual or upon material change | Inspect policy approval and review evidence; compare policy requirements to described control activities |
| Risk management | Maintain a risk register and document risk assessments, treatment decisions, and ownership. | Security / Common Criteria; may support other selected criteria | Security, GRC, or executive risk owner | Risk register, assessment notes, treatment plans, accepted risks | Periodic and upon significant change | Inspect risk assessment records and verify selected risks have owners and treatment status |
| Access control | Require approved, role-based access for in-scope systems and review access periodically. | Security / Common Criteria; Confidentiality or Privacy if in scope | IT, security, or system owner | Access requests, approvals, user listings, review sign-offs, remediation tickets | Upon access change and periodic review | Sample users or access reviews; inspect approval, role appropriateness, and remediation evidence |
| HR security | Perform defined onboarding and offboarding steps for personnel with access to in-scope systems. | Security / Common Criteria; Confidentiality or Privacy if in scope | People/HR and IT | HR records, onboarding tickets, access provisioning logs, termination tickets, deprovisioning logs | At hire, role change, and termination | Compare HR population to access changes; inspect timely provisioning or removal evidence |
| Vendor management | Evaluate vendors that support in-scope services or handle in-scope data. | Security / Common Criteria; Confidentiality, Privacy, or Availability depending on vendor role | GRC, security, legal, or procurement | Vendor inventory, risk reviews, contracts, security questionnaires, SOC reports where available | Before onboarding and periodic review | Inspect vendor inventory and selected vendor review records; verify risk decisions are documented |
| Encryption | Protect in-scope data using defined encryption requirements where appropriate. | Security / Common Criteria; Confidentiality or Privacy if in scope | Engineering, security, or infrastructure | Architecture diagrams, cloud configuration exports, key management settings, encryption policy | Continuous configuration with periodic review | Inspect configurations or exports supporting encryption design for selected systems |
| Logging and monitoring | Collect and monitor security-relevant logs for in-scope production systems. | Security / Common Criteria; Availability if monitoring supports uptime commitments | Security, SRE, or infrastructure | Logging configuration, alert rules, monitoring dashboards, alert records, incident tickets | Continuous monitoring with periodic review | Inspect logging and alert configurations; trace selected alerts to review or response records |
| Vulnerability management | Identify, track, and remediate vulnerabilities according to defined severity and risk treatment rules. | Security / Common Criteria | Security or engineering | Scan results, remediation tickets, exception records, risk acceptances, retest evidence | Recurring scans and risk-based remediation | Inspect scan results and sample findings; verify remediation, exception, or risk acceptance evidence |
| Change management | Require documented review, testing, and approval for production changes. | Security / Common Criteria; Availability or Processing Integrity if in scope | Engineering | Pull requests, code reviews, test results, deployment records, approvals | Per production change | Sample production changes; inspect review, approval, testing, and deployment evidence |
| Incident response | Maintain and test an incident response process for security events affecting in-scope systems. | Security / Common Criteria; Confidentiality, Privacy, or Availability depending on incident type | Security, engineering, or incident commander | Incident response plan, incident tickets, postmortems, tabletop records, communication logs | As incidents occur; periodic exercise | Inspect plan and selected incident or exercise records; verify roles, actions, and follow-up items |
| Backups | Maintain backups for in-scope systems and verify restoration capability where relevant. | Availability if in scope; Security / Common Criteria where backups support recovery | Infrastructure, SRE, or database owner | Backup configuration, backup job logs, restore test records, remediation tickets | Scheduled backups; periodic restore testing | Inspect backup configuration and selected backup or restore records |
| Business continuity / disaster recovery | Maintain documented recovery procedures for material service disruption scenarios. | Availability if in scope; Security / Common Criteria where continuity supports service commitments | Operations, SRE, security, or leadership | BCP/DR plan, recovery objectives, test records, lessons learned, action items | Periodic review or exercise | Inspect recovery plan and exercise evidence; verify issues are tracked to resolution |
| Availability | Monitor service availability and respond to events affecting contractual or operational uptime commitments. | Availability if selected; Security / Common Criteria for supporting operations | SRE, engineering, or operations | Uptime monitoring, incident records, status page records, SLA review notes, capacity alerts | Continuous monitoring; periodic review | Inspect monitoring configuration and selected availability events; compare response evidence to defined process |
Use this matrix as a readiness planning tool. For each row, refine the wording until it is specific enough to test. “Access is reviewed” is weak. “The system owner reviews production administrative access quarterly, documents approval or removal decisions, and tracks remediation to completion” is usually easier to test.
How To Tailor SOC 2 Controls To Your Scope
SOC 2 control selection depends on what your report covers. The same control area can require different evidence depending on the system boundary, data handled, criteria selected, and commitments made to customers.
Use this decision aid to narrow the starter matrix into a scoped control set.
| System or data condition | Why it matters | Controls to consider | Evidence implications | Scope dependency |
|---|---|---|---|---|
| You store or process customer confidential data | Confidential data can affect control design for access, encryption, retention, and vendor handling | Access control, encryption, logging, vendor management, data handling policies | Access reviews, encryption configuration, vendor security reviews, data flow diagrams | Stronger relevance if Confidentiality is in scope or contracts define confidentiality commitments |
| You make availability commitments in contracts, SLAs, or customer-facing documentation | Availability commitments may need controls over monitoring, incident response, backups, and recovery | Availability monitoring, incident response, backups, BCP/DR, capacity monitoring | Uptime records, incident tickets, backup logs, restore tests, DR exercise records | Most relevant when Availability is selected or commitments are included in the system description |
| Third-party vendors process in-scope data or support in-scope services | Vendor failures can affect your control environment and service commitments | Vendor inventory, vendor risk review, contract review, ongoing monitoring | Vendor risk assessments, contracts, SOC reports where available, review records | Depends on vendor role, data access, and whether the vendor is included or carved out of scope |
| Production deployments are frequent | Frequent changes increase the need for consistent approval, testing, and traceability | Change management, code review, deployment controls, segregation of duties where relevant | Pull requests, approvals, CI/CD logs, test results, deployment records | Depends on engineering workflow and whether production systems are in scope |
| Employees or contractors have privileged cloud, database, or production access | Privileged access can materially affect system security and availability | Access approvals, MFA, privileged access reviews, offboarding, logging | User listings, approval records, MFA configuration, review sign-offs, deprovisioning evidence | Depends on identity architecture, privileged roles, and system boundary |
| Privacy is in scope, not only security | Privacy criteria may require additional controls around personal information handling | Data inventory, consent or notice processes, privacy request handling, vendor privacy review | Data maps, privacy procedures, request logs, retention records, vendor privacy terms | Only applies if Privacy is selected and relevant to the service organization’s commitments |
| You rely on cloud-managed services | Cloud architecture affects what your team controls directly and what is inherited from providers | Cloud configuration review, vendor review, access control, logging, backup configuration | Cloud exports, architecture diagrams, provider reports, configuration evidence | Depends on shared responsibility model and in-scope cloud services |
| Existing policies do not match engineering practice | A mismatch between policy and actual operation creates weak evidence and unclear testing | Policy review, control redesign, workflow alignment | Updated policies, workflow records, approval history, implementation evidence | Depends on whether the policy describes in-scope controls or commitments |
The practical test is simple: if a control appears in your matrix, you should be able to answer five questions.
- What risk, criterion, or commitment does it support?
- Which system, process, or population does it cover?
- Who owns performance and evidence?
- How often does it operate?
- What record proves it happened?
If you cannot answer those questions, the control is probably not ready for audit planning.
What Evidence Makes SOC 2 Controls Audit-Ready
A written control does not prove operation, evidence should connect directly to the control wording and show performance, review, approval, or remediation where applicable.
For access reviews, evidence may include the user population reviewed, the reviewer’s sign-off, timestamps, exceptions identified, and tickets showing removal or role correction. A spreadsheet with names but no reviewer, date, scope, or remediation trail may not show that the control operated as described.
For onboarding and offboarding, useful evidence may include HR records, access request tickets, approval records, provisioning logs, termination dates, and deprovisioning records. The key is traceability from the personnel event to the system access change.
For change management, evidence may include pull requests, code reviews, test results, approvals, deployment logs, and rollback or incident records where relevant. If your control says changes are approved before deployment, the evidence should show approval before deployment, not just a merged ticket after the fact.
For vendor management, evidence may include a vendor inventory, risk assessment, contract review, security review, SOC report where available, and documented acceptance of residual risk. The vendor’s relevance to in-scope services and data should be clear.
For vulnerability management, evidence may include scan results, triage records, remediation tickets, retest evidence, exception records, and risk acceptance approvals. If remediation deadlines vary by severity, evidence should show how severity was assigned and how exceptions were handled.
For incident response, evidence may include incident tickets, timelines, postmortems, tabletop records, communication logs, and follow-up action tracking. If there were no incidents, tabletop or exercise records may help demonstrate that the process exists and has been practiced.
For backups and recovery, evidence may include backup job logs, backup configuration, restore tests, DR exercises, and action items from failed or partial tests. A backup configuration alone does not necessarily show that restoration has been verified.
For logging and monitoring, evidence may include alert configuration, log source inventory, monitoring dashboards, alert history, and records showing investigation or escalation. Screenshots should be timestamped or otherwise traceable enough to support the period under review.
For a Type 2 engagement, evidence should support the control’s stated design and, where applicable, its operation during the examination period. That usually means evidence needs to be retained consistently, not reconstructed at the end of the audit window.
Common Control And Evidence Gaps To Review Before The Audit
Before entering audit readiness or fieldwork, review for gaps such as:
- Access reviews completed without a defined population, reviewer, date, or remediation trail
- Terminated users with unclear deprovisioning evidence
- Production changes missing approval, testing, or deployment traceability
- Vendor reviews documented for some vendors but not tied to the in-scope vendor inventory
- Backup jobs configured but restore tests undocumented
- Disaster recovery plans written but not exercised or updated after system changes
- Vulnerability findings closed without remediation evidence, retest results, exception approval, or risk acceptance
- Policies that describe a process different from the engineering workflow actually used
- Control owners named in documents but not responsible for collecting or retaining evidence
- Evidence scattered across tickets, cloud consoles, HR systems, and spreadsheets with no consistent retention method
These are not universal audit findings or ranked failure patterns. They are practical readiness checks. The clear issue is whether a reviewer can trace each control from scope, to owner, to operation, to clear evidence.
Turning SOC 2 Controls Into An Ongoing Operating System
SOC 2 control work becomes harder when it is managed as a one-time spreadsheet exercise. A more sustainable approach is to treat controls as operating responsibilities:
- Assign one accountable owner for each control.
- Align policy language with the workflow teams actually follow.
- Define the evidence source before the audit period starts.
- Keep cadence explicit: per change, per hire, continuous, monthly, quarterly, annual, or event-driven.
- Track exceptions and risk acceptance instead of leaving gaps unexplained.
- Reuse well-designed controls across relevant frameworks where appropriate.
- Keep risks, controls, evidence, vendors, and questionnaires connected.
Ciphrix can support this operating model by helping teams structure control ownership, evidence workflows, reusable controls, and readiness activities in one compliance workspace. It should not replace professional judgment, control ownership, or the independent auditor’s work; it is an execution aid for making scoped controls easier to operate and maintain.
SOC 2 readiness is not about copying the longest checklist. It is about designing controls that fit your scope, assigning owners, collecting evidence as work happens, and showing that controls operate the way you said they would.