Control ownership: the five-column matrix that leaves no control unowned
A control ownership matrix lists every security control with one named person against it. Your provider's version has two columns, the control and the party. Yours needs five: the control, the named owner, the side it runs on, the evidence it produces, and the review date. Federal rules already name the document.
- A control ownership matrix gives every security control one named person, the evidence it produces, and the date it was last reviewed.
- Half of it is already written. Federal defence contracting rules require a customer responsibility matrix, and the big cloud platforms publish their own.
- A provider's published matrix is illustrative guidance. Microsoft says its own version does not modify the terms of any agreement with you.
- One control can split in half. The federal cloud.gov platform publishes flaw remediation as platform patches on one side and application updates on the other.
- Shared is the row that fails. A shared row needs two names, an order of play, and a date.
What is a control ownership matrix?
A control ownership matrix is a written list of your security controls with one named person against each row. It records who operates the control, what evidence the control produces, and the date the row was last reviewed. One page is enough for most small businesses.
The failure it prevents is specific. You believe your IT provider patches the firewall. Your provider believes you bought server patching only. Neither belief is written down, so nobody patches the firewall for two years. Nobody escalates it either, because there is nobody to escalate it to. The gap then surfaces in an audit, a customer security questionnaire or a breach, which is the most expensive place to find it.
Your IT provider is your largest third party, so the stakes are ordinary business stakes. Verizon reported breaches involving a third party now accounting for 48% of all breaches, after third-party supply chain breaches jumped 60% in a single year. IBM puts the global average cost of a data breach at USD 4.99 million and measures 247 days to identify and contain an active breach.
This guide is about the artefact rather than the argument. Which security tasks fall between you and your provider lists the twelve usual orphans. This post is the document that holds the answers, column by column, and the places where the assumption of ownership most reliably fails.
Your provider has already written half of this matrix
Half of the matrix already exists, in documents you can request this week. Three separate regimes require somebody to write down which party does what, and each one produces a different artefact with a different name.
Federal defence contracting names the document outright. Under the CMMC scoping rule, an external service provider's services and the data involved need to be documented in the OSA's SSP and described in the ESP's service description, alongside a customer responsibility matrix (CRM), which describes the responsibilities of the OSA and ESP. OSA means the organisation seeking assessment, which is the buyer. The rule repeats it at the higher level, where the artefact describes the responsibilities of the OSC and ESP with respect to the services provided. If that trigger might apply to you, start with HIPAA vs CMMC vs SOC 2.
The cloud platforms publish their own. Microsoft prints a table it calls a responsibility matrix, and three of its rows never move: customer data, configurations and settings, and identities and users sit in the customer column for on-premises, IaaS, PaaS and SaaS alike. AWS sorts controls into three shapes instead, naming controls which a customer fully inherits from AWS, controls which apply to both the infrastructure layer and customer layers, and controls which are solely the responsibility of the customer.
An audit report adds a fourth version. The AICPA's own SOC attestation guidance treats Complementary User Entity Controls (CUEC) as a key topic, and those are the controls a provider's auditor assumed your side was running. Our guide to what your provider's SOC 2 report actually covers walks through that section and what to do with it.
So the first move is a request, not a workshop. Ask your provider for its responsibility matrix however it is titled, for its audit report under a non-disclosure agreement, and for the published shared responsibility model of every platform it runs on your behalf. Three emails, and most of your rows arrive written by somebody else.
Why the provider's version is not your matrix
A provider's matrix allocates work. It does not make anyone accountable, and the biggest publisher of one says so on the page. Microsoft states that its model is illustrative guidance and is not intended to convey legal conclusions or to modify or contradict the terms of any agreement between you and Microsoft, and that it uses responsibility in a governance sense, meaning who is expected to configure, operate, and monitor each control.
Read that as a buyer. The most widely cited responsibility matrix in the industry says in its own words that it is not the contract. Your service level agreement is the contract, and the matrix is a map of expectations.
Every provider-side version also shares one shape. It names a control and a party. It never names a person, never names the evidence the control produces, and never carries a review date. Those three omissions are what an auditor, an insurer or a customer asks about, because each asks who, not which company.
AWS hands the same work back to the customer in plain words, telling them to review third-party audit attestation documents to determine inherited controls. Determining is your job. Writing down the result, with a name beside it, is also your job, and nobody else will do it.
Which rules require control ownership to be assigned in writing?
Four published rules require assigned ownership, and each asks for something slightly different. The useful part is the wording, because you can quote it when you ask a provider to put its half in writing.
- Name a person. The HIPAA Security Rule requires a covered entity or business associate to identify the security official who is responsible for the development and implementation of the policies and procedures the rule requires. One named official, not a department. Who signs what is a separate question, covered in who signs the business associate agreement.
- Designate an overseer. The FTC Safeguards Rule requires a firm to designate a qualified individual responsible for overseeing and implementing your information security program. That individual may sit at a service provider, and the rule then makes you retain responsibility for compliance and name a senior member of your own staff to oversee them.
- Document the roles. CISA's performance goal 1.A sets the outcome that roles, responsibilities, and authorities related to the organization's cybersecurity program are established and communicated, enforced, and aligned within the organization and external partners. Its recommended action is blunter still: all roles and responsibilities involving cybersecurity should be documented in an organization's cybersecurity policy.
- Describe the service. The CMMC rule requires an external provider's services to be documented in the OSA's SSP and described in the ESP's service description, with a customer responsibility matrix beside it.
Two more goals aim straight at a managed provider. Goal 1.E asks organisations to develop and maintain an understanding of the services, including the security products provided by MSPs. Goal 1.D asks that procurement documents and contracts, such as service-level agreements (SLAs), stipulate that vendors notify the procuring customer of security incidents and vulnerabilities within a risk-informed time frame, which is itself a row with an owner and a deadline.
None of these rules settles whether your business is compliant with anything, and none is a verdict on your provider. They are published sentences from parties with nothing to sell you, which makes them cheap language to borrow.
What belongs in every row: five columns
Give every row five columns. The control, the named owner, the side it is operated on, the evidence it produces, and the review date. A provider's version carries the first and the third. The other three are what turn a list into an allocation.
- Write the control as an action. Patch internet-facing firewall firmware, not firewall management. A noun describes a product, and a verb describes work somebody has to do.
- Name one person, not a company. A company name routes the work. A person owns it. Two names on one row means the row is not finished.
- Record the side it runs on. Yours, theirs, or theirs under your written instruction. The third case is the one people forget, and it is where approval delays live.
- Name the evidence. One artefact that proves the control ran, such as a patch report, a restore log or an access review export.
- Date the review. The day the row was last confirmed with the provider, and the month it is next due.
The evidence column is the one buyers skip and the one an auditor opens first, because an auditor tests operation rather than intention. Our guide to the audit evidence nobody collects covers what each record has to show. For the matrix itself, one line naming the artefact and where it lives is enough.
Build the row list from your own asset inventory rather than from the provider's service catalogue. CISA's goal 2.A asks organisations to maintain a regularly updated inventory of all organizational assets, covering data, hardware, software, systems, facilities and personnel. A service catalogue tells you what you bought. An asset inventory tells you what has to be protected, and the difference between the two lists is a set of rows nobody has written yet.
Five rows where ownership quietly falls through
Five rows account for most unowned work in a managed IT relationship. Write these first, because each one is close enough to the boundary that both sides can reasonably assume the other has it.
Identity and privileged access
Start here, because identity carries the most incidents. Sophos found 67% of incidents rooted in identity-related attacks and a lack of MFA in 59% of cases, across 661 incident response cases handled between November 1, 2024 and October 31, 2025. Privileged access is the sub-row that fails, because somebody has to review who still holds administrator rights, and nobody is paid to notice. CISA gives a usable cadence inside its offboarding goal, telling organisations to review user access and disable accounts when inactive for a specified period (e.g., 30 days).
Give every service account its own row, because no service account ever leaves. CISA's goal 3.C is the only one that names them, requiring that system administrators and service/machine accounts have unique passwords that differ from those of regular user accounts, and adding that no universal non-person entity (NPE) account passwords should be deployed.
Log retention, and who can search it
Split this into two rows, collecting logs and retaining them, because the second one is a budget decision disguised as a technical setting. CISA's goal 3.Q names the control without a number, saying only that logs are stored for a duration informed by risk or pertinent regulatory guidelines, so somebody has to own the duration. The defaults will not help you. Microsoft Entra ID retains audit logs and sign-in logs for seven days on Microsoft Entra ID Free and 30 days on P1 and P2.
Sophos found missing logs caused by data retention issues doubled over last year, largely driven by firewall appliances where the default was only seven days, and in some cases, 24 hours. Set that beside the same report's median dwell time of three days and the shape of the problem is clear enough. Seven days of log retention survives a fast intrusion and nothing slower.
Backup testing, which is not backup execution
Make these two rows as well. Backup testing is a separate control from running the backup, with different evidence and a different failure mode, and only one of them appears on most invoices. CISA asks organisations to test backups and recovery on a recurring basis, no less than once per year. Somebody has to verify that the data comes back, and the annual restore test is the row that proves it.
Check the destination while you are there. Microsoft 365 Backup restores OneDrive and SharePoint to the same or new URL and Exchange to a same or new folder within user's mailbox, and Microsoft states that data never leaves the Microsoft 365 data trust boundary. Restoring one file is routine. Carrying a copy out of the tenant is a different control that nobody has bought.
Patching the things that are not servers
Name an owner for firmware, browsers and line-of-business applications separately from servers, because the answers usually differ. Verizon puts exploitation of vulnerabilities at 31% of breaches, now the most common initial access vector, with credential abuse, the previous leader, down to 13%. It also found only 26% of critical vulnerabilities in the CISA known exploited catalog were fully remediated in 2025, a drop from the previous year's 38%, with the median time for full resolution up to 43 days, against 32 days the previous year.
AWS puts the split in writing and it is worth copying word for word. Patch management is a shared control where AWS is responsible for patching and fixing flaws within the infrastructure while customers are responsible for patching their guest OS and applications. Two owners, one control name, and the line between them sits exactly where an unowned firewall lives.
Whatever the cloud model leaves with you
Copy these rows straight out of your platform's own model, because the platform has already decided them. Microsoft lists four duties you keep regardless of what you buy, and separately shows client devices as shared in SaaS and applications as shared in both PaaS and SaaS. Read the whole split in the cloud shared responsibility model, then lift every customer-column row into your matrix with a name against it.
Shared is the word that breaks a matrix
Treat shared as a prompt for two rows rather than an answer. AWS defines shared controls as controls which apply to both the infrastructure layer and customer layers, but in completely separate contexts or perspectives. Separate contexts means different work, different people and different evidence, which is three good reasons not to leave it on one line.
The clearest published example comes from the federal government's own cloud platform. cloud.gov, run by the GSA, publishes four control numbers split down the middle: CM-2 baseline configuration as platform configuration against application configuration, RA-5 vulnerability scanning as infrastructure and platform scanning against application code scanning, SI-2 flaw remediation as platform patches against application updates, and AU-12 audit generation as platform events against application logging. One control number, two owners, every time.
The split also moves on a technical choice nobody will flag to you. cloud.gov's customer column grows by deployment method. Customers on standard buildpacks own application code and dependencies while the platform handles language runtime updates and patches. Customers on custom buildpacks also own buildpack maintenance and updates and runtime security patches. Customers running containers also own base image maintenance and OS-level security updates.
Nothing in that contract changed. The architecture changed, and three controls crossed the line with it. The same thing happens when your provider moves a workload, swaps a backup product or puts a new appliance in your rack, which is why the review date matters more than the first draft.
A row that names a company has routed the work. A row that names a person has assigned it. Only the second one answers the question an auditor asks.
How to keep the matrix true after the meeting
Put the review cadence inside the matrix, because the document is only accurate on the day it was signed. The FTC Safeguards Rule names the habit, requiring firms to oversee service providers by requiring your service providers by contract to implement and maintain such safeguards and by periodically assessing your service providers based on the risk they present and the continued adequacy of their safeguards.
Borrow the cadences the published goals already set rather than inventing your own. Backup and recovery testing no less than once per year. Account review with inactivity measured against a specified period such as 30 days. An asset inventory kept regularly updated. Three dates, and the matrix maintains itself.
Reconcile the matrix against your invoice once a quarter. A control you pay for that nobody operates is the expensive version of this problem. A control nobody pays for is the common one. When a customer or an insurer sends a security questionnaire, the matrix is the file you answer from, which is why how to answer a customer security questionnaire starts by sorting every question by owner.
You have more options than you think if a provider will not engage with any of this. Our directory holds 24,491 provider records across 730 city datasets, and the median market lists 16 ranked providers, so a firm that refuses to put its half in writing is not the only firm in your city. We are independent and do not sell IT services.
What to ask your provider this week
Ask for five things in writing, then keep every answer in the same file as the matrix.
- Request the responsibility matrix. Ask for the provider's own split of controls, in writing, whatever it is called internally.
- Request the platform models. Get the published shared responsibility model for every cloud platform the provider runs for you.
- Ask who holds each half. Get a named person on their side and name one on yours, for every row marked shared.
- Ask what evidence each control produces. One artefact per row, and where you can see it without asking.
- Ask when each row is reviewed. A dated review, plus the name of whoever calls it.
No document makes a business secure, and no honest provider claims otherwise. What a control ownership matrix does is remove the sentence that costs the most in an audit, a questionnaire or an incident, which is that we thought you were doing that. Write the rows, name the people, date the reviews, and that sentence has nowhere left to live.
FAQ
What is a control ownership matrix?
A control ownership matrix is a written list of security controls, each with one named owner, the evidence it produces and a review date. Federal contracting rules require a customer responsibility matrix (CRM), which describes the responsibilities of the OSA and ESP, the buyer and its provider. One page covers most small businesses.
Who is responsible for security controls, my business or my IT provider?
Both, control by control, and some rows never move. Microsoft places customer data, configurations and settings, and identities and users in the customer column for on-premises, IaaS, PaaS and SaaS alike. Everything else is negotiable, so write the split down rather than assuming it.
Does my provider have to tell me which controls are my job?
Only where a rule reaches the work. The CMMC scoping rule requires a provider's services to be documented in the OSA's SSP and described in the ESP's service description with a customer responsibility matrix. CISA separately asks buyers to develop and maintain an understanding of the services, including the security products provided by MSPs.
Is a shared responsibility model the same as a control ownership matrix?
No. A shared responsibility model is the platform's published split, and Microsoft calls its own illustrative guidance and is not intended to convey legal conclusions or to modify or contradict the terms of any agreement. A control ownership matrix is your written allocation, with a named person, the evidence and a date on every row.
How often should a control ownership matrix be reviewed?
Quarterly against the invoice, and immediately after any architecture change. The FTC Safeguards Rule requires periodically assessing your service providers based on the risk they present and the continued adequacy of their safeguards, and CISA asks for backup and recovery testing no less than once per year. Put both dates in the matrix.
Best IT MSP is the independent directory of managed IT and cybersecurity providers across the US and Canada. Organic ranking is earned on verified rating and firmographic data, and paid placement is always labelled. Shortlist three firms in your city, then ask all three for their responsibility matrix and see which one sends it.