Who is liable when an MSP's client is breached?

The short version

There is no single answer. When an MSP's customer is breached, responsibility can sit with the MSP, the customer or both, depending on what caused the breach, what the contract says and which laws apply. The Cyber Security and Resilience Bill (CSRB) adds direct regulatory duties for in-scope MSPs, but it doesn't decide who pays whom.

This guide is general information, not legal advice. After a real incident, get a solicitor involved early, ideally before anyone discusses fault in writing.

Four separate kinds of liability

People often treat "liability" as one question. It is at least four:

Type	Question	Who usually decides
Regulatory under the Bill	Did a regulated organisation meet its own duties?	Regulator, with appeal to the First-tier Tribunal
Data protection	Did the controller or processor meet UK GDPR duties?	Information Commission and courts
Contractual	Did a party breach the contract, and what do the liability terms allow?	Negotiation, arbitration or courts
Other civil claims	Does someone have a negligence or data protection claim?	Courts

One breach can trigger all four, with different answers.

Regulatory liability under the Bill

A relevant managed service provider (RMSP) answers for its own duties. Those include:

• managing risks to systems it relies on to provide managed services
• notifying qualifying incidents
• notifying UK customers likely to be adversely affected

Penalties apply to failures of those duties. The Bill's text doesn't make an MSP liable for every customer's breach, and it doesn't make the customer's duties disappear because a supplier was involved.

An operator of essential services (OES) with an MSP still has its own security duty. Using an MSP doesn't hand off that responsibility.

An incident report must also say if it was caused by a separate incident at another regulated person. That means a regulator may see both sides of the same event.

Data protection liability

If an MSP handles personal data for a customer, it is typically a processor and the customer the controller. Roles can differ, so check each service.

Under UK GDPR:

• Controllers answer for overall compliance, including notifying the regulator where required.
• Processors have their own duties, including security and telling the controller about a breach without undue delay.
• Both can be liable to people who suffer damage, with limits for processors who followed instructions and their processor duties.

This isn't theoretical. In March 2025 the ICO fined Advanced Computer Software Group £3.07 million as a processor, after a ransomware attack affected NHS and care services.

Contractual liability

For most commercial disputes, the contract matters most. Look at:

• Scope. Exactly which systems and controls did the MSP take on?
• Security obligations. Are they specific, or just "reasonable"?
• Liability caps and exclusions. Do data loss or regulatory costs have separate treatment?
• Indemnities. Does either party cover the other's losses?
• Notification. How fast must each side tell the other?
• Customer responsibilities. Did the customer have to approve patches, or fund upgrades?

Caps and exclusions are not always enforceable. The Unfair Contract Terms Act 1977 can apply, particularly to standard terms, so this is a point for your solicitor.

Regulatory fines raise further issues. Whether a fine can be recovered from another party or insured against is uncertain, so take advice instead of assuming.

Common scenarios

These illustrate the questions to ask. They aren't legal conclusions, because outcomes depend on the facts and contract.

Scenario	Likely questions
Attacker enters through the MSP's remote management tool	Did the MSP secure its tool? Did it notify on time? Does the contract cap its liability?
Customer declines a recommended upgrade, then is breached through it	Was the risk documented and accepted? Which party owned the decision?
Customer's employee is phished, and no MSP system is involved	Did the service include email security or monitoring? Did the MSP miss alerts it was paid to act on?
Monitoring service misses an alert	What did the service promise? What standard applies?
The MSP's own supplier is compromised	Who was responsible for that supplier? Could the supplier be designated as critical?

For MSPs: reduce your exposure now

• Define responsibilities in a matrix. Show who owns patching, backups, identity and monitoring for each customer.
• Record customer risk decisions. Keep written acceptance when a customer declines advice.
• Review caps and indemnities. Consider the new regime and take legal advice.
• Check your insurance. Ask what it covers, including regulatory investigations.
• Practise customer notifications. The duty applies after your full notification to the regulator.
• Preserve evidence. Logs often decide these disputes.

For customers: check your MSP arrangements

• Ask whether your MSP expects to be an RMSP, and why.
• Confirm in the contract who does what.
• Set notification timings that let you meet your own deadlines.
• Secure rights to logs and forensic evidence.
• Check whether your own insurance covers supplier-caused losses.

The managed security services contract guide lists clauses to review.

After an incident

1. Start your incident process and preserve evidence.
2. Check your own reporting deadlines first. They won't wait for a liability discussion.
3. Bring in legal counsel early, including to advise on how legal privilege applies.
4. Notify your insurer in line with your policy.
5. Keep communications factual. Avoid admissions or blame until you have the facts.
6. Review the contract notice clauses, as some claims must be raised within set periods.

Sources

• The Bill as brought from the Commons, HL Bill 32: sections 9, 10, 15 and 16
• ICO: guidance on personal data breaches
• NCSC and international partners: protecting against cyber threats to MSPs and their customers
• Freeths: ICO fines software services provider £3.07 million
• Unfair Contract Terms Act 1977