The Irish Data Protection Commission fined Bank of Ireland €463,000 in March 2024 specifically for missing the 72-hour notification window. Not for the breach itself. For the late disclosure. That distinction matters enormously, because it means your incident response workflow is a regulatory artefact in its own right, one that regulators will scrutinise independently of whatever caused the underlying event.
European cloud operators now sit at the intersection of two overlapping frameworks: GDPR’s Article 33 notification obligations and the NIS2 Directive’s structured three-stage reporting model. Both carry significant penalties. Neither tolerates improvisation. What follows is a concrete account of what needs to be in place before the first alert fires.
How the 72-hour clock actually works under GDPR
Article 33 GDPR requires controllers to notify their competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. The phrase “becoming aware” is where most organisations underestimate their exposure.
EDPB Guidelines 9/2022 (Version 2.0, April 2023) clarify that the clock starts when the controller has a “reasonable degree of certainty” that a security incident has compromised personal data. If your team detects a network intrusion and confirms within two hours that personal data was accessed, the 72-hour period begins at that confirmation, not when the forensic investigation concludes. Waiting for certainty before starting the clock is itself a compliance failure.
Processors carry a parallel obligation: they must notify the controller “without undue delay” after becoming aware of a breach. GDPR sets no explicit hour count for processor-to-controller notification, but the EDPB is clear that the processor’s notification must arrive early enough for the controller to meet the 72-hour supervisory deadline. In practice, a processor that takes 48 hours to notify the controller has made compliance structurally impossible.
Phased notification is permitted under Article 33(4). If complete information is unavailable within 72 hours, the controller can submit an initial notification and follow up without undue further delay. The mandatory content for any notification includes the nature of the breach (categories and approximate numbers of individuals affected), the DPO or contact point details, the likely consequences of the breach, and the measures taken or proposed to address it. Missing any of these elements from an initial filing does not excuse the gap; it extends the documentation trail regulators will review.
Article 34 adds a second obligation that operates at a higher threshold: when a breach is likely to result in a high risk to the rights and freedoms of natural persons, affected data subjects must also be notified without undue delay. And Article 33(5) requires documentation of all breaches regardless of whether notification was required, so that supervisory authorities can verify compliance. Every breach, even those assessed as low-risk, generates a record.
“The controller shall document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken. That documentation shall enable the supervisory authority to verify compliance with this Article.” — Article 33(5) GDPR
Failure to notify, or late notification, is a separate violation from whatever caused the underlying incident. Fines reach up to €10 million or 2% of global annual turnover. In 2024 alone, European data protection authorities issued over €40 million in fines where late or missing breach notification was a cited violation. The Bank of Ireland decision is not an outlier; it is a pattern.
NIS2’s 24-72-30 structure: a tighter cadence than most teams expect
Directive (EU) 2022/2555, formally adopted on 16 January 2023 with a member state transposition deadline of 17 October 2024, replaces the original NIS Directive and introduces the most structured incident reporting framework in EU cybersecurity regulation. For cloud providers, it is not optional background reading: NIS2 explicitly classifies cloud computing services, data centre services, content delivery networks, DNS providers, and managed service providers as essential entities, placing them in the highest-risk category under Annex I.
Article 23 of NIS2 mandates three discrete reporting actions for significant incidents:
- Within 24 hours: an early warning indicating whether the incident is suspected to involve unlawful or malicious acts or could have cross-border impact.
- Within 72 hours: an incident notification updating the early warning with an initial assessment of severity and impact, and indicators of compromise where available.
- Within one month of the 72-hour notification: a final report covering root cause, impact, and remediation measures.
The 24-hour early warning is the element that catches operators off guard. It requires a substantive communication to the relevant CSIRT or competent authority before most internal investigations have concluded. That means the workflow must produce a structured, accurate preliminary report under time pressure, not a placeholder email.
The significant incident threshold and who it catches
NIS2 reporting is triggered by “significant incidents,” defined as incidents that have caused or are capable of causing severe operational disruption or financial loss to the entity, or that have affected or are capable of affecting other persons by causing considerable material or non-material damage. The “capable of causing” language is deliberate: the threshold does not require confirmed harm. A credible risk of cross-border service disruption is sufficient.
Non-EU entities providing cloud services, DNS resolution, CDN capacity, or managed services within the EU are also in scope and must designate an EU representative in a member state where their services are offered. The size threshold for most sectors is 50 employees or €10 million turnover, with specific exceptions for DNS operators, trust services providers, and certain public administrations. For most cloud operators of meaningful scale, NIS2 applies without qualification.
Penalties for essential entities reach €10 million or 2% of total worldwide annual turnover, whichever is higher. Important entities face up to €7 million or 1.4% of global turnover. Member states may set higher penalties at transposition but not lower ones.
What a pre-built response workflow must contain
Given overlapping GDPR and NIS2 obligations, a cloud security incident response plan needs to address four operational requirements before any incident occurs.
Detection-to-declaration in under two hours
The gap between technical detection and formal internal declaration that a breach has occurred is where most disclosure delays originate. Your monitoring stack needs a defined escalation path that produces a binary decision: does this event meet the threshold for GDPR or NIS2 notification? That decision must involve named individuals with authority to act, not a committee that forms after the fact.
Processor notification SLAs written into contracts
If you operate as a processor, your data processing agreements must specify the notification timeline to controllers. The EDPB’s guidance makes clear that “without undue delay” for processors means fast enough for the controller to meet 72 hours. Practically, that means a contractual commitment of no more than 12 to 24 hours from processor detection to controller notification, with a defined escalation contact on both sides.
Pre-drafted notification templates mapped to each framework
Article 33(3) GDPR and Article 23 NIS2 require different content at different stages. A single generic incident report will not satisfy both. Templates should be structured around the mandatory fields for each framework, with placeholder fields that investigators fill in from a running incident log rather than reconstructing from memory under pressure.
Documentation running from minute one
Article 33(5) GDPR requires documentation of every breach, including those assessed as not requiring notification. That record must be contemporaneous: timestamped entries showing what was known, when, and what decisions were taken. A post-incident writeup assembled after the supervisory authority asks questions does not satisfy the obligation and will not survive scrutiny.
Operating from a certified baseline
DIVERSITY’s infrastructure operates under ISO 27001 certification across Tier III facilities, which means the incident management processes that underpin GDPR Article 33 and NIS2 Article 23 compliance are not improvised responses to regulatory pressure. They are embedded in a documented information security management system, tested through regular audits, and operated by a team that answers to European law without the jurisdictional ambiguity that comes with infrastructure rooted outside the EU.
For IT teams evaluating cloud providers against their own NIS2 incident reporting timeline obligations, the question is not whether their provider has an incident response plan. It is whether that plan integrates with theirs, produces the right artefacts at the right times, and operates under the same legal framework. Those are questions worth asking before the 24-hour clock starts.
