MSPs' liability and risk under the CRA (Cyber Resilience Act)

MSPs are coming into scope under the new Cyber Resilience Bill which will make many MSPs legally accountable for security and resilience, including smaller providers that think they are “too small to matter.”

Disclaimers will not save you...

Relying on liability waivers in SLAs is risky...

If roles and responsibilities are vague, regulators and clients will still look to the MSP when things go wrong.

Risk ownership must be explicit.

The MSP runs the tech, but the client owns the business risk.

Who decides resilience levels, recovery times, and acceptable downtime must be documented and signed off by senior management. Documentation is your first line of defence.

You need

• evidence

• risk registers

• security forums

• minutes

• approvals

• decisions

• and rejected recommendations

“We told Fred months ago” is worthless if it is not written and traceable.

Core cyber services are now “must have”. Patching, monitoring, identity and access control, and incident response are no longer optional extras. Many MSPs are not contractually bound to do patching today. That gap will be unacceptable under CRA-style exceptions.

Supply chain risk will cascade. Third, fourth, and fifth parties can be pulled into scope, in a similar way that it us under DORA and NIS2. Even small niche vendors may suddenly face regulatory expectations because of their role in critical infrastruture and supply chains.

Incident response and escalation protocols need to be strong. You may have 4–72 hours to notify regulators and clients. That means you need clear escalation paths, board-level availability out of hours, and pre-agreed decision authority before the incident hits.

Cyber is a board issue, not “an IT problem”. CAF, ISO 27001, NIS2, DORA, and CRA all push cyber into mainstream governance. Risk language and reporting must be simple enough for finance and executives to understand and own. Standards and certification are becoming a necessity. Cyber Essentials, ISO 27001 and similar will be used by insurers and regulators as a baseline. MSPs that can show mapped controls across CRA, NIS2, DORA, and existing standards will win trust and deals.This is a commercial opportunity, not just a burden.

Clients will expect security and compliance as a service. MSPs who build repeatable security and compliance offerings (and sensible alliances) will gain stickier clients, higher recurring revenue, and push out weaker competitors.

Key Insights:

Regulation is shifting MSP security from “nice to have” to “you are on the hook.”

The real risk is not just cyber attacks. It is weak documentation, unclear risk ownership, and slow or clumsy incident handling.

CRA sits in the same ecosystem as NIS2, DORA, and CAF, so you should think in terms of a single, consistent control set, not a pile of unrelated checklists.

Actionable Recommendations for MSPsMap responsibilities:

• Build a simple RACI for security.

• Clarify who owns business risk versus who runs the controls.

• Bake it into contracts and a live risk register.

• Tighten SLAs + evidence.

• Update SLAs to reflect reality.

• Create security forums and sign-off trails so you can prove what the client accepted or declined.

• Industrialise patching and monitoring

• Treat patching, IAM, and incident response as standard services, not add-ons.

Price these services properly

• Build an incident playbook

• Define “who do we call, within how long, who decides what” in one short, accessible document.

• Test it.

• Use standards as a sales tool

• Align to Cyber Essentials and ISO 27001, and show how your controls support CRA, NIS2, and DORA.

Sell this as “compliance as a service.”

Single takeaway: If you are an MSP, treat the Cyber Resilience Bill as your best excuse to professionalise security, formalise risk ownership with clients, and turn ongoing compliance into paid, recurring revenue, recurring work.