72-hour incident report under the Cyber Security and Resilience Bill: guide and template
The 72-hour full notification under the Cyber Security and Resilience Bill (CSRB) covers who you are, when the incident happened, its nature, any link to another regulated organisation, and its impact, so far as you know them. The 72 hours starts from first awareness, not from the 24-hour notice.
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.
What the law asks for
The Cyber Security and Resilience Bill (CSRB) calls this the full notification. HL Bill 32 uses almost the same list for each category: regulation 11 for OESs, 11A for data centres, 12A for RDSPs and 14E for RMSPs.
| Item | What it means in practice |
|---|---|
| Name and service | Your organisation, and the essential, digital, data centre or managed service affected |
| Time, duration, whether ongoing | When it occurred, how long it lasted, and its current status |
| Nature of the incident | What kind of event it was, and what systems it affected |
| Link to another regulated person | If it was caused by another incident at a regulated person, details of that incident and organisation |
| Impact | Actual or likely impact, including cross-border impact |
| Other useful information | Anything else you consider may assist the regulator |
The duty only covers this information "so far as known". The Bill does not ask you to have finished your investigation.
Check the final text. Lords amendments may have changed the incident wording. See what Parliament has changed.
The clock
| Time | What is due |
|---|---|
| T+0 | You are first aware that a reportable incident has occurred or is occurring |
| Before T+24h | Initial notification |
| Before T+72h | Full notification |
Both must go to the regulator and, at the same time, to the CSIRT. Note the difference between "aware of an event" and "aware of a reportable incident". Keep a record of when you made that decision and why. See what counts as a significant incident.
Template (unofficial)
This is not an official form, and we have not found one as of 2 November 2026. Regulators can set the form and manner, so use theirs once published.
Full notification under [regulation 11 / 11A / 12A / 14E]
Reference: [Regulator reference from the initial notification, if any] Date and time of this report: [UTC and UK time]
1. Organisation and service Organisation: [legal name] Category: [OES / data centre / RDSP / RMSP] Service affected: [name and description] 24/7 contact: [name, phone, email]
2. Timing First aware of the reportable incident: [date, time] Incident occurred: [date, time, or "not yet established"] Duration: [time] Current status: [ongoing / contained / resolved]
3. Nature of the incident Type: [for example, ransomware, unauthorised access, denial of service, or non-malicious failure] Systems affected: [description, without unnecessary sensitive detail] Confirmed facts: [list] Under investigation: [list]
4. Link to another regulated person Caused by a separate incident affecting another regulated person: [Yes / No / Not yet known] If yes: [organisation and details]
5. Impact Disruption to the service: [extent, actual and likely] Users affected: [number or estimated range, stating which] Geographical area: [UK nations and regions] Data: [any confirmed or likely compromise of confidentiality, authenticity, integrity or availability] Impact on users' systems: [description] Wider impact: [economy or day-to-day functioning of society, if relevant] Cross-border impact: [countries and description]
6. Other information that may assist [Containment steps, indicators, whether other authorities have been told, and support requested]
7. Next steps Next update expected: [date, time] Customer notification: [plan and status, if applicable]
The impact section follows the factors in the Bill. RDSPs and RMSPs have more factors than other OESs, so remove anything that does not apply.
Writing it well
- Separate fact from assessment. Use labels like "confirmed", "likely" and "not yet known".
- Use ranges honestly. "Between 2,000 and 5,000 users" is better than a false exact figure.
- Do not guess at attribution. Say so if the source is not known.
- Get privilege advice early. Lawyers may want to review what you write, but build that into the 72 hours.
- Think about what you share. Regulators may share some information in certain circumstances, with limits on confidential or commercially harmful details.
Who does what
Before an incident, name a drafter (incident lead), a fact checker (technical lead), an approver (senior manager or deputy) and a sender. Check all four have cover. The final decision should not depend on one person being reachable.
Related duties
- Failure penalties. Incident notification failures are in the higher band. Failing to copy the CSIRT is in the standard band. See fines and penalties.
- Customers. RDSPs, RMSPs and data centres must notify customers after the full notification. See customer notification.
- UK GDPR. A personal data breach may need a separate report to the Information Commission within 72 hours, under a different test.
Sources
- The Bill as brought from the Commons (HL Bill 32), sections 15, 16 and 21
- Government incident reporting factsheet
Frequently asked questions
Before the end of 72 hours from when you were first aware of the reportable incident. It is the same starting point as the 24-hour notice, so you do not get a fresh 72 hours after sending that notice.
The duty is to include the listed information so far as known to you. Say what is known, unknown and still under investigation.
Root cause is not on the list in HL Bill 32. You must give information on the nature of the incident, and may add anything that would help the regulator. Do not guess at a cause.
Your regulator, with a copy sent to the CSIRT at the same time. It must be in writing, in the form and manner the regulator sets.
RDSPs, RMSPs and data centres must then notify affected UK customers as soon as reasonably practicable. A regulator may also decide that public awareness is needed.