Glossary · Duties and incidents

Near miss

Definition

A near miss is an event that could have caused harm but did not. The Cyber Security and Resilience Bill does not use the term, but it amends the NIS definition of incident to cover events "capable of having" an adverse effect. Only the data centre test expressly makes such events reportable.

Does the Bill require near miss reporting?

Partly. The word "near miss" does not appear in the Bill. What the Bill does is change the definition of incident so that an event "capable of having" an adverse effect is an incident. That brings stopped attacks into the category of incidents that security duties must address and that organisations should record.

Reporting is a separate step. Each group has its own significant incident test, and only the data centre test in regulation 11A(3) expressly captures incidents that "could have had" a significant impact without having one.

Where does near miss reporting actually bite?

For an operator of a data centre service, an event that could have had a significant impact on the systems, on continuity of the service, or otherwise in the UK is reportable, even if it was contained. The full notification must describe the impact the incident "could have had" (reg 11A(4)(e)).

For other operators of essential services, digital service providers and managed service providers, the incident must have "affected or is affecting" the operation or security of the relevant systems. The significance limb then asks whether impact has been, is or is "likely to be" significant. So an attacker who gained a foothold that was then contained may well be reportable, because the systems were affected and likely impact counts. A connection attempt blocked at the perimeter, with no effect on the systems, generally will not be.

What should organisations do now?

Treat the wider definition as a detection and record-keeping requirement. You cannot assess what you do not see, and a regulator can later ask how you classified events.

  • Log events capable of adverse effect, not only confirmed breaches.
  • Write down the significance test for your category and apply it consistently.
  • Be able to run the assessment inside 24 hours of first awareness.
  • Data centres should build a specific process for "could have had" events.

Common misconceptions

Myth: Every blocked attack must be reported within 24 hours.

Reality: Outside data centres, the systems must have been affected and the actual or likely impact must be significant. A blocked perimeter attempt with no effect on the systems will usually fail that test.

Myth: Near misses will get their own timetable in secondary legislation.

Reality: Reportable events follow the 24-hour and 72-hour clocks already set in regs 11(6), 11A(5), 12A(5) and 14E(5). No separate near miss timetable is proposed in the Bill.

Where it appears in the Bill

  • Cl.15(2)Adds "capable of having" to the incident definition.
  • New reg 11A(3)Data centre incidents include impact that "could have" occurred.
  • New reg 11A(4)(e)Full notification covers impact the incident could have had.
  • New regs 11(3), 12A(2), 14E(2)Require the systems to have been affected.

References are to HL Bill 32 as brought from the Commons. Read the Bill.

Frequently asked questions

Do managed service providers have to report near misses?

Only where the event passes the RMSP test in regulation 14E(2). The incident must have affected or be affecting the systems relied on to provide the managed service, and its actual or likely impact must be significant. A contained compromise of a remote management tool could qualify; an attempt blocked before touching the systems generally would not.

Why are data centres treated differently?

Regulation 11A(3) defines a data centre incident as one which "could have had, has had, is having or is likely to have" a significant impact. Unlike the tests for other groups, it does not require the systems to have been affected already. The Bill gives no reason in its text, but the effect is a broader duty for data centre operators.

Should we log events we decide not to report?

Yes. Regulators can use information notices and inspections to examine how incidents were identified and classified. A record of events capable of adverse effect, with the significance assessment and the reasons for not notifying, shows the test was applied properly and is far easier to produce than a reconstruction after the fact.

Related guidance

Official sources

More in Duties and incidents

Full glossary