CSRB Incident Reporting for MSPs: The 24-Hour and 72-Hour Rules Explained

For MSPs following the Cyber Security and Resilience Bill (CSRB), one obligation stands out as the most concrete and operationally demanding: the 24-hour and 72-hour incident reporting rule. Unlike some of the Bill's broader governance requirements, this one has a clear structure, a hard clock, and a very real risk of getting it wrong under pressure. If you are a Relevant Managed Service Provider (RMSP) once the relevant provisions commence, this is the duty you are most likely to trigger first, and the one with the least room for improvisation.

This article explains what the two-stage reporting process actually requires, who needs to be told, why it is uniquely difficult for MSPs specifically, and what a defensible reporting workflow needs to include before an incident happens rather than during one.

What the CSRB Actually Changes

The CSRB amends and expands the existing Network and Information Systems (NIS) Regulations 2018 rather than replacing them outright. Its most significant change for the managed services sector is the creation of a new regulated category: the Relevant Managed Service Provider (RMSP). Per the GOV.UK "Relevant managed service providers" factsheet (last updated 30 June 2026), an RMSP is an entity providing ongoing management of a customer's IT systems under contract, including support, maintenance, monitoring, or active administration, whether delivered on-premises or remotely.

Medium and large MSPs providing UK managed services fall into scope. Small and micro enterprises are exempt, as are certain public authority bodies. Pure data centre services, public electronic communications networks and services, and pure operational-technology management without IT management are excluded from the RMSP definition specifically, though data centres get their own separate regulated category based on Rated IT Load.

Once relevant provisions commence, in-scope RMSPs will have three months to register with the Information Commission, the regulator under the Bill. Importantly, security duties apply from commencement, not from the point of registration, so the incident-reporting clock does not wait for paperwork.

The Two-Stage Reporting Process

The incident reporting regime under the Bill follows a two-stage structure that is consistent across industry commentary, even though it is not yet set out on a single dedicated primary-source page in the way the RMSP definition is:

Stage One: Initial Notification Within 24 Hours

Once an RMSP becomes aware of a significant incident, it must submit an initial notification within 24 hours. This notification goes to both the regulator (the Information Commission) and the National Cyber Security Centre (NCSC) or the relevant Computer Security Incident Response Team (CSIRT). The 24-hour window is not 24 hours from when the incident started; it runs from the point the MSP becomes aware of it, which puts a premium on detection speed as much as reporting speed.

Stage Two: Fuller Report Within 72 Hours

A more detailed report follows within 72 hours of becoming aware of the incident. This is where the MSP is expected to provide a fuller account: what happened, what systems and data were affected, the assessed severity, and the steps taken or planned to contain and remediate the incident.

Note what is still missing from public guidance: the exact definition of a "significant incident" that triggers this obligation, and the exact size or turnover thresholds distinguishing in-scope from exempt organisations, are both left to secondary legislation that has not yet been published. Any MSP building a reporting workflow today has to design around a threshold that will be defined later, which is its own planning challenge.

The Customer Notification Duty

Regulatory notification is only half of the obligation. Where customers are likely to be adversely affected by a significant incident, they must be told "as soon as reasonably practicable." This is a separate duty from the regulator/NCSC notification and runs on its own clock, driven by materiality to the customer rather than a fixed number of hours.

For an MSP, this is where the obligation becomes multiplicative rather than singular, and it is worth examining why.

Why This Is Operationally Hard for MSPs Specifically

A single business suffering a security incident generally has one regulator relationship and one set of stakeholders to manage. An MSP is structurally different: it holds concentrated access across many client environments simultaneously, often with privileged credentials, remote monitoring agents, and administrative tooling that spans dozens or hundreds of separate organisations.

That means one incident on the MSP's own infrastructure, or one compromised credential, can create a cascade of separate customer-notification obligations, each running on its own "as soon as reasonably practicable" clock, potentially all triggered from the same root cause. Industry commentary on the Bill (not primary-source-verified, but consistent across multiple sources) flags privileged access management as a likely major regulatory focus area for exactly this reason, and specifically highlights this "one incident, many notifications" risk as a distinguishing feature of MSP exposure compared with single-organisation obligations under the same regime.

In practice, this means an MSP's incident response plan cannot just answer "did this happen to us." It has to answer, quickly, "which of our clients does this affect, to what degree, and what does each of them need to be told, and by when." Doing that under a 24-hour regulatory clock while also running technical containment is where reporting workflows built during a crisis tend to fail.

What a Defensible Reporting Workflow Needs

Given the compressed timeline and the multiplied notification surface, a workflow assembled after an incident starts is rarely fast enough. A defensible process, one that can actually meet the 24 and 72-hour windows and demonstrate that to a regulator afterwards, needs to be built in advance and needs at minimum:

• A declaration threshold — a documented, pre-agreed internal definition of what counts as a reportable incident for your organisation, so staff are not debating severity classification while the clock is already running.
• A named decision owner — a specific person (not "the team" or "whoever is on call") with the authority to declare an incident reportable and trigger the notification sequence, with a named deputy for cover.
• An evidence log — a running, timestamped record of what was known and when, which is what actually demonstrates to a regulator that your 24-hour and 72-hour deadlines were met, and from what point they were calculated.
• Pre-built templates — for the initial 24-hour notification, the fuller 72-hour report, and client-facing notifications, so the content is being filled in under pressure, not drafted from scratch.
• An escalation path — a clear internal chain covering who is told, in what order, and at what point client-facing communications are authorised to go out, particularly given that multiple clients may need different messages depending on how they were individually affected.

None of this needs to wait for the secondary legislation that will define exact "significant incident" thresholds. The structure above, a threshold, an owner, a log, templates, and an escalation path, is what makes any threshold usable once it is confirmed, and it is what turns a regulatory deadline from a scramble into a checklist.

Building This Before You Need It

MSPs that wait until an actual incident to work out declaration thresholds, ownership, and client notification sequencing are working against the clock twice: once technically, and once procedurally. Secordit Intelligence's CSRB-RESPOND Incident Response Pack (£247) is built specifically around this two-stage reporting structure, providing 24/72-hour incident reporting templates, a notification decision tree for working through client-impact scenarios, and a tabletop exercise pack for testing the workflow before it is needed for real.

If you are still working out where your organisation stands more broadly, whether you are likely to fall into the RMSP category at all, and what your wider compliance gaps might look like, the free Product Selector quiz or the MSP Briefing are useful starting points before going deeper into a specific workflow like incident reporting.

Where This Stands in the Legislative Timeline

For context, the CSRB had its First Reading in the Commons on 12 November 2025, Second Reading on 6 January 2026, and Committee stage began 3 February 2026. The Bill was reintroduced in the Commons on 14 May 2026 as part of the carry-over from the 2024-26 session into 2026-27, with Report stage and Third Reading both on 16 June 2026, and First Reading in the Lords on 17 June 2026. Second Reading in the Lords is currently scheduled for 14 July 2026, though Parliament's own bill-stages page notes that dates more than a week out may be provisional. The Bill is now numbered HL Bill 32 of session 2026-27. Trackers suggest Royal Assent is expected sometime in 2026, though phased commencement could extend implementation into 2028; this has not been confirmed by a primary source.

Given that timeline, the exact commencement date, and therefore the exact date the three-month registration window and ongoing security duties start, is not yet fixed. That is precisely why building the reporting workflow now, ahead of a confirmed deadline, is lower-risk than waiting for secondary legislation to force the issue.

Secordit Intelligence products are operational intelligence and compliance readiness materials. They do not constitute legal advice and do not guarantee regulatory outcomes.

Last reviewed: 1 July 2026

Matthew Protheroe-Hill, Founder, Secordit Intelligence