Who Owns What? 12 Security Tasks That Fall Between You and Your MSP
Twelve security tasks routinely fall between a business and its IT provider, owned by neither. CISA tells customers to identify ownership of security roles in the contract and to address requirements falling outside its scope. Assigning all twelve takes one meeting.
- Ask your provider for a written list of what it does not do.
- Third-party patching, firmware and restore testing are the usual orphans.
- Shadow AI incidents more than doubled to 43 percent of breached organisations.
- Fewer than half of organisations secure service accounts and API keys.
- Outsourcing moves the work. It does not move the risk.
Which security tasks fall between you and your MSP?
Twelve tasks account for most of the gap, and they share a shape. Each one is small enough that nobody escalates it, and each sits close enough to the boundary that both sides can reasonably assume the other has it.
The gap is not usually caused by a provider cutting corners. It is caused by a scope document that lists what is included and never lists what is excluded, so the excluded work becomes invisible rather than unassigned.
Run down this checklist and write a single name beside each item. Not a company, a person. The ones you cannot name are your findings.
- Joiner, mover, leaver. Creating, changing and removing accounts as staff arrive, change role and leave.
- Privileged access review. Checking, on a schedule, who still holds administrative rights.
- Operating system patching. Servers and workstations, including the machines that keep failing.
- Third-party application patching. Browsers, PDF readers and the line-of-business software.
- Firmware updates. Firewalls, switches, access points and anything else with a web login.
- Backup coverage. Deciding what is in scope, and noticing what was never added.
- Restore testing. Proving the data comes back, with a date against it.
- Out-of-hours alert triage. Reading the alert at 2am, and deciding whether to act.
- Departmental SaaS. The tools bought on a card that never passed through IT.
- Non-human identities. Service accounts, API keys and automation credentials.
- Security awareness training. Delivery, tracking, and following up the people who fail it.
- Policy documents. Writing them, reviewing them, and evidencing that staff read them.
Why do these tasks end up owned by nobody?
Because contracts describe inclusions and stay quiet about exclusions. The joint advisory puts the fix in its opening list of tactical actions, telling both parties to ensure MSP-customer contracts transparently identify ownership of ICT security roles and responsibilities.
It then asks providers for something most scope documents never contain. MSPs should give clear explanations of the services the customer is purchasing, the services the customer is not purchasing, and all contingencies for incident response and recovery. The middle clause is the one worth requesting in writing, because a list of exclusions is a map of exactly this gap.
The duty to look runs the other way too. Customers should ensure they have a thorough understanding of the security services their provider supplies and address any security requirements that fall outside the scope of the contract. Outside the scope does not mean not your problem.
CISA's framework offers the tool for this. Organisations can define roles in a vendor agreement using a shared responsibility model that articulates the vendor's responsibilities, the customer's responsibilities, and any responsibilities shared by both parties, framing decisions such as which entity applies patches, maintains hardware, or trains employees. It also names the trade-off honestly: ceding more responsibility to an MSP may increase cost-efficiency but could also increase risk exposure, and organisations may lose visibility across their IT enterprise that could otherwise inform threat detection.
Who owns identity, joiners and leavers?
Name the person who removes access on someone's last day, and check they hear about last days. This is the most commonly split task in the list, because HR knows a leaver is leaving and IT often finds out afterwards.
The advisory treats the transition moment as the risk, telling customers to periodically review their attack surface and disable user accounts when personnel transition. Movers matter as much as leavers. Somebody who changes department and keeps both sets of permissions accumulates access nobody granted deliberately.
Ask a harder question about the plumbing beneath it. Customers should review and verify all connections between internal systems, MSP systems and other networks, and ensure management of identity providers and trusts between environments. Trust relationships between your directory and your provider's are exactly the kind of thing both sides assume the other configured correctly.
Who owns patching, including software your provider did not install?
Split this into three and assign each part separately, because the answer usually differs. Operating systems are almost always the provider's. Third-party applications are frequently nobody's. Firmware is nobody's more often still.
That gap is expensive. Verizon found vulnerability exploitation is the top initial access vector, at 31 percent of breaches, and unpatched software does not care which party was supposed to update it.
Make the arrangement standing rather than occasional. Customers should understand their provider's policy on software updates and request that comprehensive and timely updates are delivered as an ongoing service. Then ask the specific question that finds the gap: who patches the browser plugin the finance team needs, and who patches the firewall itself?
Who owns backup coverage and restore testing?
Separate the two, because a provider can own the backup while nobody owns the proof. Coverage decides what is captured. Testing decides whether it returns.
The advisory asks organisations to regularly update and test backups, including gold images of critical systems. Gold images are the usual casualty of unclear ownership, because restoring a file is routine and rebuilding a domain controller is a project somebody has to schedule.
The coverage half fails quietly. A new file share, a new SaaS platform or a new database gets added to the estate and never added to the backup job, and nobody notices until it is needed. Assign someone to reconcile the backup scope against the asset list quarterly.
Who owns alerts outside working hours?
Establish whether anyone is actually reading them, because monitoring and response are separate purchases and are frequently confused. A tool that generates alerts into a queue nobody watches overnight is monitoring in name only.
The advisory expects the capability regardless of who supplies it, saying all organisations should implement endpoint detection and network defense monitoring capabilities in addition to using application allowlisting and denylisting.
Ask three questions and write the answers down. Who receives the alert at 2am, what are they authorised to do without waking anyone, and what is the deadline for telling you it happened?
Who owns the tools and accounts nobody bought?
Assign this one deliberately, because by definition it is outside every scope document ever written. Departmental software bought on a card, and machine accounts created years ago, are the two categories no contract mentions.
The unapproved-tool problem is growing fast. IBM found security incidents involving shadow AI more than doubled to 43 percent of breached organisations, from 20 percent the previous year, that 68 percent of breached organisations lacked governance to manage AI or detect shadow AI, and that breaches involving shadow AI cost an average of 5.39 million dollars, up from 4.63 million.
The quieter half is the accounts with no person attached. IBM reports fewer than half of organisations secure non-human identities such as service accounts and automation credentials. These never trigger a leaver process, because nobody leaves. Give them an owner, an expiry and a review date.
Who owns training and written policy?
Decide who runs it and, more importantly, who chases the people who ignore it. Delivery is easy to buy. Follow-up is the part that changes behaviour and the part nobody owns.
CISA's shared responsibility model explicitly covers which entity trains employees alongside patching and hardware, which places it firmly in the negotiable middle rather than assuming it belongs to either side.
Policy documents split the same way. A provider can supply templates. Only you can approve them, apply them to how your business actually works, and evidence that staff have read them, which is the part an auditor or insurer asks to see.
How do you close the gap in one meeting?
Book ninety minutes, put the twelve tasks on screen, and give each one exactly one owner. Shared is allowed, provided you name which side leads and who acts first. Unassigned is not allowed to survive the meeting.
CISA sets out the three-way sort for smaller businesses directly, advising them to determine which tasks the MSP will take on, which the business will continue to execute, and which will be shared. Work in that order and the arguments resolve themselves.
Then hold the line on the part that stays yours regardless. Businesses outsourcing IT should maintain full control of access to their systems and maintain awareness of vendor access by setting clear policies agreed to by the vendor.
Send the finished matrix to your provider and ask it to confirm in writing. Agreement in a meeting is a memory. Agreement in an email is a record, and it is the document you will want the next time something turns out to have been nobody's job.
FAQ
What is a shared responsibility model for an MSP?
A shared responsibility model is a written split of duties between a business and its IT provider. CISA describes it as articulating the vendor's responsibilities, the customer's responsibilities, and any responsibilities shared by both parties, and suggests using it to frame decisions such as which entity applies patches, maintains hardware, or trains employees. One page listing each task against a single named owner is enough.
Which IT tasks most often end up unassigned?
Third-party application patching, firmware updates, restore testing, out-of-hours alert triage, departmental SaaS and non-human identities such as service accounts. They share a shape: each is small enough that nobody escalates it, and each sits close enough to the boundary that both sides assume the other has it. Removing access for leavers is a close runner-up, because HR and IT learn about departures at different times.
Should you ask your MSP what it does not do?
Yes, and ask for it in writing. The joint advisory from CISA and six partner cyber authorities tells providers to give clear explanations of the services a customer is purchasing, the services the customer is not purchasing, and all contingencies for incident response and recovery. A written list of exclusions is the fastest way to find the gap, and a provider that will not produce one has told you something useful.
Does outsourcing IT transfer the risk to the provider?
No. CISA is explicit that outsourcing IT management does not absolve an organisation of risk management responsibility for it, and warns that ceding more responsibility to a provider may increase cost-efficiency while also increasing risk exposure and reducing your visibility across the estate. Contractual liability and operational risk are different things, and only the first one moves.
Who should own service accounts and API keys?
A named person on your side, with an expiry date and a review schedule, even when the provider created them. IBM reports that fewer than half of organisations secure non-human identities such as service accounts and automation credentials. These accounts never trigger a leaver process because nobody leaves, so they accumulate quietly and survive staff changes on both sides of the relationship.
Sources
- CISA, NSA, FBI, NCSC-UK, ACSC, CCCS and NZ NCSC, Joint Cybersecurity Advisory AA22-131A, Protecting Against Cyber Threats to Managed Service Providers and their Customers (11 May 2022)
- CISA Insights, Risk Considerations for Managed Service Provider Customers (2 September 2021)
- IBM and Ponemon Institute, Cost of a Data Breach Report 2026
- Verizon, 2026 Data Breach Investigations Report, 19th edition (news release, 19 May 2026)
Best IT MSP is an independent directory of managed IT providers across the US and Canada. We rank on verified rating and firmographic data, we label paid placement, and we do not sell IT services.