MSP Incident Reporting Under the Cyber Security & Resilience Bill
CSRB Incident Reporting for MSPs: What the 24-Hour Obligation Means in Practice
The Cyber Security & Resilience Bill introduces a mandatory 24-hour incident reporting obligation for UK Managed Service Providers classified as Relevant Managed Service Providers. This is not a best-practice recommendation — it is a statutory requirement with fines of up to £17 million for non-compliance. If an incident occurs and your MSP cannot demonstrate that you detected, assessed, and notified the ICO within 24 hours, you are exposed.
This page explains what the obligation requires, what evidence the regulator will expect, and what a compliant response process looks like. If you are looking for the operational tools to implement one, the CSRB-RESPOND kit is available on our product page.
What the Cyber Security & Resilience Bill Requires from MSPs
The CSRB extends the Network and Information Systems (NIS) Regulations 2018 to formally include Managed Service Providers as Relevant Managed Service Providers — a new classification that places MSPs under the same incident reporting obligations currently applied to operators of essential services in energy, transport, and health.
Under the Bill as currently progressing through Parliament, RMSPs will be required to:
– Notify the relevant competent authority — expected to be the ICO for most MSPs — within 24 hours of becoming aware of a significant incident
– Submit a full incident report with root cause analysis within 72 hours
– Maintain documented evidence of the notification process, timeline, and actions taken
– Demonstrate that a tested incident response process exists prior to any incident occurring
The Bill completed Committee Stage on 25 February 2026, ahead of schedule. The core incident reporting framework is no longer subject to material change. Royal Assent is expected Q3–Q4 2026. Secondary legislation will confirm the precise thresholds for what constitutes a ‘significant incident’ requiring notification.
The 24-Hour Clock: What Triggers It and What It Demands
The 24-hour window does not begin at the moment an incident is confirmed. It begins when your MSP ‘becomes aware’ of a significant incident. That distinction matters: if a monitoring alert fires at 03:00 on a Saturday, awareness begins at 03:00 on a Saturday.
Within that 24-hour window your MSP must complete all of the following:
– Triage and classify the incident against defined severity criteria
– Assess whether the incident meets the threshold for regulatory notification
– Prepare and submit an initial notification to the ICO containing the required information
– Begin the documented chain of custody that will form part of your 72-hour full report
The 72-hour full report must then contain root cause analysis, a timeline of events, the scope of affected systems and clients, containment actions taken, and a recovery plan. Both documents are regulatory submissions — they will be reviewed by ICO inspectors if the incident results in enforcement proceedings.
What Evidence Does the ICO Expect to See?
Regulatory inspectors under the NIS framework — the model the CSRB extends — assess not just whether you notified, but whether your organisation had a credible, documented process before the incident occurred. Improvised responses are treated as evidence of systemic non-compliance, regardless of outcome. See also our CSRB-BRIDGE gap analysis.
The evidence package the ICO is likely to request includes:
– A written incident response plan with defined roles, escalation triggers, and regulatory notification procedures
– Timestamped records of the incident timeline from detection to notification
– Completed triage and impact assessment documentation
– The initial 24-hour notification itself, with submission timestamp
– The 72-hour full report with root cause and containment evidence
– Records of prior tabletop exercises or drills demonstrating tested readiness
That final point — tested readiness — is one that most MSPs overlook entirely. An incident response plan that has never been exercised is not a credible plan in the eyes of a regulator. Documented tabletop exercises produce the evidence trail that demonstrates proactive compliance intent before any incident occurs.
Why Most MSP Incident Response Plans Are Not Enough
The majority of UK MSPs have some form of incident response documentation. Almost none of it was built around a 24-hour regulatory notification window. There are three specific gaps that appear consistently:
1. The timeline assumes days, not hours
Plans written for internal IT recovery tend to prioritise containment and remediation over regulatory notification. Under the CSRB, regulatory notification is not a step you get to once the technical situation is resolved — it is a parallel workstream that begins at the moment of awareness. Most existing plans do not have this separation documented.
2. The notification template does not exist
When an incident occurs, your team should not be writing the ICO notification from scratch under time pressure. The content of the notification — what it must contain, in what format, to whom it is addressed — should be pre-prepared and require only factual completion at the time of incident. Most MSPs do not have this document.
3. No one has practised the process
A plan that exists only as a PDF is not a tested process. The CSRB’s enforcement model is based on the NIS framework, which already expects operators to conduct regular exercises. An MSP that cannot produce records of prior tabletop exercises is at a disadvantage in any regulatory review.
How to Build a Compliant 24/72-Hour Response Process
Building a CSRB-compliant incident response capability requires three things: operational documentation that covers the full T+0 to T+72 timeline, a pre-built notification template that your team can complete under pressure, and a tested process evidenced by at least one structured exercise.
The minimum viable documentation set for CSRB compliance is:
– A severity matrix that defines what constitutes a notifiable incident and who makes that determination
– A triage and impact assessment template, completed at T+0 to T+4
– A containment record documenting actions taken during the incident
– A pre-formatted ICO notification template, ready to complete and submit by T+24
– A client communication template for affected parties
– A full incident report template for the T+72 submission
– A post-incident review framework for lessons learned documentation
– A command tracker that auto-calculates your T+24 and T+72 deadlines from the detection timestamp
That is eight documents. Each one serves a dual purpose: it guides your team during the incident, and it produces a regulatory-ready evidence artefact as a by-product of its completion.
Frequently Asked Questions
Does the 24-hour obligation apply to every incident?
No. The obligation applies to incidents that meet the threshold for a ‘significant incident’ under the Bill. The exact thresholds will be confirmed in secondary legislation after Royal Assent. Indicators likely to be included are: disruption to service availability above a defined threshold, compromise of client data, and incidents affecting critical national infrastructure clients. The severity matrix in a compliant incident response plan should capture these thresholds and make the notification decision a documented one, not a judgement call made under pressure.
We already have a cyber insurance policy that includes incident response — is that enough?
Insurance-backed incident response typically prioritises business recovery and legal liability management. It does not produce the specific regulatory evidence documentation that the ICO will expect under the CSRB. The two are complementary, not interchangeable. Your insurer’s IR team will help you contain the incident; a CSRB-compliant process ensures you also satisfy your regulatory notification obligations within the required window. We can map your specific service architecture, client base, and operational controls against CSRB requirements within a 90min Pulse Audit with an Analyst.
What happens if we miss the 24-hour window?
Late notification is treated as a separate compliance failure from the underlying incident. Under the NIS enforcement model — which the CSRB mirrors — the ICO can issue enforcement notices and financial penalties for notification failures independently of any penalty arising from the incident itself. The maximum fine under the CSRB is £17 million or 4% of global turnover, whichever is higher. Regulators have discretion on quantum, but a documented failure to notify on time with no audit trail of a tested process is not a position you want to be defending.
How often should we test our incident response process?
The NCSC CAF v4.0 guidance — against which CSRB compliance will be assessed — recommends regular exercising of incident response processes without specifying a fixed frequency. Annual tabletop exercises are generally considered a minimum. For MSPs managing clients in regulated sectors, twice-yearly exercises with documented outcomes are a stronger position. The key requirement is that exercises are conducted, documented, and that the gap capture outputs feed back into plan updates. Our CSRB-WATCH will help you monitor changes as they happen.
Next Step: Get Your Incident Response Kit
CSRB-RESPOND is a three-tool kit built specifically for the CSRB’s 24-hour notification requirement. It contains all eight documents described above, a pre-built Excel command tracker that auto-calculates your regulatory deadlines from the detection timestamp, and a structured tabletop exercise guide for a supply chain ransomware scenario.
It is a one-time purchase, instant download, and is designed to be deployed on the day of purchase. Your team does not need compliance expertise to use it — every template is written in plain English for operational teams, not lawyers.
|
CSRB-RESPOND — Incident Response Kit | From £147 ex. VAT → |