GDPR Article 33: The 72-Hour Breach Notification Countdown

What Constitutes a Personal Data Breach

The GDPR^[1] defines a personal data breach broadly: “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.” This encompasses far more than hacker attacks. Aransomware encryption rendering data inaccessible is an availability breach. An employee sending client data to the wrong recipient is a confidentiality breach. Database corruption altering records is an integrity breach.

A breach does not require malicious access. Accidental deletion without backup, loss of an unencrypted laptop, or a misconfiguration exposing data to unauthorised internal users all constitute notifiable breaches if they meet the risk threshold. The EDPB has demonstrated the breadth of this definition through detailed case guidance.

For private capital organisations, the data types matter significantly. Financial data, investor identity documents, beneficial ownership information, and UHNWI personal details represent categories where breach notification is almost always required, regardless of volume.

When the Clock Starts: The Awareness Threshold

The 72-hour period begins when the controller “becomes aware”—a reasonable degree of certainty that a security incident has compromised personal data. This does not require complete certainty about scope or impact. Awareness typically crystallises when monitoring detects anomalous activity, an employee reports a data handling error, a third party notifies of exposure, or ransomwareconfirms system compromise.

Organisations cannot extend the clock by failing to investigate alerts or structuring monitoring to avoid detection. The GDPR imposes a constructive awareness standard: if a reasonable controller with appropriate measures would have detected the breach, the clock runs from when detection should have occurred, not when it did. Supervisory authorities have penalised organisations claiming late awareness due to inadequate detection.

The Risk Assessment: Notify or Not

Article 33(1) requires notification “unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons.” The EDPB methodology considers: breach nature (confidentiality, integrity, availability), data sensitivity, ease of identification, severity of consequences, special characteristics of individuals or controller, and number affected. Only breaches genuinely unlikely to pose any risk fall below the threshold.

In practice, the threshold is low. Supervisory authorities consistently hold that controllers should notify unless they can positively demonstrate no risk. Failure to notify when required: up to €10 million or 2% of annual worldwide turnover under Article 83(4)(a). Late notification is an independent compliance failure that authorities have fined separately.

Content of the Notification

Article 33(3) specifies minimum content: description of the breach nature including categories and approximate numbers of data subjects and records; DPO or contact point details; likely consequences; and measures taken or proposed to address the breach and mitigate effects.

Article 33(4) permits phased notification—initial notification within the deadline with available information, followed by supplements as investigation progresses. Forensic investigation routinely extends well beyond 72 hours. Maintain pre-drafted templates aligned with your supervisory authority's forms to accelerate the process under time pressure.

Cross-Border Notification

For organisations with multi-EU operations, the one-stop-shop mechanism directs notifications to the lead supervisory authority in the controller's main establishment. However, some authorities have asserted local jurisdiction over cross-border breaches, and the cooperation mechanisms under Articles 60–67 create multi-authority coordination requirements. Map supervisory authority relationships before a breach occurs.

Consider parallel obligations: NIS2^[2] requires 24-hour early warning and 72-hour incident response notification; DORA^[3] imposes separate requirements for financial entities. Manage these through integrated reporting procedures ensuring all obligations are met without inconsistency across authorities.

The Practical 72-Hour Timeline

Allocate time across four parallel workstreams: investigation, risk assessment, notification preparation, and containment. Hours 0–12: confirm the breach, initiate containment, assemble the response team, notify the DPO, and begin risk assessment alongside forensic analysis. Hours 12–36: substantially complete risk assessment, estimate affected data scope, make notification decision, begin drafting using pre-prepared templates, and obtain legal review.

Hours 36–72: finalise notification, obtain management approval, and submit. If Article 34 notification to individuals is required (high risk to rights and freedoms), prepare in parallel. Document all decisions, factual bases, and timelines throughout to demonstrate due diligence.

Common Mistakes

First, delayed internal escalation. IT teams investigating for days before informing the DPO consume time needed for assessment and notification. Clear escalation protocols requiring immediate privacy function notification upon any suspected breach are essential.

Second, treating risk assessment as justification for non-notification rather than genuine risk evaluation. Authorities are sceptical of assessments that invariably conclude no notification is required. When uncertain, notify.

Third, controller/processor confusion—common among Private Equityportfolio companies. When a cloud provider (processor) suffers a breach, the portfolio company (controller) bears the notification obligation. Contractual provisions requiring processor notification within 24 hours preserve adequate time for the controller's compliance process.

Fourth, inadequate documentation. Every breach—notified or not—must be recorded in a breach register under Article 33(5). Supervisory authorities routinely request access during audits, and an incomplete register is itself a compliance failure attracting independent enforcement.