What counts as a significant incident under the Cyber Security and Resilience Bill?
Under the Cyber Security and Resilience Bill (CSRB), most regulated organisations must report an incident that has affected the operation or security of their systems where the UK impact is, or is likely to be, significant. The Bill sets factors rather than numbers, and the text as drafted gives data centres a wider test.
The Bill is not yet law. Regulation and section references come from the Bill as brought from the Commons (HL Bill 32). The Lords has since amended the Bill, so numbering and detail may change in the final Act. This guide is general information, not legal advice.
Report Stage update: VinciWorks reports that Government amendments on 26 October 2026 narrowed the incident definition to incidents that have actually adversely affected systems, and removed mandatory near-miss reporting for data centre operators. We could not check this against the amended Bill, so the wording below reflects HL Bill 32 and may be out of date. See what Parliament changed.
The test has two parts
Under the Cyber Security and Resilience Bill (CSRB), the word "significant" is judged against listed factors, not a number. For most regulated organisations, both of these must be true:
- Effect: the incident has affected, or is affecting, the operation or security of the network and information systems relied on to provide the service.
- Impact: the impact in the UK, or any part of it, has been, is or is likely to be significant.
The Bill also widens the basic definition of "incident" to an event having, or capable of having, an adverse effect on the operation or security of systems. That wider definition does not remove the two-part test above.
How the test differs by category
| Category | Regulation | Test |
|---|---|---|
| Operator of essential services | 11 | Has affected or is affecting systems, and impact is or is likely to be significant |
| Relevant digital service provider | 12A | Same structure, with more factors |
| Relevant managed service provider | 14E | Same structure, with more factors |
| Data centre service | 11A | An incident that could have had, has had, is having or is likely to have a significant impact |
The data centre wording is the only one that says "could have had". That makes it the widest test in the Bill, and the closest to a true near-miss duty.
The factors
| Factor | OES | RDSP and RMSP |
|---|---|---|
| Extent of disruption to the service | Yes | Yes |
| Number of users affected | Yes | Yes |
| Duration | Yes | Yes |
| Geographical area | Yes | Yes |
| Whether users' data confidentiality, authenticity, integrity or availability is compromised | Yes | Yes |
| Impact on users' own network and information systems | No | Yes |
| Impact on the economy or day-to-day functioning of society | No | Yes |
Each factor includes actual and likely effects. So you should not wait for harm to appear if the effect is already likely.
For data centres, regulation 11A has no factor list. It looks at significant impact on the operation or security of the systems, the continuity of the data centre service, or any other significant impact in the UK.
Worked examples
These are our reading of the text, not regulator decisions. Real cases depend on the facts, and regulators may issue guidance.
| Scenario | Category | Likely position | Why |
|---|---|---|---|
| Ransomware stops a managed service for many customers for hours | RMSP | Report | Systems affected, with clear disruption and customer impact |
| Attacker uses an MSP's admin tool to reach customer systems, before any outage | RMSP | Likely report | Security affected, and customer systems are a listed factor |
| Phishing email blocked by the mail gateway | Any | Not reportable | No effect on operation or security |
| Stolen credentials used on one internal account, contained with no realistic route to services | RMSP | Judgement call; record your reasoning | Security affected, but significant impact may not be likely |
| Cooling failure caused by a cyber attack nearly takes a data centre offline, but is stopped in time | Data centre | Likely report | Could have had a significant impact on continuity |
| Same type of attack is stopped at a hospital's service provider, before affecting any system | OES | Probably not | The first part of the test is not met, though you should log it |
What this means for near misses
Be careful with broad statements that every near miss must be reported.
- Data centres: an event that could have had a significant impact is covered.
- Everyone else: the incident must have affected or be affecting operation or security. A compromise that has already happened, but has not yet caused harm, can qualify because the likely impact counts.
- Blocked attempts: an attack stopped with no effect on systems is unlikely to qualify outside data centres.
Internal logging is still worthwhile. A record of near misses and your decisions helps show that your security measures work, and regulators may clarify this area. See near-miss reporting for more on recording these events.
When the clock starts
The 24-hour and 72-hour periods both start when you are first aware that a reportable incident has occurred or is occurring. The text does not define the point of awareness in more detail.
It also isn't clear how a regulator will treat time spent investigating whether an event qualifies. A sensible approach, in our view, is to:
- Log when an event was first detected.
- Set a short internal target for deciding whether it is reportable.
- Record who decided, when and why.
- Treat a likely significant incident as reportable, rather than waiting for certainty.
The 24-hour runbook and template puts this into a timed process.
Build your own thresholds
The Bill doesn't set numbers, so set internal triggers now for your own services. For each factor, agree what would prompt an escalation, such as a set share of customers affected or a set length of outage. These are triggers for a decision, not legal thresholds. Review them when regulator guidance is published.
Sources
Frequently asked questions
The text does not set one. It lists factors such as disruption, users affected, duration, geographical area and data compromise. Regulator guidance or secondary legislation may add detail.
It depends on the category. For data centres the test includes incidents that could have had a significant impact. For other organisations, the incident must have affected or be affecting operation or security, and its impact must be or be likely to be significant. An attack blocked with no effect is unlikely to meet that second test, but record your reasoning. Reports say the Lords may have narrowed this at Report Stage, so check the final text.
It starts when the organisation is first aware that a reportable incident has occurred or is occurring. Both the 24-hour and 72-hour periods run from that same moment.
No. The two regimes have different tests. Data compromise is one factor under the Bill, while UK GDPR asks about risk to people’s rights and freedoms. One event can trigger both.