Breach vs incident vs near miss: what to report and to whom

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 short version

A cyber incident is an event that affects, or could affect, your systems. A personal data breach is a security failure affecting personal data. A near miss is an informal term for something that could have caused harm but didn't. Under the Cyber Security and Resilience Bill (CSRB), what you report depends on the legal test, not the label.

One event can be all, some or none of these, so assess each regime separately.

The decision table

	Cyber incident (the Bill)	Personal data breach (UK GDPR)	Near miss
What it means	An event having, or capable of having, an adverse effect on the operation or security of systems	A security breach leading to loss, alteration, unauthorised disclosure of or access to personal data	No statutory definition in the Bill
Report if	It meets your category's significance test	It's likely to result in a risk to people's rights and freedoms	Only if it meets one of the other tests
Report to	Your regulator, with a copy to the CSIRT	The Information Commission	Internally, unless another test is met
Deadline	24 hours for initial notice; 72 hours for full notice, both from first awareness	Without undue delay and, where feasible, within 72 hours of becoming aware	Set by your own policy
Tell others?	Data centres, RDSPs and RMSPs notify affected UK customers	Tell affected people if the risk to them is high	Consider your customer contracts
Keep a record?	Keep your assessment, as good practice	Yes, record all breaches, whether reported or not	Yes, as good practice

The Bill's duties are not in force yet. UK GDPR already applies.

Is a near miss reportable under the Bill?

The label won't tell you. The Bill's text does change the definition of "incident" to include events "capable of having" an adverse effect, but each category then has its own reporting test:

• Data centres (regulation 11A): the test covers incidents which "could have had" a significant impact, as well as those that have or are likely to. This is the widest test, so more near misses are likely to be reportable.
• OES, RDSPs and RMSPs (regulations 11, 12A and 14E): the incident must have affected or be affecting the operation or security of the relevant systems, and its UK impact must have been, be or be likely to be significant.

Under the second test, a phishing email blocked at the gateway is unlikely to qualify, as it had no effect on your systems. An attacker who got in and was contained before causing disruption needs a closer look: security has been affected, so the question becomes whether the impact was or is likely to be significant.

This is our reading of the text, not regulator guidance. Guidance may change it, so when unsure, escalate early and record why you decided as you did. Our significant incident guide sets out the factors.

Worked examples

These are examples rather than rulings. Your facts could change the answer.

Event	Bill: reportable?	UK GDPR: reportable?
Phishing email blocked, nobody clicks	Unlikely	No personal data affected
Laptop with encrypted data lost, strong encryption confirmed	Depends on the wider effect, probably not	Assess risk, likely low; record it
Email with customer data sent to the wrong person	Usually not a systems issue	Assess risk; may be reportable
Attacker uses stolen admin credentials, contained within an hour	Possibly, assess significance	Depends on data access; assess it
Ransomware stops a managed service for many customers	Likely	Likely if personal data was affected, including loss of availability
Data centre cooling attack stopped just before an outage	Possibly, under the "could have had" test	Not unless personal data was affected
Misconfigured storage found internally, logs show no access	Assess it	Assess it, and record your finding

A single process for all three

Your team shouldn't have to decide which regime applies before raising the alarm. Use one route:

1. Log it. Record the time, who found it and what's known.
2. Triage it. A trained person checks whether systems or personal data were affected.
3. Run each test separately. Use one column for the Bill and one for UK GDPR. Add others that apply, such as customer contract terms or FCA rules.
4. Start the clocks. Note when you first became aware, for each regime.
5. Decide and record. Write down the decision, the reasoning and who made it.
6. Notify. Use your 24-hour notification template.
7. Learn. Feed near misses into your risk register and controls.

Common mistakes

Assuming one report covers everything. A notice under the Bill doesn't replace a UK GDPR notification, even though both may go to the Information Commission. Treat them as separate.

Waiting for certainty. The Bill's initial notice only needs brief details, and the full notice covers information "so far as known". UK GDPR also allows information to follow in phases.

Treating all near misses as reportable. Over-reporting takes up time and doesn't help regulators. Assess against the right test.

Treating all near misses as irrelevant. They reveal which controls worked by luck rather than design. A near-miss log makes that visible.

Telling staff never to report small things. Internal reporting should have a low threshold. The legal test applies later in the process.

Sources

• ICO: personal data breaches
• ICO: 72 hours, how to respond to a personal data breach
• The Bill as brought from the Commons, HL Bill 32: sections 15 and 16
• NIS Regulations 2018