Near miss reporting: no longer mandatory.
Near misses do not have to be reported under the Cyber Security and Resilience Bill (CSRB). Government amendments at Lords Report Stage on 26 October 2026 limited incidents to events with an actual adverse effect, and removed near-miss reporting for data centres. A voluntary mechanism has been promised instead. The Bill is not yet law.
Last updated Status: not yet law. The Commons considers the Lords amendments on 24 November 2026.Sources: UK Parliament · HL Bill 62 · NIS Regulations 2018What is a near miss in cyber security?
An event that could have caused serious harm, but was prevented or did not materialise.
A near miss in cyber security is an event that could have compromised the availability, authenticity, integrity or confidentiality of data, systems or services, but was successfully prevented or did not materialise. Unlike a full cyber incident, no actual disruption, data loss or breach of service occurred - but the potential for serious harm was present.
Examples include a phishing email that reached an employee but was reported before credentials were entered, a vulnerability scan that detected an exploitable weakness before it was exploited, or a DDoS attack that was absorbed by mitigation controls before service was affected.
Near miss vs incident: the key distinction
An event where no actual compromise occurred. No loss of data availability, confidentiality or integrity - but there was a realistic potential for significant harm if the event had not been detected or mitigated.
An event that has actually affected or is affecting the security or operation of network and information systems. Service was disrupted, data was compromised, or the integrity of systems was breached.
HL Bill 32 widened the definition of an incident to events "capable of having" an adverse effect, and made data centres report incidents that "could have had" a significant impact. Government amendments on 26 October 2026 removed both. In HL Bill 62, an incident must have an actual adverse effect on the operation or security of systems (clause 15, new regulations 11, 11A, 12A and 14E). The Bill passed the Lords on 2 November 2026 and returns to the Commons, so it is not yet law.
The same tests would apply to operators of essential services, digital service providers and relevant managed service providers. To see which body you would report to, read which regulator covers you; for how this differs from today's rules, see the NIS Regulations vs the Bill. The full text is in our clause-by-clause guide, and the term is defined in our near miss glossary entry.
A voluntary route, not a legal duty.
"Instead of mandating near-miss reporting, I commit to establishing a voluntary near-miss reporting mechanism for all regulated entities under this framework." Baroness Lloyd of Effra, Lords Report Stage, 26 October 2026 (HL Deb 26 October 2026, via TheyWorkForYou). The mechanism needs no primary legislation and has not been set up yet.
The line that matters now is whether a system was actually affected. Unauthorised access that stole nothing still affected security, so it can be a reportable incident. A DDoS absorbed before it touched your service is a near miss. You need detection good enough to tell the two apart within hours.
Is it reportable? HL Bill 32 vs HL Bill 62.
Our reading of how common events are treated, before and after the Report Stage amendments. Real cases depend on the facts and regulator guidance.
| Event | HL Bill 32 (June 2026) | HL Bill 62 (current) |
|---|---|---|
| Attack blocked at the perimeter, no effect on any system | An "incident" under the wider definition, but outside the reporting tests for OES, RDSPs and RMSPs. Data centres had to report if it could have had a significant impact. | Not an incident. Not reportable. Log it, and share it through the voluntary mechanism once it exists. |
| Attacker gains a foothold but is contained before any disruption | Reportable if the impact was or was likely to be significant. | Still an incident, because security was actually affected. Reportable if the impact is or is likely to be significant. |
| Data centre cooling attack stopped just before an outage | Reportable to Ofcom under the "could have had" test. | Reportable only if it has had, is having or is likely to have a significant impact. |
| Ransomware encrypts production systems | Reportable: 24-hour initial and 72-hour full notification. | Reportable: 24-hour initial and 72-hour full notification. |
You can’t report what you don’t detect.
Near misses are no longer mandatory, but the 24-hour clock still starts when you become aware of an incident. If an attacker is already inside, you need to know quickly, decide whether the impact is significant, and notify on time.
- 24/7 Managed Detection: Eyes on glass, round the clock.
- Log Retention & Analysis: Automated correlation to spot usage anomalies.
- Incident Reporting Support: We draft your regulator reports for you.
Analysis: Attempted SQL Injection from known malicious IP.
Outcome: WAF Blocked. IP Blacklisted.
Generate Compliance ReportNear miss questions answered.
Not any more. The Bill as brought from the Commons (HL Bill 32) widened the definition of an incident to events 'capable of having' an adverse effect, and required data centres to report incidents that 'could have had' a significant impact. Government amendments at Lords Report Stage on 26 October 2026 removed both. In HL Bill 62, an incident must have an actual adverse effect, and there is no mandatory near-miss reporting.
At Report Stage the minister, Baroness Lloyd of Effra, said the Bill 'now makes it clear that an incident is an event which has had an actual adverse impact on the security and operations of an entity's systems'. She committed to a voluntary near-miss reporting mechanism for all regulated entities, to be set up without primary legislation. It does not exist yet.
No. A near miss is an event that could have caused harm but did not affect your systems, such as a blocked attack or a phishing email reported before anyone clicked. An incident has an actual adverse effect on the operation or security of network and information systems. Only incidents can be reportable under the Bill, and only when the impact is or is likely to be significant.
It depends on how far it got. If the attacker never affected a system, it is a near miss and not reportable. If they gained access, even briefly, security was actually affected, so it is an incident. It must then be reported within 24 hours if its impact is or is likely to be significant. The minister said ransomware and pre-positioning attacks that compromised a system remain covered.
A near miss in data protection is an event where personal data could have been exposed but was not, such as an email caught before sending to the wrong recipient. UK GDPR only requires reporting of actual personal data breaches that pose a risk to individuals, so near misses are not reportable to the Information Commission (the ICO until 30 September 2026). Many organisations still log them internally to learn from them.
Yes. A near-miss log shows regulators and auditors that your detection works, helps you spot patterns, and prepares you for the voluntary mechanism the Government has promised. It also helps you decide quickly when an event crosses the line into a reportable incident. It is good practice, not a legal duty under the Bill.
Guides on this topic.
All guidesNear-miss log template for cyber security
An unofficial near-miss log template with sample entries, what to record and how to run it, now that near misses are not reportable under the Bill.
Read the guideWhat Parliament has changed in the Cyber Security and Resilience Bill so far
Every Lords change to the Cyber Security and Resilience Bill, with an amendment-by-amendment ping-pong tracker for the Commons stage.
Read the guideAre you ready for 24-hour reporting?
Take our free readiness assessment to see whether your detection and incident response can meet the Cyber Security and Resilience Bill (CSRB) reporting deadlines.