Customer notification under the Cyber Security and Resilience Bill: guide and template
Under the Cyber Security and Resilience Bill (CSRB), data centres, RDSPs and RMSPs must notify UK customers likely to be adversely affected by a reportable incident, as soon as reasonably practicable after the full notification. The notice must explain the incident and why that customer is affected.
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 duty
Under the Cyber Security and Resilience Bill (CSRB), three kinds of provider have a separate duty to tell customers about reportable incidents.
| Provider | Provision in HL Bill 32 | Trigger |
|---|---|---|
| Data centre operator | Reg 11C | After full notification to Ofcom |
| RDSP | Reg 12C | After full notification to the Information Commission |
| RMSP | Reg 14G | After full notification to the Information Commission |
The process has two steps, and both must happen as soon as reasonably practicable:
- Take reasonable steps to establish which UK customers are likely to be adversely affected.
- After those steps, notify them.
This may have changed. One secondary source reports that Lords amendments at Report Stage also require providers to keep affected customers updated. We have not confirmed this. Plan to send updates anyway, as customers will expect them. See what Parliament has changed.
Working out who is affected
The Bill requires you to take account of:
- The extent of actual or likely disruption to the service you provide to that customer
- Whether the confidentiality, authenticity, integrity or availability of data relating to that customer is likely to be compromised
- Any other impact on that customer's network and information systems
An MSP compromise is the hard case, because a shared tool can reach many customers. You should be able to answer quickly:
- Which customers use the affected tool, tenant or site?
- Which accounts had access, and to which customer environments?
- What logs exist to show what was actually accessed?
If you cannot rule a customer out, record your reasoning and decide whether to include them. Over-notifying has costs as well, so aim for a defensible decision.
What the notice must say
It must:
- Provide details of the nature of the incident
- Explain why you consider the customer likely to be adversely affected
A generic "we had an incident" message does not do the second part. The government's factsheet explains that the purpose is to help customers take steps to mitigate harm, so practical advice is useful too.
Template (unofficial)
This is not an official form. Adapt it with legal input, and do not include details that could harm the response.
Subject: Security incident affecting [service]: action may be required
We are writing to tell you about a security incident affecting [service], which we have reported to [regulator].
What happened: [Plain-English description of the nature of the incident, known to date.]
When: We became aware on [date, time, time zone]. The incident [is ongoing / was contained at time, date].
Why this affects you: We consider your organisation likely to be adversely affected because [specific reason, such as use of affected tool, disruption to named service, or possible access to named data].
What we are doing: [Containment and investigation steps.]
What you should do: [Specific actions, such as rotating credentials, reviewing logs for named indicators, or using a workaround.]
What we do not know yet: [Open questions.]
Next update: We will update you by [time, date], or sooner if something material changes.
Contact: [Name, 24/7 phone, monitored mailbox.]
Think about your customer's clock
Your notice may start their own legal process. A regulated customer may have to report, and a personal data breach could trigger UK GDPR duties. Sending clear facts early helps them decide. Do not tell a customer whether they have to report, as you may not know their circumstances.
Prepare before an incident
- Keep a current list of customers, services and security contacts.
- Agree an out-of-band route, in case email is affected.
- Pre-approve template wording with legal and communications staff.
- Check contracts for shorter notice periods, which still apply.
- Rehearse it in your 24-hour runbook.
Sources
Frequently asked questions
Data centre operators (regulation 11C), RDSPs (regulation 12C) and RMSPs (regulation 14G). Other operators of essential services do not have this particular duty in HL Bill 32.
As soon as reasonably practicable after the full notification to the regulator. The organisation must take reasonable steps to identify affected UK customers and then notify them. No fixed number of hours is given.
UK customers likely to be adversely affected. You consider disruption to their service, whether their data’s confidentiality, authenticity, integrity or availability is likely to be compromised, and any other impact on their systems.
HL Bill 32 places these failures in the higher band: a maximum of the greater of £17 million and 4% of turnover for undertakings.
The duty is triggered after the full notification, but nothing we found in the text prevents telling customers earlier. A customer contract or UK GDPR may require it, so check them.