A security incident at a regulated organisation operating across multiple jurisdictions simultaneously triggers notification obligations measured in hours and days, not the weeks that traditional incident response processes assume. GDPR requires notification to the supervisory authority within 72 hours. DORA requires initial classification notification within 4 hours and a detailed report within 24 hours. NIS2 requires early warning within 24 hours. HIPAA allows 60 days for covered entities — but also requires notification of affected individuals, which must be managed in parallel. Managing all of these obligations simultaneously, with different clocks, different recipients, and different content requirements, is beyond the capacity of manual tracking systems at scale.
The Notification Timeline Matrix
GDPR Article 33 requires notification to the competent supervisory authority within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to natural persons. The notification must include the nature of the breach, categories and approximate number of affected persons, likely consequences, and measures taken or proposed. If all information is not available within 72 hours, initial notification must be made with the information available and supplemented without undue delay. The 72-hour clock starts from "becoming aware" — which is not the moment of first detection of anomalous activity but the moment the organisation has sufficient certainty that a breach has occurred.
DORA Article 19 requires that financial entities notify their competent authority of major ICT-related incidents. The notification has three stages: initial notification within 4 hours of classifying an incident as major, intermediate report within 72 hours, and final report within 1 month. The 4-hour initial notification is the most demanding timeline in the regulatory landscape — it requires that the incident classification decision be made quickly and the notification be generated and submitted within 4 hours of that decision. Manual drafting and submission processes cannot reliably hit this deadline at the end of a 3am incident call.
NIS2 Article 23 creates two-stage notification obligations for essential and important entities: early warning within 24 hours of becoming aware of a significant incident, and full notification within 72 hours. The early warning requires only basic information — the full notification requires comprehensive detail. NIS2 covers a broader scope of organisations than its predecessor NIS Directive — check whether the organisation qualifies as an essential or important entity under the sector-specific scope definitions before assuming NIS2 does not apply.
The Automation Requirement
The combination of 4-hour, 24-hour, and 72-hour deadlines across multiple frameworks makes manual notification tracking an unreliable process. A 4-hour deadline from DORA classification means that the incident response team must simultaneously be managing the technical response and drafting a regulatory notification — while potentially dealing with a major outage, customer escalations, and executive communication. The automated incident response workflow has three components: incident classification logic (automated rules that flag an incident as potentially notifiable under specific frameworks based on the nature of the incident, the data types involved, and the affected systems), notification drafting templates (pre-populated templates for each regulatory framework that pull relevant incident data from the incident record automatically), and submission automation (API integrations with regulatory notification portals where they exist, with deadline-tracking alerts that escalate if submission has not been confirmed before the deadline).
Incident Classification for Multi-Framework Notification
An incident that involves personal data, financial services infrastructure, and healthcare records simultaneously may trigger notification obligations under GDPR, DORA, HIPAA, and NIS2 at the same time. The classification logic must evaluate the incident against each framework's triggering criteria independently: GDPR triggers on personal data breach likely to result in risk to natural persons; DORA triggers on ICT incidents that affect financial entity operations above a defined impact threshold; HIPAA triggers on impermissible acquisition, access, use, or disclosure of unsecured PHI; NIS2 triggers on significant incidents that affect the continuity of essential services. The same incident may or may not trigger each framework, and the classification for each must be made independently and documented.
Evidence for the Notification Record
Regulatory notification processes require documented evidence that the notification was made within the required timeframe. Email submissions should generate automated receipts. Portal submissions should capture confirmation numbers. The notification submission record — who submitted it, when it was submitted, to which authority, with what content — must be retained as part of the incident record. Regulators routinely audit notification timeliness, and missed deadlines require explanation.
- Map all applicable notification obligations by framework and jurisdiction before an incident occurs — this is a planning exercise, not a crisis response exercise
- Build incident classification logic that evaluates each incident against all applicable notification triggers simultaneously, generating a per-framework notification decision
- Pre-populate notification templates for each framework with the required content fields — reduce the drafting burden on incident responders to filling in incident-specific details
- Integrate submission automation where regulatory portals offer APIs — eliminate the manual submission step for frameworks where automated submission is possible
- Build deadline tracking with escalating alerts: alert at T-2 hours, T-1 hour, and T-30 minutes before each deadline for unsubmitted notifications
- Retain notification submission evidence as part of the incident record — confirmation numbers, submission timestamps, and notification content
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.