When the first notification clock starts, nobody wants to be writing a regulator report from a blank page while the facts are still moving. This pack gives you pre-drafted initial reports for the regimes that most often apply to organisations operating in the UK, EU and US: UK GDPR and EU GDPR personal data breach notifications, the UK NIS Regulations 2018 incident notice, the NIS2 early warning and 72-hour notification, the DORA initial notification for financial entities, and the SEC Form 8-K Item 1.05 disclosure for US-listed companies. Each draft is built from the field list in the legal text, with placeholders you complete on the day. It is written for legal, privacy, compliance and incident response leads. Which regimes apply, and how their clocks interact, is covered in the EU Incident Reporting Clocks guide and the Cyber Incident Reporting Requirements Map; this page is the drafting layer.
How to use this template
- Replace text in square brackets, such as [Organisation], [time of awareness] and [competent authority], with your own values.
- Always submit through the regulator's own form or portal where one exists. Use these drafts to prepare the content and to agree it internally, then copy it into the portal. Several national NIS2 authorities and every DORA competent authority set their own submission channel, so confirm it in advance.
- Pre-fill the static parts now: legal entity names, registration numbers, LEIs, services provided, contact points and the regulator list. On the day you should only be writing facts about the incident.
- Say what you know, say what you do not yet know, and say when you will update. GDPR, NIS2 and DORA all allow information to follow in stages.
- Have counsel confirm which regimes apply in each jurisdiction and sector. Laws change, and this template is not legal advice.
1. Notification register
Open this register as soon as the legal and privacy lead is engaged, and record the awareness time first. Every clock in the table runs from awareness or determination, not from the end of the investigation.
| Regime | Trigger | First report due | Recipient | Owner | Status |
|---|---|---|---|---|---|
| UK GDPR / EU GDPR Art. 33 | Personal data breach, unless unlikely to result in a risk to individuals | Without undue delay and, where feasible, not later than 72 hours after becoming aware | [ICO / lead supervisory authority] | [DPO] | [ ] |
| UK NIS Regulations 2018, reg. 11 | NIS incident at an operator of essential services | Without undue delay, no later than 72 hours after the operator is aware | [designated competent authority] | [ ] | [ ] |
| NIS2 Art. 23(4)(a) early warning | Significant incident | Within 24 hours of becoming aware | [CSIRT or competent authority] | [ ] | [ ] |
| NIS2 Art. 23(4)(b) incident notification | Significant incident | Within 72 hours of becoming aware | [CSIRT or competent authority] | [ ] | [ ] |
| DORA initial notification | Major ICT-related incident | Within 4 hours of classification as major, and no later than 24 hours from awareness | [financial competent authority] | [ ] | [ ] |
| SEC Form 8-K Item 1.05 | Incident determined to be material | Generally within four business days of the materiality determination | SEC (EDGAR filing) | [General Counsel] | [ ] |
Record against each row the time of awareness, who decided, and the reason for any decision not to notify. GDPR Article 33(5) requires all personal data breaches to be documented, whether or not they are reported, so that the supervisory authority can verify compliance.
2. UK GDPR and EU GDPR personal data breach notification
Article 33(3) lists the minimum content: the nature of the breach including, where possible, the categories and approximate number of data subjects and records; the name and contact details of the DPO or other contact point; the likely consequences; and the measures taken or proposed. In the UK, report through the ICO's personal data breach route; providers of public electronic communications services (PECR), trust service providers and digital service providers under NIS each have a separate ICO reporting route.
Report type: [Initial / follow-up / final]. Our reference: [internal incident ID].
Controller: [legal entity name], [registration number], [address]. ICO registration number: [ ]. Lead supervisory authority (EU): [ ].
Contact point: [DPO name], [phone], [email]. Out of hours: [ ].
Timeline: The breach [occurred / is believed to have started] on [date, time UTC]. [Organisation] became aware on [date, time UTC] when [how it was detected]. This report is made on [date, time UTC]. [If more than 72 hours after awareness: The reasons for the delay are [reasons].]
Nature of the breach: [Confidentiality / integrity / availability] breach caused by [brief, factual description, for example unauthorised access to [system] using a compromised [user credential / API key / service account]]. Systems involved: [ ].
Data subjects and records: Categories of data subjects: [customers / employees / patients / children]. Approximate number of data subjects: [number or range, or "being established"]. Categories of personal data: [ ]. Special category or criminal offence data involved: [yes, which / no / not yet known]. Approximate number of records: [ ].
Likely consequences: [For example: risk of targeted phishing using the exposed contact details; risk of fraud; loss of access to services for [period]].
Measures taken or proposed: [Containment actions, for example access revoked, credentials rotated, system isolated]; [steps to reduce harm, for example password resets, monitoring]; [notification of individuals: done on [date] / planned for [date] / not required because [reason]].
Other notifications: [Other supervisory authorities, NCSC, law enforcement (reference), other regulators].
Information to follow: We will provide [scope confirmation / number of individuals / root cause] by [date].
Article 33(4) allows information to be provided in phases without undue further delay where it cannot all be given at once. Do not hold the report back for a complete picture. Telling individuals (Article 34) is a separate decision with its own test of high risk; use the Customer Breach Notification Letter Template for that.
3. UK NIS Regulations 2018 incident notice
Regulation 11 requires an operator of essential services to notify its designated competent authority in writing, without undue delay and no later than 72 hours after it is aware that a NIS incident has occurred. The information required is limited to what the operator can reasonably be expected to know. Relevant digital service providers report incidents to the ICO under their own route.
Operator: [legal entity name]. Essential services provided: [for example electricity distribution in [region]].
Contact: [name, role, phone, email].
Incident timing: Occurred at [date, time UTC] (or "first observed at"); operator aware at [date, time UTC]; [ongoing / contained at [time]]. Duration so far: [ ].
Nature of the incident: [Factual description]. Suspected malicious: [yes / no / unknown].
Impact on the essential service: [Users affected, geographic area, degradation or loss of service, duration].
Cross-border impact: [None known / affects services in [countries]].
Other information: [Indicators shared with NCSC, supplier involvement, actions taken].
See the UK NIS Regulations 2018 Guide for thresholds and competent authorities by sector.
4. NIS2 early warning (24 hours)
Article 23(4)(a) requires an early warning within 24 hours of becoming aware of a significant incident. Where applicable it states whether the incident is suspected of being caused by unlawful or malicious acts or could have a cross-border impact. Keep it short: its purpose is to alert the CSIRT and ask for help if you need it.
Entity: [legal entity], [essential / important entity], sector [ ], Member State of establishment [ ].
Contact: [name, phone, email].
Awareness: [date, time UTC].
Summary: [One or two sentences: what is affected and how, for example "ransomware encryption of [systems] affecting [service]"].
Suspected unlawful or malicious act: [Yes / no / not yet known].
Possible cross-border impact: [Yes, [countries or services] / no / not yet known].
Assistance requested from the CSIRT: [None at this stage / specify].
5. NIS2 incident notification (72 hours)
Article 23(4)(b) requires, within 72 hours of becoming aware, an update to the early warning, an initial assessment of the incident including its severity and impact, and indicators of compromise where available. A final report follows within one month of this notification (Article 23(4)(d)), or a progress report if the incident is still ongoing.
Reference: Early warning submitted [date, time], reference [ ].
Update to early warning: [Changes since the early warning].
Initial assessment: Severity: [our rating and basis]. Impact: [services degraded, users affected, duration, financial loss estimate if known, effect on other persons].
Indicators of compromise: [IP addresses, domains, hashes, compromised account or key identifiers, or "attached separately"].
Mitigation: [Applied and ongoing measures].
Recipients of services informed: [Yes, on [date] / planned / not required because [reason]].
Next report: [Final report by [date], or intermediate report on request].
National transposition sets the portal, the competent authority and sometimes extra fields. Check the relevant country page, for example the Germany NIS2 Implementation Guide, and see the NIS2 Directive Guide for the significance test.
6. DORA initial notification (major ICT-related incident)
Commission Implementing Regulation (EU) 2025/302 sets the template. One template covers the initial notification, intermediate report and final report; you complete the fields required at each stage and may complete later fields early. Delegated Regulation (EU) 2025/301 Article 5 sets the clocks: initial notification within four hours of classification as major and no later than 24 hours from awareness; intermediate report within 72 hours of the initial notification; final report no later than one month after the latest intermediate report. If a deadline will be missed, tell the authority before it passes and explain why.
| Field (ITS 2025/302 Annex I) | Draft entry |
|---|---|
| 1.1 Type of submission | Initial notification |
| 1.2 to 1.6 Submitting and affected entity, type, identification code, LEI | [Pre-fill now] |
| 1.7 to 1.12 Primary and second contact (name, email, phone) | [Pre-fill now] |
| 1.13 to 1.14 Ultimate parent name and LEI | [Pre-fill now, if in a group] |
| 1.15 Reporting currency | [EUR / other] |
| 2.1 Incident reference code | [Internal ID] |
| 2.2 Date and time of detection | [UTC] |
| 2.3 Date and time of classification as major | [UTC] |
| 2.4 Description | [Factual summary of what happened and what is affected] |
| 2.5 Classification criteria triggered | [Criteria from Delegated Regulation (EU) 2024/1772 that were met, for example clients affected, critical services, data losses] |
| 2.6 Geographical spread | [Member States affected, if the threshold is met] |
| 2.7 Discovery method | [Internal monitoring / client report / third-party provider / authority] |
| 2.8 Originates from a third-party provider or other financial entity | [Yes, name / no / unknown] |
| 2.9 Business continuity plan activated | [Yes / no] |
| 2.10 Other relevant information | [ ] |
The weekend and bank holiday extension in Article 5(4) does not apply to initial notifications or intermediate reports from credit institutions, central counterparties, trading venue operators, or entities that are essential or important under NIS2. Estimates are allowed where accurate data is not yet available. See the DORA Major ICT Incident Reporting Guide for classification.
7. SEC Form 8-K Item 1.05 draft
Item 1.05 requires a registrant to describe the material aspects of the nature, scope and timing of a material cybersecurity incident, and its material impact or reasonably likely material impact, including on financial condition and results of operations. The materiality determination must be made without unreasonable delay after discovery, and the filing is generally due four business days after it. Delay is possible only where the US Attorney General determines that immediate disclosure would pose a substantial risk to national security or public safety and notifies the SEC in writing. Foreign private issuers make comparable disclosures on Form 6-K.
Item 1.05 Material Cybersecurity Incidents
On [date], [Registrant] [detected / was notified of] [unauthorised access to / a ransomware attack affecting / other] [category of systems, described at a level that does not help an attacker]. [Registrant] activated its incident response plan, [took steps to contain], engaged [external advisers] and notified law enforcement.
Nature and scope: [Which operations, business lines or data categories were affected, in material terms].
Timing: [When the activity began, if known, and when it was contained or whether it is ongoing].
Material impact or reasonably likely material impact: [Effect on operations, customers, financial condition and results of operations, for example disruption to [operations] for [period], expected costs, effect on revenue in the current quarter, regulatory or legal exposure].
As of the date of this report, [Registrant] has not yet determined [specific information not yet known]. [Registrant] will file an amendment to this Form 8-K to disclose that information within four business days after it is determined or becomes available.
On 21 May 2024 the Director of the SEC's Division of Corporation Finance stated that Item 1.05 is for incidents determined to be material, and encouraged companies to disclose incidents not yet assessed, or found immaterial, under a different item such as Item 8.01. If an Item 8.01 incident is later found material, file under Item 1.05 within four business days of that determination. See the SEC Cybersecurity Disclosure Rules Guide.
Implementation guidance
Preparing the pack before an incident
- Build the applicability list: for each legal entity, which regimes apply, which authority receives the report, and through which portal. Get access credentials to portals now and store them where the response team can reach them if the corporate identity provider is down.
- Pre-fill static fields: entity names, registration numbers, LEIs, essential services, contacts, parent company. These are slow to find under pressure.
- Agree approvers: who signs each report (DPO, General Counsel, disclosure committee) and who deputises. Record it on the legal lead's card in the Incident Response Role Cards Template.
- Link the facts pipeline: the technical lead's scope statement should map to the fields here (systems, data categories, counts, indicators), so legal is not re-asking the same questions.
- Exercise it: in each tabletop, have the legal lead file a mock initial report against the clock. See the Tabletop Exercise Guide.
Which draft to start first
| Situation | Start with | Then |
|---|---|---|
| EU financial entity, major ICT incident | DORA initial notification (4 hours from classification) | GDPR if personal data involved |
| NIS2 essential or important entity, significant incident | NIS2 early warning (24 hours) | GDPR, then NIS2 72-hour notification |
| UK operator of essential services | NIS reg. 11 notice and UK GDPR in parallel (both 72 hours) | Sector regulator contacts |
| US-listed company, incident possibly material | Materiality assessment record, then Item 1.05 draft | Item 8.01 if not yet determined material |
| Any organisation, personal data breach only | GDPR Art. 33 report | Article 34 decision on telling individuals |
Where identity fits
Most of the drafts ask for the nature or cause of the incident. Be specific and factual about the identity involved (a phished user, a stolen API key, a misused service account or OAuth token) without disclosing secrets, and say what was revoked and rotated. Keeping an inventory of non-human identities makes the "scope" fields answerable inside 72 hours. See the Identity Incident Response Playbook.
Measures
- Percentage of applicable regimes with pre-filled static fields and tested portal access (target 100%).
- Time from awareness to register opened (our target: under one hour).
- Notifications filed on time over the last 12 months (target 100%).
- Follow-up reports delivered by the date promised in the initial report.
Common failure patterns
- Waiting for certainty: the investigation is not finished, so the report is not sent, and the 72-hour clock runs out. All the regimes here accept staged information.
- Awareness time not recorded: nobody can later show when the clock started.
- Inconsistent facts: the regulator report, the customer letter and the press statement give different numbers. Route all three through the legal lead.
- Portal access lost: the only person with credentials is on leave, or access depends on the compromised email system.
- Over-sharing technical detail: public filings such as Item 1.05 should describe impact, not detail that would help an attacker.
Framework mapping
| Framework | Reference |
|---|---|
| NIST CSF 2.0 | GV.OC-03 legal, regulatory and contractual requirements understood and managed; RS.CO-02 internal and external stakeholders notified of incidents |
| NIST SP 800-53 Rev. 5 | IR-6 Incident Reporting |
Standards and references
- legislation.gov.uk: UK GDPR Article 33, Notification of a personal data breach to the Commissioner
- EUR-Lex: Regulation (EU) 2016/679 (GDPR), Articles 33 and 34
- ICO: Report a breach
- legislation.gov.uk: The Network and Information Systems Regulations 2018, regulation 11
- EUR-Lex: Directive (EU) 2022/2555 (NIS2), Article 23
- EUR-Lex: Commission Delegated Regulation (EU) 2025/301 on major ICT-related incident reporting
- EUR-Lex: Commission Implementing Regulation (EU) 2025/302 on reporting templates
- SEC: Form 8-K and General Instructions (Item 1.05 and Instructions)
- SEC: Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure rules
- SEC: Statement on disclosure of cybersecurity incidents determined to be material
Related NHI Mgmt Group resources: EU Incident Reporting Clocks · Cyber Incident Reporting Requirements Map · Incident Communication Plan Template · Data Breach Notification Checklist · Board and Director Cyber Liability Guide. This guide summarises notification requirements and is not legal advice.