An access review can be scheduled, a logging platform can be running and a vendor questionnaire can be filed. The gap appears when nobody is responsible for checking whether all relevant accounts, systems and suppliers were actually covered.
That is why a SOC 2 control list needs more than control names. In an organization without a CISO, engineering, IT, people operations, procurement and leadership may all run parts of the programme. Each control needs an operational owner, a clear escalation path and evidence that matches the period and scope of the SOC 2 examination.
This guide offers a practical ownership model for 2026. It keeps the focus on the Trust Services Criteria, representative control domains, a usable SOC 2 RACI, and the work needed to close gaps before they become audit findings.
What belongs on a SOC 2 control list?
SOC 2 is an attestation report on controls at a service organization relevant to one or more of five Trust Services Criteria categories: Security, Availability, Processing Integrity, Confidentiality and Privacy. Security provides the common criteria; the other categories are selected based on the service, commitments and report scope.
There is no universal AICPA checklist of prescribed tools, owners and evidence files for every company. Management describes the system and designs controls to meet the applicable criteria. The independent CPA firm examines that description and the controls within the agreed scope. A template can help organize work, but it must reflect what the company actually operates.
For each control, record:
- The objective and the system or population in scope
- Who performs the control and who is answerable for the outcome
- How often the control runs or is reviewed
- Where authoritative evidence is generated and retained
- How a failed check is escalated, remediated and verified
For a Type 2 report, the operating trail matters across the examination period. A control that looks correct on the last day may still have gaps earlier in the period. Agree on the report scope and evidence expectations with the CPA firm rather than assuming one generic frequency applies to every control.
Who owns SOC 2 controls without a CISO?
Management remains responsible for its system and control environment even when no executive has a CISO title. A founder, COO or technology leader may sponsor the programme. Day-to-day control ownership should sit with people who can direct the underlying process and resolve a failure.
The programme coordinator can track deadlines and auditor requests, but should not silently own every technical, HR and supplier control. Separate control operation from programme coordination.
The following is an illustrative SOC 2 control list, not a list required by AICPA. Adjust it for your services, selected criteria and team structure.
| Control area | Likely operational owner | Partners | Evidence and useful outcome check |
|---|---|---|---|
| Identity and access | IT or identity lead | HR, system owners | Joiner and leaver records, access reviews; check that all in-scope accounts were included |
| Production changes | Engineering or platform lead | Product, security | Pull requests, approvals, deployment records; reconcile changes with production releases |
| Cloud configuration and monitoring | Platform lead | Service owners, incident responders | Baselines, alert records, log-feed health; check critical assets and response ownership |
| Incident response | Incident lead or operations leader | Legal, support, leadership | Escalation record, exercise or incident timeline, follow-up actions; verify closure |
| Supplier oversight | Procurement or vendor owner | Legal, engineering, data owners | Due diligence, contracts and review dates; check critical providers and open findings |
| Workforce security | People operations | IT, managers | Training, onboarding and departure records; reconcile departures with access removal |
| Data protection and recovery | Service or data owner | Platform, privacy team | Encryption settings, backup and restore results; check sensitive data and critical services |
The specific owner may differ. For example, engineering could own application access while IT owns the central identity platform. Avoid treating the department names in a sample table as an audit requirement.
Make ownership specific enough to act
“IT owns access” is useful at a planning level. It is insufficient when a quarterly review is due and nobody knows who will generate the account list, who will approve each exception or who will revoke access.
For each recurring control, identify a named coordinator or role with an assigned incumbent, the reviewers who make decisions and the person authorized to resolve exceptions. Define a backup when the primary person is unavailable. Record the evidence source before the first review, not during the auditor’s sample request.
Consider a departure process. People operations records the departure date, IT disables central accounts, application owners remove local access and a manager checks that the work is complete. The programme owner tracks missed steps. A strong control record ties those events to the same person and date range, and flags any application that was omitted.
Review assignments after a new SaaS deployment, reorganization or acquisition. An old control map may no longer match the systems and reporting lines in use.
Use a SOC 2 RACI as a working map
A RACI can distinguish who is Responsible for performing a task, Accountable for its outcome, Consulted for expertise and Informed about its status. It is a management tool, not a SOC 2 requirement by name. Use it where multiple teams touch the same control.
For example, for employee offboarding:
| Activity | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| Record departure and trigger workflow | People operations | People operations lead | Employee’s manager | IT |
| Remove central and application access | IT and application owners | IT lead | People operations | Manager |
| Investigate missed access and confirm closure | Relevant system owner | IT lead | Risk or compliance coordinator | Executive sponsor |
The exact assignments depend on authority in your organization. The point is to avoid a control falling between two teams because each believes the other will complete it. An auditor assesses the control against the applicable criteria and the organization’s description; a perfect-looking RACI does not replace evidence of execution.
What evidence proves a control operated?
Start from the system that performs the activity. An access review needs the source population, reviewer, review date, decisions and evidence of action on exceptions. A change control needs the proposed change, approval, release record and any required post-deployment check. An incident control needs an escalation and response trail, not merely an approved response plan.
The evidence should answer four questions: What was in scope? When did the activity occur? Who made the decision? What happened to any exception?
Screenshots without timestamps or asset context make those answers difficult. A dashboard showing that a tool was installed does not necessarily prove that every relevant asset was protected.
For a SOC 2 Type 2 examination, establish a cadence that can operate throughout the reporting period. Track missed reviews and failed checks when they occur. Corrective action should show an owner, a due date, the fix and a recheck. Do not quietly replace missing historical evidence with a new screenshot at the end of the period.
A practical example: privileged access across a growing service
Suppose a SaaS company has moved several production workloads to a new cloud account. Its SOC 2 control list says privileged access is reviewed, and the IT lead has signed the latest review. Yet the cloud administrator roles created during the migration are absent from the identity export used for that review.
The review happened, but its population was incomplete. The service owner identifies the new roles, the identity owner compares them with approved access, and the platform team closes any excessive permissions. The team then updates the review source and documents a check that the next review includes all production accounts.
This example illustrates why SOC 2 control ownership should connect the control, the systems it covers and the people who can fix a gap. The decision is more useful than a simple “review complete” status because it identifies what was missed and how the outcome was validated.
How to assign SOC 2 ownership in five steps
- Confirm report scope. List the service, systems, locations, subservice relationships and Trust Services Criteria categories with the CPA firm. Do not use a generic control library as a substitute for the agreed boundary.
- Inventory current controls. Identify the activities already performed across engineering, IT, people operations, legal and suppliers. Keep the list specific enough to test.
- Name the operators and decision makers. Assign who executes, reviews and escalates each control. Use a RACI for handoffs that regularly cross teams.
- Map evidence and failure response. Record the source, frequency, expected population, owner of exceptions and the way remediation will be rechecked.
- Walk through a sample. Take a real access review, change or vendor review and trace it from source data to decision and closure. Fix unclear ownership before the examination period accumulates more gaps.
This sequence works for a small founder-led team and for a larger enterprise with dedicated functions. The assignment changes with scale; the need for an accurate account of what happened does not.
What changed in the 2026 conversation about SOC 2 tools?
The AICPA continues to identify the 2017 Trust Services Criteria with revised points of focus in 2022 as the criteria resource. There is no reason to relabel those criteria “SOC 2 2026 controls.” AICPA’s 2026 SOC resources also emphasize the credibility of examinations and scrutiny of tool-provider arrangements. That reinforces a practical point: automation can organize evidence and surface gaps, but it cannot issue an auditor’s conclusion or make a weak control effective.
When evaluating software, check whether it preserves source context, timestamps and ownership. Ask how it handles missing data and exceptions. A promise that a platform will make an organization “SOC 2 compliant” without examining control operation and the CPA firm’s work is too broad.
How SPOG.AI supports control ownership and evidence
SPOG.AI connects evidence from identity, endpoint, cloud, vulnerability, ITSM and other systems to assets, controls, risks and owners. This helps teams see whether a selected control covers the intended population, where it has failed and who is responsible for remediation. Its governance and continuous control monitoring capabilities support exception tracking, accountable workflows and revalidation after a fix.
For a SOC 2 programme, that connected view can reduce the manual chase between a policy, a ticket and a system status report. The organization still defines its controls and report scope, and the independent CPA firm performs the examination. SPOG.AI helps the team manage the operating evidence behind those decisions.
See how SPOG.AI connects control owners, evidence and remediation.