Incident reports under the Cyber Security and Resilience Bill and UK GDPR
One incident can trigger two separate reports. The Cyber Security and Resilience Bill (CSRB) asks about significant impact on a service and starts with a 24-hour notice, while UK GDPR asks about risk to people and gives 72 hours where feasible. Sending one report does not satisfy the other.
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.
The short version
The Cyber Security and Resilience Bill (CSRB) and UK GDPR ask different questions about the same event. The Bill asks whether your service or systems were significantly affected. UK GDPR asks whether personal data was breached and whether people are at risk. If the answer to both is yes, you make two separate reports.
Neither report replaces the other. Build one incident process that can feed both.
How the two regimes compare
| Cyber Security and Resilience Bill | UK GDPR | |
|---|---|---|
| Trigger | An incident with a significant impact, or likely significant impact, on a regulated service | A personal data breach, unless it is unlikely to pose a risk to people's rights and freedoms |
| First deadline | 24 hours from first being aware of the reportable incident | 72 hours from becoming aware, where feasible |
| Second deadline | Full report within 72 hours of the same starting point | Further information in phases, without undue further delay |
| Who you tell | Your regulator, with a copy to the CSIRT at the same time | The ICO |
| Who else | Affected UK customers, for data centres, RDSPs and RMSPs, as soon as reasonably practicable after the full report | Affected people, without undue delay, if the risk to them is high |
| Records | Keep your own record of decisions, because you may need to justify them | All breaches must be documented, whether reported or not |
Four situations you should plan for
A ransomware attack takes down a managed service and exposes customer staff data. This is likely to engage both regimes. An RMSP would notify the Information Commission and the CSIRT under the Bill. The processor would also tell each affected controller without undue delay, and each controller then decides whether it must notify the ICO.
An outage with no personal data involved. This could be reportable under the Bill if the impact is significant, with nothing to report under UK GDPR.
A staff member emails a spreadsheet of customer details to the wrong person. This may be a UK GDPR breach, depending on the risk. It is unlikely to be a significant incident under the Bill, because the operation of the service was not affected at any meaningful scale. Record your reasoning.
An attacker is blocked before anything happens. Probably neither, though data centres should look carefully at the wider test in our significant incident guide.
Where the processes collide
The clocks start at different points. Under the Bill, the clock starts when you are first aware that a reportable incident has occurred or is occurring. Under UK GDPR, it starts when you become aware of the breach. Those moments can be hours or days apart, so log each one separately.
The 24-hour notice comes first. Sending it does not stop or start the UK GDPR clock. If personal data may be involved, start the UK GDPR assessment at the same time.
Your role can differ. You might be a controller for your own staff data and a processor for customer data. A processor must tell its controller without undue delay and needs a contract that sets out how. Check that those contract terms still work alongside customer notice duties under the Bill.
The same regulator may receive both. For RDSPs and RMSPs, the Information Commission receives Bill notifications, and data protection reports also go to the same body. Do not assume one submission counts as both. The Bill's notices must be given in the form and manner the regulator sets, and we have not found published forms yet.
Messages must be consistent. The regulator, the CSIRT, customers and affected people may all compare what you told them. Use one fact log as the source for every message, and be clear about what is confirmed and what is still unknown.
What to put in your incident plan
- Add two separate decision points: "Is this reportable under the Bill?" and "Is this a personal data breach?"
- Name who makes each decision and a deputy for out-of-hours incidents.
- Record four timestamps: first detection, Bill awareness, UK GDPR awareness and each notification sent.
- Bring your data protection lead into the incident call from the start.
- Prepare templates for both regimes. Start with our 24-hour notification template.
- Check processor and customer contracts against both sets of duties.
- Rehearse a scenario that triggers both regimes, including out of hours.
Sources
Frequently asked questions
Yes, if the incident meets both tests. The Bill covers significant incidents affecting regulated services, and UK GDPR covers personal data breaches that pose a risk to people. These are separate duties.
Usually the 24-hour initial notice under the Bill, though the two clocks can start at different moments. Track awareness for each regime separately.
Under UK GDPR, a processor must tell its controller without undue delay. The controller normally decides whether to notify the ICO. A processor that is also an RMSP has its own separate duties under the Bill.
For RDSPs and RMSPs, Bill notifications go to the Information Commission. Do not assume one submission covers both regimes, and use whichever forms each process requires.