Learn · SOC 2 Readiness
Who Actually Runs
Each SOC 2 Control
Every control in your system description is performed by a person. In readiness work the exceptions that surface most often are not missing controls but controls nobody was accountable for — or, which amounts to the same thing, controls owned by 'the security team'. A control with no owner produces no evidence, and a control with no evidence did not operate.
Accountability is not the same as effort. One named individual answers for each control’s operation and its evidence. Others may do most of the work. What the owner cannot hand over is the answer to the first question in every walkthrough: who is responsible for this, and how do you know it happened?
Plain-English explainer · TSC 2017 (rev. 2022) · AT-C 205 examination · Last reviewed August 2026
Every control described in a SOC 2 system description should have exactly one named individual accountable for operating it and for producing the evidence that it operated — not a team, not a tool, but a person who can be put in a walkthrough and asked to describe what they do. Not because a Trust Services criterion says “assign a control owner”; none does. Because of how the examination works. The CPA firm tests each control in Section 4 by establishing who performs it, corroborating that against what they produce, and sampling from a population somebody must generate on request. Every step needs a name. Where none exists, months in which nobody was accountable look exactly like months in which nothing happened.
The standard, precisely
No criterion says “control owner”
Worth being exact, because ownership matrices are sold as though the AICPA mandated them. The Trust Services Criteria (2017, points of focus revised 2022) never use the term. They require the substance of it in four places.
CC1.3
COSO Principle 3. Management establishes structures, reporting lines and appropriate authorities and responsibilities; its points of focus look at how those authorities are defined, assigned and limited. Management must decide and assign who holds which authority and responsibility.
CC1.5
COSO Principle 5. The entity holds individuals accountable for their internal control responsibilities — individuals, not functions, with mechanisms to enforce accountability and take corrective action.
CC5.3
COSO Principle 12. The closest the criteria come to naming ownership. Its points of focus place accountability with management or designated personnel of the function “in which the relevant risks reside”, and separately look for competent personnel with sufficient authority acting in a timely manner. Points of focus are not themselves requirements — TSP section 100 states that use of the criteria does not require an assessment of whether each point of focus is addressed.
CC2.2
COSO Principle 14. Responsibilities for internal control must be communicated internally — so a short matrix that was circulated and acknowledged beats a thorough one nobody read.
Alongside these sit the description criteria for SOC 2 — DC section 200, which apply to SOC 2 and not to SOC 1 — requiring the description to cover the system’s components, of which people are one. It asks for functions and responsibilities rather than individual names, which is why Section 3 says “the Head of IT approves privileged access requests” and the individual’s name lives elsewhere. Market practice, not requirement: one named owner per row of the matrix. No standard prescribes it. It survives because every test procedure in an examination under AT-C sections 105 and 205 resolves to a person who did something.
Why “the security team” is not an owner
The walkthrough breaks first. Inquiry alone is not sufficient appropriate evidence under the attestation standards, so the conversation is with a person who then has to show something. When the matrix says “Security”, the readiness lead narrates a control they do not perform, and the auditor notices within two questions.
Accountability diffuses second. The point of focus under CC5.3 is specific: accountability sits with personnel of the function in which the risk resides. The risk of an unreviewed deployment resides in engineering; the risk of a leaver keeping access resides jointly in what HR triggers and what IT executes.
Evidence fails last, and most expensively. Populations come out of systems that functions administer — leavers from HR, changes from engineering, vendors from procurement. An owner who does not administer the system cannot attest that an export is complete, and completeness is tested before sampling begins.
Record the role and the person holding it, with an effective date, keeping prior holders rather than overwriting them. The role survives turnover; the name makes the control testable; the dates establish who was accountable in March.
The map
A realistic ownership map
What holds up most often in software companies of fifty to three hundred people — a starting position for an argument inside your own organisation, not a rule. Two columns carry more weight than they look: frequency determines how many occurrences the auditor expects and therefore the sample size, and the system of record determines who is in a position to say an export is complete.
| Control family | Frequency | Accountable owner | System of record for the population | Evidence the owner must produce |
|---|---|---|---|---|
| Access provisioningCC6.1 · CC6.2 | Event-driven | Head of IT, with a named system owner per in-scope system | Identity provider, plus each in-scope system’s own console | Requests naming requester, approver and role granted; the approval captured by the system rather than asserted afterwards |
| User access reviewCC6.1 · CC6.2 · CC6.3 | Quarterly | The named system owner performs; Head of IT is accountable for the cycle | Entitlement export per in-scope system, generated from the identity provider | Dated entitlement export naming the reviewer; each line struck off closed by a revocation ticket that references the review |
| Onboarding & screeningCC1.4 | Event-driven | HR, with the hiring manager confirming role and access need | HRIS, plus the background-check provider’s record | Screening record per joiner where policy requires it; role assignment at hire reconcilable to the provisioning request |
| Offboarding & access removalCC6.2 · CC6.3 | Event-driven | HR or procurement owns the leaver trigger; Head of IT owns the access actions | HRIS plus the contractor and purchase-order register | Leaver register reconcilable to an independent source; deprovisioning tickets timed against the policy SLA |
| Change managementCC8.1 | Event-driven | Head of Engineering, or whoever owns the deployment pipeline | Version control and the deployment pipeline | Change records showing author and approver differ, test evidence, deployment record, and the branch-protection settings enforcing it |
| Vulnerability & patch managementCC7.1 · CC8.1 | Weekly scan, monthly review | Head of Infrastructure or the platform engineering lead | Scanner output plus the ticketing system holding the findings ledger | Scan schedule and outputs; a findings ledger with severity, SLA clock and owner; retests; dated acceptances for open items |
| Incident responseCC7.2 · CC7.3 · CC7.4 | Event-driven | The security lead — CISO, Head of Security or the named equivalent | Alerting platform plus the incident register | Incident register reconcilable to the alerting source; detection, containment and closure timestamps; post-incident reviews with named actions |
| Vendor & third-party managementCC9.2 | Annual per in-scope vendor | A named risk owner in security or GRC — not procurement, not the budget holder | Vendor inventory, reconciled to accounts payable at a stated date | Vendor inventory with tiering rationale; a dated review per in-scope vendor naming the reviewer; exception approvals where no assurance exists |
| Business continuity & DRCC9.1 · A1.2 · A1.3 (where Availability is in scope) | Annual | Head of Infrastructure for technical recovery; an executive sponsor for the plan | The DR test record and the plan repository | Dated test plan and results naming participants; defects raised as tickets; the plan version approved after the test |
| Policy governance & reviewCC5.3 · CC2.2 | Annual | The GRC or compliance owner for the cycle; a subject-matter owner per policy | Policy repository version history plus the acknowledgement log | Version history showing approval date and approver identity; acknowledgements reconciled to the roster at a stated date |
| Risk assessmentCC3.1 · CC3.2 · CC3.4 | Annual, plus on significant change | An executive — CEO, COO or CTO. Security facilitates; it does not decide | The risk register and its version history | Dated register versions; the record of who decided; treatments with owners and target dates; evidence of revisiting after change |
| Security awarenessCC1.4 · CC2.2 | Annual, plus at hire | HR where training runs on the HR platform; security where it does not | The LMS or HR platform, reconciled to the headcount roster | Completion report reconciled to the headcount roster at a stated date, plus documented follow-up for non-completers |
Two placements are argued about. Risk assessment belongs to an executive, because CC3 concerns the entity specifying objectives and analysing risks to them. Vendor management belongs to security or GRC, because CC9.2 is about assessing and managing risk, not running a renewal calendar.
One scope caveat on the continuity row. The A-series criteria exist only where Availability is included in the engagement; a Security-only report — which is what most first Type 2s are — carries CC9.1 and no A1.x at all. Assigning an owner to a criterion that is not in your scope is harmless; assuming the A-series will carry your DR test when Availability was never selected is not.
The artefact
What the matrix actually contains
The roles-and-responsibilities matrix is the artefact every readiness conversation orbits and almost nobody specifies. It is a spreadsheet. Ten columns make it useful to a service auditor; fewer than that and it becomes a document you maintain rather than one that answers questions.
| Field | Why the auditor needs it | Example value |
|---|---|---|
| Control ID | Ties the control described in Section 3 to the test performed in Section 4. | AC-04 |
| Criterion mapped | Lets the auditor trace coverage, and surfaces any applicable criterion nothing addresses. | CC6.2, CC6.3 |
| Control description | The wording that gets tested. Where the matrix and the description disagree, the description governs. | Access for terminated personnel is revoked within one business day. |
| Accountable role | Survives turnover. The role is what the next holder inherits, unchanged. | Head of IT |
| Named individual | Who sits in the walkthrough and describes the control without prompting. | A. Rao |
| Effective from / to | Establishes who was accountable in March. Without dates a mid-period handover is invisible. | 01-Oct-2026 – 14-Mar-2027 |
| Performer, where delegated | Distinguishes an authorised delegation from an unauthorised performer — in evidence the two look identical. | IT service desk |
| Frequency | Drives the sample size, and states how many occurrences should exist across the period. | Event-driven |
| Evidence artefact | Names what the control produces, so the request can be written against a real object. | Deprovisioning ticket with close timestamp |
| System of record for the population | Identifies who can attest that an export is complete — tested before any sample is drawn. | Identity provider plus contractor register |
Two properties matter more than the columns. The matrix must be approved and circulated before the period opens — CC2.2 addresses the internal communication of internal control responsibilities, and a matrix nobody was sent communicated nothing. And prior holders are retained as rows rather than overwritten: the row for A. Rao ends on 14 March 2027 and a new row for the incoming owner begins on 15 March, so the file can still answer who was accountable in the first week of March two years later. A matrix maintained as a current-state document cannot answer a question about a period, which is the only kind of question a Type 2 asks.
Before the period opens
Five steps to a matrix that is already true on day one
Ownership is one of the few things in a SOC 2 that genuinely cannot be repaired late, because it is tested through every other control rather than as a control of its own. The sequence below takes a week or two and is worth starting before the observation period is fixed.
1
List every control in the draft description and the system each depends on
Work from the system description, not from a platform’s control library. A control absent from the description is not tested; a system that supports a described control but appears in no inventory is the one that ends up unowned.
2
Map each control to the function in which the risk resides
The point of focus under CC5.3 is the argument to use when two teams both decline the row. Deployment risk resides in engineering; a leaver keeping access resides jointly in what HR triggers and what IT executes.
3
Confirm the assignment in writing with each named owner
An unconfirmed assignment is not an assignment. One line back from the named person — that they hold this control, at this frequency, producing this artefact — is enough, and it is the line that stops the row being disowned in fieldwork.
4
Capture the acknowledgement
This is the part CC2.2 addresses: internal communication of internal control responsibilities. The acknowledgement, rather than the matrix itself, is what shows the responsibility was communicated and received.
5
Baseline the matrix with an effective date on or before day one
Version it thereafter. A matrix first approved in month nine of a twelve-month period tells the auditor that nobody was formally accountable for the first eight.
Accountable versus performing
What an owner keeps
A Head of IT accountable for provisioning across nine systems does not click nine consoles. The line that matters is between what can be handed over and what cannot leave the owner without changing the control.
Cannot be delegated
- The approval decision, where the control is an approval. Delegating does not distribute it — it moves it, and the description must name where.
- The exception call: what happens when the control cannot be performed on time, at what authority, with what compensating action.
- Completeness of the population — saying the export covers everything, and naming the source it reconciles against.
- Escalation when the control fails repeatedly. With nobody accountable for noticing a pattern, it runs to period end.
Can be delegated
- Execution — running the scan, closing the ticket, deactivating the account, scheduling the test.
- Evidence collection and filing, including automated collection through a compliance platform.
- Drafting: the policy text, the review template, the questionnaire, the runbook.
- Scheduling and chasing — the reminder that a review is due, the follow-up to non-completers.
An unrecorded delegation looks identical, in evidence, to a control performed by an unauthorised person. If access reviews are delegated to a service desk lead, the matrix should say so and the owner should still sign off the output.
The seams
The controls that fall between teams
In the engagements we support, first-period exceptions cluster in three places, and none of the three is caused by a missing control. Each is caused by two teams reasonably believing the other one had it.
Offboarding, between HR and IT
HR owns knowing somebody left; IT owns removing what they had. The control described in Section 3 is usually the second half, so the trigger ends up owned by nobody. It works for employees, because payroll forces the conversation, and fails for contractors, whose engagements end by a purchase order expiring. Split it: HR — or procurement, for non-employees — owns the leaver record existing within one business day; IT owns the access actions that follow.
Vendor reviews, between procurement and security
Procurement holds the contract dates; security holds the ability to judge whether a vendor’s assurance is adequate. Neither half is a review. Procurement renews on time and files whatever the vendor sent, and the “annual review” produces a year of unopened PDFs. Give security the judgement, procurement the calendar, and make the artefact a short written assessment naming the reviewer.
Access reviews for systems nobody owns
The analytics tool bought by a team that has since reorganised; the legacy console kept alive for one report. They stay in scope because they hold customer data or reach production, and the review stops because the person who ran it is no longer on the org chart. The fix is a rule: ownership follows the business function that depends on the system, and any in-scope system without a named owner is assigned one before the period opens or decommissioned. See scope and system boundary.
RACI for the disputed controls
Exactly one Accountable per row — the moment there are two, the control is back where it started.
| Disputed control | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| Leaver access removal within SLA | IT service desk | Head of IT | HR operations (the trigger), the leaver’s manager | Security lead, via the monthly metric |
| Contractor & non-employee offboarding | Engaging manager raises the record; IT executes | Head of IT | Procurement (engagement end dates) | Security lead, HR |
| Annual review of an in-scope vendor | Security analyst performing the review | Security or GRC lead | Budget holder (criticality), legal (terms) | Procurement, finance at renewal |
| New-vendor assessment before signature | Requesting team completes intake; security assesses | Security or GRC lead | Legal, data protection, the integrating system owner | Finance, procurement |
| Quarterly access review, system nobody claims | The IT administrator holding the console | The executive owning the function that depends on it | Security, the heaviest-using team | Everyone holding an account in it |
Worked example
One leaver, twenty-four days
An illustrative composite — not a client. A software company of about a hundred and twenty people runs its first Type 2.
1 Oct 2026
Period opens
A twelve-month Type 2 running 1 October 2026 to 30 September 2027. Deprovisioning sits with the Head of IT, against a one-business-day SLA written into the access policy.
15 Jan 2027
A contractor finishes
A back-end contractor engaged on a purchase order has his last day. No HR record — contractors sit with procurement — so no leaver ticket is raised.
8 Feb 2027
Access removed, late
A licence-cost review flags an unused seat. IT deactivates the account and revokes the repository token. Elapsed against a one-day SLA: twenty-four days.
Oct 2027
The completeness test
HR produces thirty-one employee leavers. Reconciled against the identity provider’s deactivated accounts and the contractor register, nine non-employee departures appear. Tested population: forty.
Oct 2027
The deviation
Fifteen items selected across the period; fourteen inside SLA, one at twenty-four days. Described in Section 4 with the population, items tested and the exception.
Nov 2027
Root cause
The control had an owner. The trigger did not. Remediation names the service desk lead as owner of one register covering employees and contractors, with procurement obliged to file an end-of-engagement notice.
Section 4, as written
Inspected the deprovisioning record for 15 of 40 personnel departures occurring during the period and compared the access revocation timestamp to the termination date. For 14 of 15 selections access was revoked within one business day. For 1 selection, a non-employee whose engagement ended 15-Jan-2027, access was revoked 08-Feb-2027, 24 days after the engagement end date.
Management’s response
Contractor departures were not captured in the leaver register because engagement end dates were held only in purchase-order records. Effective 01-Dec-2027 a single departure register covering employees and non-employees is maintained by the service desk lead, with procurement required to file an end-of-engagement notice on the last working day.
Two things are worth noticing in that wording. The test names the population before the sample — 15 of 40, not simply “a sample of departures” — and the exception is described by what happened rather than characterised as a failure. Management’s response names an owner, a register and a date; a response that says the process “has been reinforced” tells a reader nothing and tends to invite the same question next year.
Whether that deviation prevents the criteria being met is the service auditor’s judgement — a single delay with a corroborated root cause and a named remediation owner is commonly described as an exception without qualifying the opinion, but that is not a guarantee. The diagnosis matters more. The control was owned; the SLA was written; the tooling worked. What had no owner was the trigger — and a control whose trigger is unowned operates only when somebody remembers. Note too that the tested population was not HR’s list of thirty-one but the reconciled forty — nine larger, and nearly thirty per cent bigger. Had the sample been drawn from HR’s list, the one late revocation could not have been selected at all, and the report would have described a control that was never actually tested against the population it applies to. See opinions and exceptions.
Evidence
How ownership is actually evidenced
Ownership is rarely tested as a control in its own right. It is tested indirectly, through every other control — which is why it cannot be fixed late.
| What is requested | Accepted | Rejected |
|---|---|---|
| Roles-and-responsibilities matrix | Every described control, the accountable role, the named person holding it, an effective date — approved and circulated before the period opened. | A matrix dated after period end, or one listing departments rather than people. |
| A walkthrough with the named owner | The person named describes the control unprompted and shows what they produce — inquiry alone is not sufficient appropriate evidence. | A compliance manager narrating a control they do not perform. |
| Approval evidence identifying the approver | Records where the system captures the approver’s identity — ticket approvals, pull-request reviews, workflow sign-offs. | A screenshot with no attribution, a shared-mailbox approval, or one self-recorded by the requester. |
| The population, before any sampling | A system-generated export covering the whole period plus an independent source it reconciles to — leavers to payroll, changes to the deployment log, incidents to alerting history. | A hand-maintained spreadsheet with nothing corroborating it. The sample is then worthless. |
| Authority for a delegated performer | A dated delegation in the matrix, with the owner still reviewing and signing off the output. | A control performed all period by someone the description never connects to it — indistinguishable from an unauthorised performer. |
| Owner change during the period | A dated handover, the updated matrix version, and unbroken evidence across both tenures. | A current matrix showing only the new owner, leaving the earlier months unaccounted for. |
Population first, sample second
The service auditor has four procedures available in an examination under AT-C sections 105 and 205: inquiry, observation, inspection of documentation and reperformance. Ownership is tested through the first three and almost never the fourth. Inquiry establishes who says they perform the control; observation confirms they can actually do the thing they describe, which is where a nominal owner who has never opened the console comes apart; inspection tests whether the artefact carries their identity. Reperformance — the auditor re-running the control themselves — surfaces ownership only incidentally, because re-executing an access review says nothing about who was accountable for the one that already happened.
A population request, as it arrives
Provide the entitlement export for [system] as of 31-Mar-2027, system-generated, showing the generating account, the generation timestamp, the report parameters and the record count; confirm in writing that the export is complete and name the source it reconciles to.
Every clause in that request is load-bearing, and each one fails a different way. The record count must be visible on the export itself, because a count typed into an email is an assertion rather than an attribute of the file. The query parameters or report definition should be captured in the same screenshot as the results, so the filter that produced the rows can be seen alongside them — an export filtered to active users only, sent in answer to a request about all users, is complete and wrong. And an export a client opens, tidies and re-saves before sending is no longer system-generated; it is a spreadsheet the client made, and it will be treated as one.
Only then does sampling begin, and sample sizes follow control frequency. The AICPA publishes no mandatory table; what exists is a convention most firms work from — market practice, not a rule. An annual control means one occurrence tested in full with no sampling relief; quarterly, two of four, sometimes all four; monthly, two to four; weekly, five to nine of fifty-two; daily, twenty to forty, with twenty-five the usual starting point above a population of two hundred and fifty. The full sampling convention sets out where those numbers come from and what a deviation does to each.
Event-driven controls are sized off the population rather than the frequency — a population of forty terminations typically draws a sample in the region of fifteen to twenty-five, which is exactly why completeness of the population is tested before the sample is drawn rather than after. Low-frequency controls are the unforgiving ones at the other end: an annual disaster recovery test whose owner was between jobs when it fell due has no second occurrence to fall back on.
One request surprises almost every first-time client: the auditor may ask who performed a specific occurrence, not just who owns the control. For the March access review the answer must be a person and a date, and it must match the artefact. Where the export carries no reviewer name, the evidence is weak however good the matrix is.
Small teams
When one person owns fourteen controls
In a twelve-person company one person often owns most of the technical control set, and that is not a defect to be papered over. Headcount does not remove a criterion; it changes how the control is designed. The point of focus under CC5.1 permits alternative control activities where segregating incompatible duties is not practical — a substitute, not an exemption.
The substitute is usually a detective review by a different person. The CTO grants production access; the Head of Operations reviews the entitlement export quarterly and reports to the CEO. The founder merges code; branch protection requires a non-author approval, which maps onto the point of focus under CC8.1 about implementing changes with consideration of segregation of responsibilities. The reviewer needs independence from the act reviewed, not seniority.
Two boundaries. An owner who reviews their own work has not created a compensating control. And external help does not transfer accountability: an advisor or vCISO can design the control and prepare the evidence while an internal executive remains the accountable owner. That is how TCSA works — readiness, implementation, evidence and coordination. We never certify, attest, audit or sign; the opinion comes from an independent licensed CPA firm. More in SOC 2 for small teams.
Turnover
When the owner leaves mid-period
The departure is not the problem; the fortnight after it is, in which the outgoing owner has stopped and the incoming owner has not started. The examination covers the whole period, so the matrix needs versions rather than a current state.
1
A dated handover record
Which controls transferred, from whom, to whom, effective when — signed by the incoming owner and their manager where the outgoing owner has gone.
2
The evidence position at handover
Which occurrences were completed, which are outstanding, and where the artefacts live. Most often skipped; costs weeks in fieldwork.
3
An updated matrix version
A new version with the effective date, retaining the prior holder so both tenures are visible.
4
The access consequence
The outgoing owner is also a leaver. Approver rights and admin roles come off on the same SLA as anyone else.
5
A named interim, if there is a gap
Usually the departing owner’s manager. An interim named for six weeks is defensible; a vacancy nobody recorded is not.
One case needs different handling: a control that genuinely did not operate during the transition — the quarterly review nobody ran because the owner had left. That is a deviation, and it should be disclosed rather than reconstructed. Back-dated evidence turns one control failure into a question about everything else management has asserted.
Objections
What the service auditor challenges
These four arrive in fieldwork, from the person doing the testing. They are not customer questions — a customer never sees your ownership matrix.
“Your CTO owns fourteen controls. That is not credible.”
Concentration is a fact of a small organisation, not a defect — CC5.1 permits alternatives where segregating incompatible duties is not practical. What is not credible is concentration with no second pair of eyes. Answer specifically: the CTO approves production access, the Head of IT reviews the quarterly entitlement export and reports exceptions to the CEO.
“Your list shows roles, not people.”
Record both. The role survives turnover; the name is who sits in the walkthrough. A matrix listing only “Head of IT” cannot say whether that seat was filled in March; one listing only a person is wrong the day they are promoted.
“The person who grants access also approves it.”
This is the real finding behind most ownership questions. Separate request, approval and grant: the manager approves on business need, IT grants, a third party reviews on a defined cycle. Where headcount forbids that, CC5.1 permits an alternative — a detective review by someone other than the grantor.
“Your control owner left mid-period.”
A departure is not an exception. What matters is whether the control kept operating and evidence is continuous: the dated handover, the matrix version recording the change, the occurrences either side of it. What fails is a matrix showing only the new owner.
After the report is issued
What a buyer’s security team pushes back on
The buyer works from a different document. They have the issued report and your security questionnaire, and nothing else — so ownership reaches them only through what Section 3 describes and what Section 4 says was tested.
“Your report shows one person approving and performing production access.”
Point at the Section 4 test of the compensating detective review and the fact it was tested without exception. A buyer reading a SOC 2 report cannot see your matrix at all — they see the control as described in Section 3, the procedure the service auditor applied, and the result. If the compensating review is not described, it does not exist as far as the reader is concerned, which is an argument for writing it into the description rather than for arguing about it afterwards.
“Your security questionnaire names no security officer.”
Buyers increasingly require a named accountable individual in the questionnaire even where the report names none, and the two are not in conflict. DC section 200 requires the description to cover people as a component of the system, but it calls for functions and responsibilities rather than individual names. The questionnaire is where the name is supplied — and it should be the same name the matrix carries, because a mismatch between the two is the thing a diligent reviewer actually notices.
Where this gets contested
Edge cases worth settling early
Each is cheaper to settle before the period opens than during fieldwork. Each resolves to a row in the matrix, in the schema above — the position on its own settles nothing until somebody writes it down.
An MSP or outsourced provider operates the control
Accountability stays with your management; the provider performs. If it is a subservice organisation, choose carve-out or inclusive explicitly — under carve-out your owner is accountable for monitoring the provider, not the activity.
Matrix row: Accountable — Head of IT, for monitoring; Performer — the provider; Evidence — the monthly service report, reviewed and signed by the Head of IT within ten business days of receipt; System of record — the provider’s ticketing instance, with an export right written into the contract.
“Our compliance platform owns it”
A tool is evidence infrastructure, never an owner. When an automated check silently stops running in April, the auditor asks who was accountable for noticing, and a platform cannot answer.
Matrix row: Accountable — the named owner; Performer — the platform; Evidence — the platform’s collection log plus the owner’s dated confirmation that collection ran in every month of the period, with the gap investigated where it did not.
A founder both performs and approves
Legitimate where unavoidable, best handled by naming the compensating review. CC5.1 permits alternative control activities where segregating incompatible duties is not practical; an external reviewer independent of the founder is a recognised alternative, and the description should name the review rather than leave it implied.
Matrix row: Accountable — the founder, as performer and approver; Reviewer — an external party independent of the founder, or a non-executive director; Evidence — the reviewer’s dated written conclusion on the period’s activity, produced on the stated cycle.
The named owner is a contractor
Contested, reasonably. A contractor can perform a control; accountability resting with someone who has no continuing obligation to the entity is harder to defend. Name the employee who reviews their output.
Matrix row: Accountable — the employing manager; Performer — the contractor; Evidence — the contractor’s output plus the manager’s countersignature on the same artefact, dated within the period the occurrence belongs to.
A vCISO or external advisor as owner
The advisor can design the control and prepare the evidence. Management stays accountable and the matrix should say so — internal executive as owner, advisor as performer.
Matrix row: Accountable — an internal executive named in the matrix; Performer — the vCISO; Evidence — the advisor’s work product plus the executive’s approval record, with the walkthrough taken with the executive and not the advisor.
A parent or shared-services team performs it
Is that team inside the system boundary described in Section 3, and does someone in the reporting entity answer for the outcome? Outside the boundary it is a subservice or vendor relationship.
Matrix row: Accountable — a named individual employed by the reporting entity; Performer — the shared-services team; Evidence — the shared team’s output plus the boundary statement in Section 3 that places them inside it; System of record — the parent’s instance, with an export the reporting entity can obtain on request.
If you run ISO 27001 alongside SOC 2, keep one owner register rather than two. ISO/IEC 27001:2022 clause 5.3 requires top management to assign and communicate roles, responsibilities and authorities relevant to information security, and Annex A control owners are recorded in the Statement of Applicability — so a single register, with a column marking which rows are in SOC 2 scope and which carry an Annex A reference, serves the SOC 2 matrix and the SoA at once. The alternative, two registers maintained by two teams, reliably disagrees by month four and gives an auditor on either side a question you did not want.
Settle the subservice question before writing the description — see carve-out versus inclusive and subservice organizations. Complementary user entity controls are the mirror image: not yours to own, and the description should state what has been assigned to the reader.
Frequently Asked Questions
Does SOC 2 require every control to have a named owner?
No Trust Services criterion uses the phrase “control owner”, so the literal answer is no — but the substance is required. CC1.3 asks management to define, assign and limit authorities and responsibilities; CC1.5 requires the entity to hold individuals accountable for their internal control responsibilities; and a point of focus under CC5.3 places accountability with personnel of the function in which the risk resides. One named owner per control is the market convention that satisfies all three.
Can a team or department be listed as the control owner?
It is allowed on paper and fails in practice. A department cannot sit in a walkthrough, attest that a population is complete, or answer for a month in which the control did not operate. In fieldwork the auditor asks who performs the control, and either a person is produced — in which case the matrix was wrong — or nobody is, and the gap surfaces as a deviation. The concrete failure is usually the entitlement export: somebody has to sign that it covers every account in the system, and “Security” cannot sign anything. Record the role and the individual holding it, with effective dates, and the department name becomes a grouping rather than an answer.
Who should own offboarding — HR or IT?
Both, split explicitly, because it is two controls sold as one. HR — or procurement, for contractors and other non-employees — is accountable for the leaver record existing within a defined window. IT is accountable for the access removal that follows, measured against your policy SLA. Almost every offboarding exception traces to an unowned trigger rather than an unowned action: the employee process works because payroll forces the notification.
Should security or procurement own vendor reviews?
Security or GRC should be accountable; procurement should be responsible for the calendar. CC9.2 requires the entity to assess and manage risks associated with vendors and business partners, which is a judgement rather than an administrative task. When accountability sits with procurement, the review degrades into confirming a report was received rather than reading it, and the artefact becomes a saved attachment instead of a written assessment naming a reviewer.
What happens if a control owner leaves during the observation period?
Nothing, provided the control kept operating and the evidence is continuous. Produce a dated handover, an updated matrix version retaining the outgoing owner with an end date and adding the incoming owner with a start date, and the occurrences performed either side of the change. Name an interim where no replacement has been hired. The failure mode is a matrix showing only the current owner.
How does an auditor test control ownership?
Mostly indirectly, through three of the four available procedures. Inquiry establishes who says they perform the control, in the walkthrough — but inquiry alone is not sufficient appropriate evidence under the attestation standards, so it is followed by observation, watching the named person actually operate the control or navigate the system it runs in. Inspection then tests whether the artefact carries their identity: a ticket approval, a pull-request review, a signed export. Reperformance rarely touches ownership at all. The fourth exposure is completeness testing, where the owner must produce a population export and name an independent source it reconciles to.
Can one person own multiple SOC 2 controls?
Yes, and in a small company one person will own most of them. Concentration is not itself a finding. What matters is whether incompatible duties sit with the same person without a substitute — the point of focus under CC5.1 permits alternative control activities where segregating incompatible duties is not practical, and looks for a substitute rather than an omission. In practice that means a detective review by someone independent of the act reviewed.
Can an external consultant or vCISO be the control owner?
An external party can design a control, run the process and prepare the evidence, and buyers accept that routinely. Accountability should remain with an internal executive and the matrix should say so, because an outside party carries no continuing obligation to the entity. TCSA operates on that basis: readiness, implementation, evidence and coordination. We never certify, attest, audit or sign — the opinion comes from an independent licensed CPA firm.
Does a compliance automation platform count as the control owner?
No. A platform is evidence infrastructure. It can collect artefacts continuously and cut the manual effort substantially, but it cannot answer for an outcome, approve an exception, or notice that it stopped collecting. The question an auditor asks about an automated check that silently stopped running in April is who was accountable for noticing, and that has to resolve to a person. Record it as two fields rather than one: accountable — the named owner; performer — the platform. The evidence is then the collection log plus the owner’s dated confirmation that collection ran in every month of the period, which is also the artefact that catches a broken integration before fieldwork does.
What should a SOC 2 roles and responsibilities matrix contain?
Ten fields, and it is a spreadsheet. Control ID, so Section 3 ties to the Section 4 test. Criterion mapped, so coverage can be traced. The control description as written. The accountable role, which survives turnover, and the named individual, who sits in the walkthrough. Effective from and to dates, which establish who was accountable in March. The performer where the work is delegated. Frequency, which drives the sample size. The evidence artefact the control produces. And the system of record the population comes from, which identifies who can attest completeness. It must be approved and circulated before the period opens — CC2.2 addresses communicating internal control responsibilities — and prior holders are retained as rows rather than overwritten.
Do control owners have to be named in the system description?
No. DC section 200 requires the description to cover the components of the system, of which people are one, but it calls for functions and responsibilities rather than individual names — “the Head of IT approves privileged access requests” is description-grade; “A. Rao approves privileged access requests” is not required and rarely wise. The names live in the matrix the service auditor requests separately, which is an internal artefact the report reader never sees. Naming individuals in Section 3 also creates a maintenance problem you do not want: the report is distributed for a year or more after issue, and every promotion, departure or reorganisation makes a distributed document wrong.
Related reading: the SOC 2 controls list, common SOC 2 pitfalls, the compliance checklist, and the SOC 2 hub.
Written By Expert Auditors
Keep Exploring
Related Reading
SOC 2 Controls List
No official list exists — illustrative controls by criteria series (CC1–CC9).
Read moreSOC 2 With a Small Team
Segregation of duties when the founder approves everything — the compensating controls that actually pass.
Read moreContinuous Monitoring and Year-Round Evidence
Why SOC 2 fails in the last four weeks, and designing controls that generate their own evidence.
Read moreWhat SOC 2 Readiness Actually Involves
What it produces, what it is not, and why the readiness firm generally should not sign the opinion.
Read moreSOC 2 Knowledge Hub
Type 1 vs Type 2, criteria, timelines and audit prep — all guides.
Read moreSOC 2 Evidence: What Auditors Accept
Why screenshots are weak, what a defensible artefact contains, and the common rejections.
Read moreGet in touch
Book a free consultation or send us your requirements. We respond within 24 hours.
Quick Call
Pick a time slot
Send Requirements
Get a custom quote in 24 hours