SOC 2 Controls List Explained: Common Criteria, Evidence, and Ownership

Overview

This section gives you a working model for reading any SOC 2 controls list without getting lost in policy language.

SOC 2 is not a single checklist of identical tasks for every company. It is a framework for evaluating whether your controls are designed appropriately and operating consistently against the Trust Services Criteria. For many SaaS companies, the starting point is the Common Criteria, which cover broad areas like control environment, risk management, access, change management, vendor oversight, and system operations.

In practice, teams usually struggle with three questions:

• What is the control trying to prevent or detect?
• What evidence proves the control exists and is followed?
• Which team owns the control, and which teams support it?

A useful SOC 2 controls list should answer all three. If your spreadsheet only contains control IDs and vague statements, it will be difficult to operate, difficult to test, and difficult to maintain as your environment changes.

Before getting into the checklist, it helps to treat each control as having four parts:

1. Objective: The risk the control addresses.
2. Control activity: The actual process, technical setting, review, or approval step.
3. Evidence: The artifact showing the control happened.
4. Owner: The person or function accountable for keeping it in place.

For example, a simple access control may have this shape:

• Objective: Prevent unauthorized access to production systems.
• Control activity: Require unique accounts, role-based access, MFA, and approval before provisioning privileged access.
• Evidence: Access request tickets, identity provider settings, user access reviews, termination logs.
• Owner: IT or security, with engineering support for production roles.

That structure is what turns the SOC 2 common criteria from an abstract framework into something a growing company can run every month.

If you are earlier in the process, pair this article with the SOC 2 Readiness Checklist: What Startups Need Before the Audit for a broader readiness view.

Checklist by scenario

This section breaks the SOC 2 controls list into practical scenarios so you can map common criteria to real work, evidence, and ownership.

1. Governance and control environment

These controls show that security is directed, approved, and monitored rather than handled informally.

What the requirement means in practice

• Security responsibilities are assigned.
• Policies are approved and communicated.
• Leadership reviews risk and security issues on a defined cadence.
• Exceptions are documented rather than handled ad hoc.

Common evidence examples

• Information security policy and supporting policy set.
• Employee handbook acknowledgments.
• Security roles and responsibilities matrix.
• Management review meeting notes or risk committee notes.
• Document version history and approval records.

Likely owner

• Primary: Security lead, compliance lead, or CTO in smaller teams.
• Support: HR, legal, engineering leadership.

What good looks like

Policies are not just stored in a folder. They have named owners, review dates, and a process for updates when systems or workflows change.

2. Risk assessment and risk treatment

Risk-related criteria are often underdeveloped in smaller SaaS companies because teams focus on technical controls before documenting why those controls exist.

What the requirement means in practice

• You identify relevant risks to customer data, system availability, and internal operations.
• You evaluate likelihood and impact using a consistent method.
• You assign mitigation actions and track them to completion.

Common evidence examples

• Risk register.
• Documented risk assessment methodology.
• Periodic review notes.
• Tickets or project plans linked to risk treatment actions.

Likely owner

• Primary: Security or compliance.
• Support: Engineering, IT, operations, leadership.

What good looks like

The risk register reflects current architecture, vendors, and data flows. It is not a static file created at audit kickoff.

3. Access management and identity controls

Access controls are central to most SOC 2 common criteria reviews and often produce a large share of audit requests.

What the requirement means in practice

• Users have unique accounts.
• Access is based on role and business need.
• MFA is enforced for critical systems.
• New access requires approval.
• Access is removed promptly when roles change or employment ends.
• Privileged access is limited and reviewed.

Common evidence examples

• Identity provider MFA settings.
• User provisioning and deprovisioning tickets.
• Quarterly access review records.
• Admin role assignments and approvals.
• HR termination workflow records.

Likely owner

• Primary: IT or security.
• Support: HR for joiner-mover-leaver triggers, engineering for production access.

What good looks like

Your evidence shows both design and operation. A screenshot of MFA settings proves configuration. A sample of reviewed access records proves the process is being followed.

4. Change management and secure development

This area connects SOC 2 requirements explained in policy documents with engineering practice.

What the requirement means in practice

• Code changes are tracked through a formal workflow.
• Changes are reviewed before deployment.
• Production deployments are controlled.
• Emergency changes are allowed but documented and reviewed after the fact.
• Security issues found during development are triaged and remediated.

Common evidence examples

• Pull request approvals.
• Issue tracker records tied to changes.
• Deployment logs.
• Branch protection settings.
• Vulnerability remediation tickets.
• Secure SDLC documentation.

Likely owner

• Primary: Engineering leadership or DevOps.
• Support: Security, QA, product engineering.

What good looks like

Controls are embedded in tools the team already uses. Review requirements should be visible in repository settings, not just stated in a policy.

5. System operations, monitoring, and incident response

Auditors usually want to see that teams can detect unusual activity, respond in a structured way, and learn from incidents.

What the requirement means in practice

• Logging is enabled for important systems.
• Alerts are reviewed and acted on.
• Incidents are classified, investigated, and resolved.
• Post-incident actions are tracked.

Common evidence examples

• Logging and monitoring configuration screenshots.
• Alert review records.
• Incident response plan.
• Incident tickets and postmortems.
• On-call procedures.

Likely owner

• Primary: Security operations, IT, or engineering operations.
• Support: Product engineering, leadership, legal or privacy depending on incident type.

What good looks like

The incident response process is linked to real workflows, including severity definitions, notification paths, and closure criteria. For a deeper treatment, see the Incident Response Policy Checklist for Compliance-Focused SaaS Teams.

6. Vendor management and third-party risk

Most SaaS companies rely on cloud providers, support tools, analytics tools, and subprocessors. Your SOC 2 controls list should reflect that reality.

What the requirement means in practice

• Vendors are reviewed before use when they affect security, availability, or confidentiality.
• Contracts are checked for security and data handling terms as appropriate.
• Critical vendors are reassessed on a recurring basis.
• Vendor issues are tracked to resolution.

Common evidence examples

• Vendor inventory.
• Completed vendor review checklists.
• Security questionnaires or reports from vendors.
• Signed agreements and risk acceptance records.
• Periodic vendor review notes.

Likely owner

• Primary: Security, IT, procurement, or legal depending on team structure.
• Support: Business owners of each vendor.

What good looks like

The vendor inventory is complete enough to identify systems that store customer data, support authentication, or affect service delivery. The Vendor Security Questionnaire Checklist: What to Ask Cloud Providers can help standardize this process.

7. Data handling, retention, and confidentiality support

Even when your SOC 2 scope is centered on security, auditors often review how information is classified, stored, retained, and disposed of.

What the requirement means in practice

• Teams know what sensitive data they handle.
• Data is stored in approved systems.
• Retention and deletion practices are defined.
• Confidential information is protected in transit and at rest where appropriate.

Common evidence examples

• Data classification policy.
• Retention schedule or policy.
• Encryption configuration documentation.
• Backup and disposal procedures.
• Data flow diagrams or system inventories.

Likely owner

• Primary: Security, IT, or data governance.
• Support: Engineering, legal, privacy, operations.

What good looks like

Your retention rules match operational reality. If logs, support tickets, and backups are kept for different periods, the policy should reflect that clearly. The Data Retention Policy Guide is a useful companion reference.

8. People processes: onboarding, training, and offboarding

Many SOC 2 controls fail operationally because people changes are not linked closely enough to access and policy workflows.

What the requirement means in practice

• Background checks or screening, where appropriate and lawful, follow company policy.
• Employees complete security awareness training.
• New hires receive policy acknowledgments.
• Departing employees lose access promptly and return assets.

Common evidence examples

• Training completion records.
• Signed acknowledgments.
• Onboarding and offboarding checklists.
• Asset return records.
• Termination-based access removal tickets.

Likely owner

• Primary: HR and IT.
• Support: Security, managers, workplace operations.

What good looks like

HR triggers system access changes in a consistent way. If a manager can start or end employment without notifying IT, the control is weak even if the written process looks fine.

What to double-check

This section helps you pressure-test your SOC 2 common criteria coverage before you hand evidence to an auditor.

• Control language matches the real workflow. If your policy says access reviews happen quarterly, make sure they actually do and that the review method is consistent.
• Evidence covers the audit period. A strong control still fails testing if you only have evidence from one month outside the review window.
• Owners are named, not implied. “Engineering” is often too broad. Name the function or role responsible for operation and review.
• One control is not overloaded with too many objectives. It is better to split large statements into smaller controls if evidence and ownership differ.
• Manual controls have reminders and review points. If a control depends on someone remembering to run a report, define cadence and accountability.
• Tool screenshots are backed by process evidence. Configuration alone is rarely enough for recurring controls.
• Exceptions are documented. Temporary privileged access, emergency changes, or vendor approvals outside the standard workflow should leave a record.

A useful test is to pick one control at random and ask: could a new employee understand how this control works, who runs it, and where the evidence lives? If the answer is no, the control probably needs refinement.

Common mistakes

This section highlights problems that slow down SOC 2 readiness and make a controls list harder to maintain over time.

Treating the controls list as a policy index

A list of policy names is not a control framework. Auditors look for activities, not just documents. A control should describe what happens, how often, and how it is evidenced.

Assigning ownership only to the compliance team

Compliance can coordinate, but most controls operate in engineering, IT, HR, and operations. If ownership is centralized in one function, evidence collection becomes brittle and remediation stalls.

Collecting evidence too late

Teams often wait until the audit starts, then discover that access reviews, training records, or vendor assessments were never saved in a consistent format. Build evidence storage into the process itself.

Ignoring dependency controls

If your company relies on a cloud identity provider, ticketing platform, or code hosting service, make sure your controls account for how those systems are configured and monitored. External tools do not remove your responsibility to show oversight.

Writing idealized processes

The fastest way to create audit friction is to document a process that sounds mature but does not match reality. Start with current operations, tighten them, then document the improved workflow.

Forgetting adjacent obligations

Many SaaS teams prepare for SOC 2 while also handling privacy and customer assurance work. That overlap matters. Vendor records, retention schedules, and incident procedures often support both audit needs and broader data protection compliance. Related resources include the Privacy Policy Requirements Checklist for SaaS Websites and Apps, the Records of Processing Activities Guide, and the DSAR Workflow Guide.

When to revisit

This final section gives you a practical schedule for keeping your SOC 2 controls list current instead of rebuilding it every audit cycle.

Revisit your controls list any time one of these changes occurs:

• Before annual planning or budget cycles. This is a good time to confirm ownership, identify under-resourced controls, and plan tooling improvements.
• When your architecture changes. New production environments, major infrastructure migrations, or new data stores can affect risk, logging, access, and backup controls.
• When your tool stack changes. Replacing an identity provider, ticketing system, HR platform, or deployment pipeline often breaks evidence collection unless you update procedures.
• When the company adds new products or customer segments. A product expansion may change system boundaries, sensitive data exposure, or support responsibilities.
• When teams reorganize. Controls fail quietly when the owner leaves and nobody inherits the task.
• After incidents, near misses, or audit findings. These events often reveal gaps between documented controls and actual behavior.
• When customers ask new security questions. Repeated questionnaire requests can expose weak vendor oversight, incomplete asset inventories, or unclear encryption practices.

A practical maintenance routine looks like this:

1. Review the control inventory quarterly.
2. Confirm each control still has a current owner.
3. Check whether the evidence source is automated, manual, or missing.
4. Update control descriptions when workflows or tools change.
5. Retire duplicate controls that create confusion.
6. Test a small sample before the formal audit window.

If you want a simple operating principle, use this one: every SOC 2 control should be understandable, observable, and owned. If a control cannot be explained clearly, evidenced reliably, or assigned to a responsible team, it will be difficult to sustain as your program matures.

Used this way, a SOC 2 controls list becomes more than an audit artifact. It becomes a live operating reference for security, engineering, IT, and compliance teams working from the same expectations.