Breach notification: procedures and deadlines

When and how to notify a breach

Breach notification in Europe involves multiple overlapping regulatory frameworks with different deadlines, different authorities, and different notification content requirements. An incident involving personal data at a financial institution operating critical digital infrastructure may simultaneously trigger GDPR, DORA, and NIS2 notification obligations — each with its own clock, its own authority, and its own content requirements.

Understanding which frameworks apply, in what sequence, and to which authorities is essential operational knowledge for security and compliance teams. The worst time to learn the notification requirements is during an active incident with systems down and leadership demanding answers.

Comparison of deadlines

Regulation	Authority	Deadline	Affected individuals
GDPR	National DPA (e.g., ICO, CNIL)	72 hours	”Without undue delay” if high risk
NIS2	National CSIRT / competent authority	24h (early warning) + 72h + 1 month	Not required
DORA	Financial supervisory authority	4 hours	Depending on impact

DORA’s four-hour initial notification deadline for major ICT incidents is among the most stringent in the regulatory landscape. Financial entities must have detection and classification capabilities that can reliably identify major incidents within the window needed to prepare a notification in four hours. Organizations that discover incidents through manual investigation or daily log review will struggle to meet this timeline.

Detection and qualification: determine whether a personal data breach has occurred (confidentiality, integrity, or availability)
Risk assessment: is the risk to individuals low, medium, or high?
Notification to the supervisory authority: via the authority’s online portal, within 72 hours of becoming aware of the breach
Notification to individuals: required if there is a high risk to their rights and freedoms, without undue delay
Documentation: record the incident in the breach register, even if notification was not required

The 72-hour clock starts when the organization “becomes aware” of the breach. This trigger point has been interpreted strictly by supervisory authorities: receiving a credible report that a breach may have occurred starts the clock, even if investigation is ongoing. Organizations cannot wait for full confirmation before the clock begins.

The risk assessment step determines whether to notify individuals. The threshold is high risk to the rights and freedoms of natural persons. Relevant factors include the sensitivity of the data (health, financial, biometric, special categories), the number of individuals affected, the likelihood of harm (fraud, identity theft, discrimination), and whether encryption or other technical controls effectively protect the data.

NIS2 reporting procedure

NIS2 reporting uses a three-stage process specifically designed to allow partial reporting when information is incomplete:

Stage 1 — Early warning (24 hours): submit a brief notification to the national CSIRT or competent authority confirming the incident occurred. Include the nature of the incident if known (ransomware, data breach, DDoS), an initial assessment of whether the incident appears to be criminal or cross-border, and immediate containment actions taken.

Stage 2 — Incident notification (72 hours): update the initial notification with preliminary impact assessment, indicators of compromise, and initial root cause analysis if available.

Stage 3 — Final report (1 month): provide a complete description of the incident, full impact assessment, root cause analysis, implemented remediation measures, and lessons learned.

NIS2 does not require notification to affected individuals — that obligation comes from GDPR when personal data is involved.

What the notification must contain

Nature of the breach (confidentiality, integrity, availability)
Categories and approximate number of individuals affected
Categories and approximate number of records affected
Likely consequences of the breach
Measures taken or proposed to address it and mitigate its effects
Contact details of the Data Protection Officer or designated contact

The emphasis on “approximate” numbers is deliberate. Supervisory authorities expect notifications before a complete forensic investigation is possible. Providing reasonable estimates with appropriate confidence intervals is expected; holding notifications until exact figures are confirmed is not.

Preparing notification templates in advance

Organizations that prepare breach notification templates before an incident occurs are significantly better positioned to meet tight deadlines under pressure. Templates should:

Include the structure required by each applicable regulation
Have pre-approved language for common incident scenarios (ransomware, data exfiltration, unauthorized access)
Identify the specific portal or contact for each regulatory authority
Define who within the organization has authority to approve and submit notifications
Reference the breach register format and where it is maintained

Running tabletop exercises that include the notification workflow — simulating the 24-hour and 72-hour decision points under realistic time pressure — reveals process gaps that are invisible until you face them.

Common mistakes

Waiting for complete information: notify within the deadline even if the investigation is still ongoing — supplementary reports are permitted
Underestimating scope: provide a reasonable estimate, not an exact figure; underreporting creates additional liability
Failing to document: incidents that do not require notification must still be recorded in the breach register
Skipping internal communication: notify your DPO, legal counsel, and executive leadership immediately upon detection, not at the 72-hour mark
Missing parallel obligations: check all applicable frameworks, not just GDPR — a single incident may trigger multiple notifications to different authorities
Inadequate record-keeping: the breach register is a regulatory document; it must be maintained systematically and available for inspection by supervisory authorities

The documentation obligation is frequently overlooked. Under GDPR Article 33(5), the controller must document all personal data breaches, including those that do not require notification to the supervisory authority. This breach register must record the facts of the breach, its effects, and the remedial action taken. Supervisory authorities can request this register during audits and investigations, and an incomplete register is independently actionable.