SOC 2 control list: Who owns what when you don’t have a CISO

Audit week exposes the real problem.

It starts the same way every time. Audit week arrives, Slack threads start piling up, and someone asks for evidence of the access review. Then comes the pause—a quick check with the engineering lead. A forward to the platform team. Nobody is sure who owns it.

This is not a control problem. You already have a SOC 2 control list. You have policies, tools, and a general sense of what needs to happen. 

According to A-LIGN's 2024 Compliance Benchmark Report, in more than half of organizations, the IT department is responsible for compliance, while only 20% have a dedicated compliance department. 

For most engineering and platform teams, that means SOC 2 ownership lands on people who are already carrying a full workload and have no CISO to escalate to.

So the real question is not whether your controls exist. It is who owns each one, who pulls the evidence, and who is accountable when something slips.

This guide gives you a SOC 2 control list mapped to real owners, what auditors actually expect as evidence, what breaks when SOC 2 ownership is unclear, and a working RACI you can apply immediately, even without a CISO.

Summary overview

• SOC 2 control ownership does not disappear without a CISO. It is distributed across engineering, IT, HR, legal, and finance.
• If a control lacks a named owner, it does not exist in practice.
• Auditors test for proof of execution over time, not just the existence of a control.

What is a SOC 2 control list (and why it’s not enough)

A SOC 2 control list is a structured inventory of the security and operational controls your organization maintains to meet the requirements of the AICPA's Trust Services Criteria (TSC). According to the AICPA, a SOC 2 examination is a report on controls at a service organization relevant to security, availability, processing integrity, confidentiality, or privacy. AICPA & CIMA.

Security is the only mandatory category for every SOC 2 audit. The remaining four TSCs are selected based on your service commitments and the nature of the data you handle.

A typical SOC 2 control list covers seven core domains:

• Access control
• Logging and monitoring
• Change management
• Incident response
• Vendor management
• HR and personnel security
• Data protection

These map across the TSC and form the backbone of what most auditors will test during an examination.

Here is the part worth paying close attention to, though. Most SOC 2 control lists stop at the inventory stage. They document what exists. They rarely answer:

• Who runs each control
• Who collects the evidence
• Who is accountable when something breaks

For engineering teams and platform leads operating without a CISO, that gap is where SOC 2 ownership quietly becomes a problem. Because without a named owner, controls get assumed rather than assigned, and assumptions don't hold up under audit scrutiny.

The sections that follow map each of these domains to real owners, evidence requirements, and the failure risks that surface when accountability is left unassigned.

Who owns SOC 2 when you don't have a CISO

Without a CISO, SOC 2 ownership does not disappear. It gets distributed. The question is whether that distribution is intentional or accidental.

In most engineering-led organizations operating without a dedicated security leader, ownership naturally follows the systems and processes each team already controls. That is actually the right instinct, as long as it is made explicit.

Here is where ownership tends to land, and where it should:

• Engineering: Application security, code review processes, and deployment controls.
• DevOps and platform: Infrastructure configuration, logging pipelines, and monitoring systems.
• IT: Identity management, access provisioning, and endpoint security.
• HR: Employee onboarding, offboarding workflows, and security awareness training.
• Legal and procurement: Vendor risk assessments and third-party contract reviews.
• Finance and leadership: Risk oversight, risk acceptance decisions, and executive accountability for the overall compliance posture.

The principle worth anchoring to here is straightforward. SOC 2 ownership should sit where the system or process actually lives, not with whoever happens to be coordinating the audit. Assigning ownership to a compliance coordinator or a single engineering lead as a catch-all creates the exact accountability gap that surfaces during audit week.

Your SOC 2 control list, mapped to real owners

The controls below are representative examples from each domain, not an exhaustive list. A complete SOC 2 control list varies depending on which Trust Services Criteria your audit covers, the nature of your product, and the scope agreed with your auditor. These tables show you what ownership looks like in practice. The downloadable RACI template at the end of this guide provides the blank version to fill in for your organization.

How to read this: Primary owner is the accountable party. The supporting team contributes to execution. Evidence is what auditors will ask to see. Failure risk occurs when ownership is unclear or assumed.

1. Access control

Controls in this domain govern who can access your systems, how that access is granted, and how it is revoked when it should no longer exist.

2. Logging and monitoring

Controls in this domain ensure that system activity is captured, retained, and reviewed, enabling anomalies and incidents to be detected and investigated.

3. Change management

Controls in this domain ensure that changes to code, infrastructure, and configuration are reviewed, approved, and traceable before they reach production.

4. Incident response

Controls in this domain cover how your organization detects, escalates, responds to, and learns from security incidents and service disruptions.

5. Vendor management

Controls in this domain address how third-party vendors are evaluated, onboarded, and monitored to ensure they do not introduce unacceptable risk to your environment or customer data.

6. HR and onboarding

Controls in this domain ensure that employees are vetted before joining, trained on security expectations, and properly offboarded upon leaving.

7. Data protection

Controls in this domain govern how sensitive data is classified, handled, stored, and transmitted to prevent unauthorized access or exposure.

One principle ties all of the above together: if multiple teams think they own control, no one owns it.

Assigning ownership is only half the equation. Controls also need to produce consistent, audit-ready evidence, and that's a discipline of its own. See how to get evidence documentation right.

SOC 2 control ownership is a RACI problem

Knowing which team owns a domain is the starting point. Making that ownership auditable requires a more precise model. That model is the RACI model: Responsible, Accountable, Consulted, and Informed.

• Responsible: The person who executes the control, runs the access review, pulls the log, or documents the change.
• Accountable: The person who owns the outcome. If something breaks or evidence is missing, this is who answers for it.
• Consulted: The people whose input shapes how a control is designed or maintained.
• Informed: The people who need to know that a control exists and whether it is working.

Two principles make this non-negotiable in a SOC 2 context. 

1. If a control lacks a named, accountable owner, it does not exist in practice. Auditors will not accept shared or unnamed ownership as evidence of an operating control.
   
2. Accountability cannot be shared. Distributing it across two or three people is the same as assigning it to no one.

Edward Contreras, Senior EVP and CISO at Frost Bank, takes a step further on the CISO Series podcast: "And so I think when it comes to being a CISO, there is an accountable party, which should be one, but there should be everybody who's responsible for executing that program, which should be all."

With that model in place, here is how ownership maps across each of the seven core domains.

What breaks when SOC 2 ownership is unclear

Most SOC 2 failures during an audit are not technical failures. They are coordination failures. When accountability is ambiguous, a predictable set of problems surfaces, often all at once and during audit week.

Here is what that looks like in practice:

• Evidence is scattered across systems, inboxes, and shared drives with no single source of truth.
• Access reviews are skipped or delayed because no one is sure who is responsible for running them.
• Alerts are generated but never reviewed, because the team that receives them assumes another team is acting on them.
• Audit preparation becomes a last-minute chase across Slack threads and email chains, pulling engineers away from their actual work.
• Duplicate effort arises when multiple teams independently gather the same evidence without knowing the others are doing the same.
• Deals slow down when prospects or enterprise customers request proof of compliance, and the documentation is incomplete or inconsistent.

Wendy Nather captured this reality plainly: "If the basics were easy, they would be done by now. The basics are not easy for small companies." SOC 2 ownership is one of those basics that looks simple on paper and falls apart in execution.

Each of these is a symptom of the same underlying problem. When SOC 2 ownership is assumed rather than assigned, the cost manifests as lost engineering hours, audit findings, and delayed revenue.

According to PwC's 2025 Global Digital Trust Insights survey, only 2% of executives are confident in their organizations' cyber resilience. Unclear ownership is a significant reason that the number stays so low.

The biggest SOC 2 risk for most engineering-led organizations is not a security vulnerability. There is ambiguity about who is responsible for what.

How to assign SOC 2 ownership without a CISO

Assigning SOC 2 ownership without a dedicated security leader is less about expertise and more about structure. The process is straightforward if you follow it in order.

1. Start with your SOC 2 control list

Your control list is the foundation. If you do not have one, the seven domains covered in this guide are your starting point. Work from what exists before adding new controls.

2. Group controls by domain

Each domain has a natural home in your organization. Use that as the basis for ownership assignment rather than starting from scratch.

3. Assign a DRI per control

A Directly Responsible Individual (DRI), not a team, not a role. A named person who is accountable for that control operating, and for evidence being available when asked for it.

4. Define what good evidence looks like

Do this before the audit begins. An access review is not complete because it happened. It is complete when it has a reviewer's name, a date, and a documented outcome.

5. Run a mock audit

Walk through each control and ask for evidence as an auditor would. This is the fastest way to surface ownership gaps before they become audit findings.

Two rules apply throughout: one control means one owner, and ownership lives with a person, not a team.

How to build your SOC 2 RACI

A working RACI does not require a security consultant or a dedicated compliance tool to get started. But it does need to reflect the reality of your organization. The same SOC 2 requirements apply whether you have 20 employees or 2,000, but who owns what, and how that ownership is documented, looks meaningfully different at each stage.

C1: Startup or small team (1–50 employees)

At this stage, dedicated functions rarely exist in isolation. One person might own engineering, infrastructure, and incident response simultaneously. The instinct is often to list a team or a role as the owner. That instinct is the problem.

A RACI at this size is essentially a named list. Every control gets one person attached to it, not a shared assumption between two founders. In practice, a founding engineer or CTO typically covers access control, logging, change management, and data protection. The CEO or COO owns vendor decisions, risk acceptance, and offboarding oversight.

The goal is not to manufacture roles you do not have. It is to make sure nothing is owned by everyone and therefore by no one.

C2: Mid-market (51–500 employees)

This is where ownership gaps become most dangerous. Distinct functions now exist across engineering, IT, HR, and operations, which creates the illusion that ownership is handled. In reality, each team assumes another team is accountable for the controls that sit at the boundary between them.

Vendor security reviews fall between legal and engineering. Offboarding access revocation falls between HR and IT. Incident escalation falls between DevOps and the engineering lead. These are the controls that produce audit findings, not because no one is capable of owning them, but because no one was ever explicitly assigned.

At this stage, a compliance lead, security engineer, or VP of Engineering typically serves as the de facto accountable party for the overall SOC 2 posture, even without a CISO title. The RACI's job is to make that implicit accountability explicit, and to push execution ownership down to named individuals in each domain rather than leaving it at the team level.

C3: Enterprise (500+ employees)

Dedicated security, compliance, legal, and IT functions exist. The risk is no longer under-assignment. It is diffusion: too many stakeholders across control, no single person answerable for the outcome, and ownership assignments that made sense at 200 employees but were never revisited at 600.

At this size, a CISO or Head of Security holds the accountable role for the overall compliance posture. Domain-level DRIs sit in engineering, IT, HR, legal, and finance. Cross-functional controls like vendor management and incident response need a single named coordinator, not a working group that owns it collectively.

RACI reviews should happen on a defined cadence, at a minimum annually, and immediately after significant organizational changes. Headcount growth, acquisitions, and leadership transitions all shift who actually controls a system or process. The RACI needs to reflect that.

Building it, regardless of size

The mechanics are the same at every stage. Set a one-hour limit and work through it in order:

1. List two to three controls under each of the seven core domains.
2. Assign a primary owner to each control before anything else. Ownership first, supporting roles second.
3. Map the evidence source for each control: where does proof of execution live, and who can pull it on short notice?

Two rules apply throughout: one control means one owner, and ownership lives with a person, not a team.

The downloadable RACI template below covers all seven domains with fields for owner, supporting roles, evidence source, and review frequency. It is structured to work whether you are filling it in as a founding team of three or distributing it across department leads.

One template does not fit all.

Get the right RACI for your stage, whether you are starting now or scaling

Conclusion: Turn controls into execution

A SOC 2 control list is the starting point, not the finish line. Every control on that list needs someone to run it, someone to own it, and a trail of evidence that proves it operated consistently across the audit period. Without that, the list is just documentation.

When SOC 2 ownership is clear, the entire compliance posture shifts. Audits become predictable because evidence is collected continuously, not assembled in a panic. Engineering teams stay focused on building because compliance work is distributed to the people who actually own each system and process. 

Once ownership is clearly assigned, the next challenge is operationalizing it consistently. Controls need to produce evidence on time, ownership needs to stay visible across teams, and audit readiness needs to hold even when systems and people change. This is the point where tooling starts to matter, not just for documenting controls, but for making ownership and evidence collection continuous in practice.

This is where Scrut Automation helps you operationalize SOC 2 in a practical way. Scrut comes with 1400+ pre-mapped controls aligned to Trust Services Criteria, so you are not starting from scratch. It connects to your existing stack through 100+ integrations, including AWS, GitHub, Okta, and Jira, to automatically collect evidence where it is generated.

Instead of chasing screenshots, you get continuous control monitoring with automated checks that run every 24 hours, so gaps are identified early, not during audit week. Ownership is clearly visible across teams, evidence is always audit-ready, and your entire compliance posture becomes a living system rather than a periodic exercise.

A SOC 2 control list tells you what needs to be in place. Ownership ensures it runs. Scrut makes sure it runs consistently, visibly, and without disruption.

Explore how Scrut Automation helps you assign ownership, automate evidence, and stay audit-ready without the chaos.

‍