Running the engagement
Who owns each SOC 2 control.
SOC 2 is often handed to one person, usually in security or compliance. But the controls themselves run in engineering, IT, HR, legal, finance and leadership. A control with no clear owner is the one that quietly stops. This page maps the usual owners and the evidence each one holds.
Back to SOC 2 services01 · Role map
Which team runs which kind of control
Most controls live outside the security team.
- Engineering
- Code review, deployment, change approval, infrastructure configuration, backups, vulnerability fixes.
- IT
- Identity provider, device management, joiner and leaver access, endpoint protection.
- HR
- Background checks, onboarding acknowledgements, security training records, termination notices to IT.
- Security
- Risk assessment, monitoring and alerting, incident response, vulnerability scanning, access review coordination.
- Legal
- Customer commitments in contracts, vendor agreements, data processing terms, confidentiality obligations.
- Finance
- Vendor onboarding and payment, insurance, budget for security work.
- Leadership
- Oversight, policy approval, setting the tone at the top, reviewing risk and audit results.
02 · Two kinds of owner
Control owner versus evidence owner
The person who does the control is not always the one who keeps the proof.
Control owner
Answers for the control
- Makes sure it runs on schedule
- Explains it to the auditor
- Fixes it when it fails
- Approves changes to its wording
Evidence owner
Answers for the record
- Knows where the evidence lives
- Produces the full population on request
- Checks retention covers the period
- Hands over samples during fieldwork
In a small team one person often holds both. Write both names anyway, so nobody assumes the other one has it.
An illustrative case: HR owns the leaver process, but evidence that access was removed sits in the identity provider, which IT runs. If HR is asked for that evidence during fieldwork, they won't have it. Naming the evidence owner up front avoids that scramble.
03 · One name
One accountable name per control
A team can perform a control. Only a person can be accountable for it.
- Write a role in the system description and a person in your internal control register. Roles survive turnover; names get things done.
- Avoid “Engineering” or “the security team” as an owner. A group can't be reminded, and can't say why a review was missed.
- Give every owner a backup who can run the control during leave.
- Review the register whenever someone changes role, not only once a year.
04 · By criteria
Usual owners across the common criteria
An illustrative map for a mid-sized software company. Your split will differ.
| Common criteria area | Usual owner (illustrative) | Evidence they typically hold |
|---|---|---|
| CC1 Control environment | Leadership with HR | Code of conduct acknowledgements, org chart, background checks, board or leadership minutes |
| CC2 Communication and information | Security with Legal | Policies and their approvals, customer-facing security commitments, internal announcements |
| CC3 Risk assessment | Security, approved by leadership | Risk register, dated annual assessment, fraud risk consideration |
| CC4 Monitoring activities | Security or compliance lead | Internal control reviews, tracking of open deficiencies |
| CC5 Control activities | Each control owner, coordinated by compliance | Control register, policy-to-control mapping |
| CC6 Logical and physical access | IT with engineering | Access requests, removals, access reviews, MFA settings, encryption configuration |
| CC7 System operations | Security with engineering | Alerts, scan results, incident tickets, post-incident reviews |
| CC8 Change management | Engineering | Pull requests with approvals, deployment logs, emergency change records |
| CC9 Risk mitigation | Finance with security and legal | Vendor reviews, contracts, insurance, business continuity plans |
05 · Handover
When an owner leaves
The control must keep running, and the leaver's own access must go.
- Name the successor before the last day. So the next occurrence isn't missed while the role is empty.
- Write a one-page handover. What the control is, when it runs, where evidence goes, what went wrong last time.
- Move tool ownership. Saved reports, scheduled exports and admin rights tied to the leaver's account.
- Remove the leaver's access. On time and recorded. An owner who kept admin rights is a classic CC6.2 deviation.
- Update the register. And, if it was significant, note the change for the system description.
Sources: AICPA TSP section 100, 2017 Trust Services Criteria with revised points of focus (CC1 to CC9); AICPA DC section 200; AICPA guide, SOC 2 Reporting on an Examination of Controls at a Service Organization.
Questions about control ownership
Should the compliance lead own every control?
No. They should own the register, not every control.
A compliance lead who owns everything becomes a bottleneck and a single point of failure. Their job is to make sure each control has a real owner, and to notice when one is slipping.
Does the auditor care who owns a control?
Yes, because they'll ask that person about it.
During fieldwork the CPA firm interviews the people who perform controls and asks them to show evidence. A named owner who understands the control makes that conversation short.
Can a vendor own one of our controls?
A vendor can perform it. Accountability stays with you.
If a managed service runs part of a control, you still need an internal owner who monitors that it happens. Where the vendor's own controls are relied on, they may appear as complementary subservice organization controls.
How do we stop ownership drifting after the first report?
Tie the register to your people changes.
Make updating the control register part of every role change and every leaver checklist. Then review the whole register when you plan each new period.
Put a name on every control.
We build a control register with an owner, evidence owner and backup for each control your report relies on.