Article 33 Breach Notification

How Article 33 Works in Practice

Article 33 is not just a deadline, it is the decision point that turns an internal incident into a regulated notification workflow. The core question is whether the event is a personal data breach, whether it is likely to risk individuals, and whether the organisation can document that decision quickly and consistently.

That means the legal duty depends on operational facts, not assumptions. Teams need a defensible way to confirm what data was involved, who may have been exposed, whether the event is still active, and whether escalation to privacy, legal, security, and incident response owners is immediate.

What Counts as a Reportable Breach

A reportable breach under Article 33 is not limited to obvious theft or public disclosure. It can include unauthorised access, accidental release, loss of availability where personal data is affected, or any event where confidentiality, integrity, or access control failures may create risk to individuals.

The practical challenge is triage. Not every security incident becomes an Article 33 notification, but waiting too long to classify the event can make a later notification incomplete. That is why organisations often build privacy breach thresholds into incident handling so the first responders know when to preserve evidence and escalate.

For a cross-border view of how breach reporting expectations vary, see Global Privacy Regulatory Map.

Assessment, Escalation, and Timing

The 72-hour clock is only useful if the organisation can start the assessment fast enough to support it. Article 33 workflows usually depend on asset inventory, data classification, ownership, logging, and a clearly defined chain for deciding when the supervisory authority must be notified.

The notification itself is often preceded by a short but disciplined assessment: what happened, when it started, what categories of personal data were involved, how many people might be affected, and what immediate containment steps were taken. If the investigation is incomplete, the law still expects the initial notice to go out when feasible, with later updates as more facts emerge.

For a concrete reporting workflow, the Data Breach Notification Checklist is a useful reference point for 72-hour reporting, decision points, and breach records.

Evidence, Containment, and Post-Notice Review

Article 33 is not finished when the notice is sent. Organisations still need to understand root cause, preserve logs and artefacts, and check whether the breach is ongoing or whether related accounts, sessions, or access paths remain compromised.

Containment measures matter because a partial fix can still leave exposure behind. Encryption, session revocation, account lockdown, and key or token rotation may change the risk picture, but only if they are applied to the actual compromised path. Post-notice review should confirm whether the incident was isolated, whether the initial assessment was accurate, and whether similar weaknesses exist elsewhere.

Where device loss or endpoint compromise is part of the scenario, the Lost or Stolen Device Response Checklist shows how containment and breach assessment should be tied together.

Risk and Threat Considerations

Article 33 risk is usually driven by timing, uncertainty, and underclassification. If teams cannot rapidly determine whether personal data was exposed, they may miss the 72-hour window, submit an incomplete notice, or fail to recognise that a seemingly technical incident has privacy consequences.

Failure mechanism: Attackers or accidental insiders exploit slow triage, poor logging, or weak data mapping, which leaves the organisation unable to prove what happened in time for a reliable supervisory notice.

Impact: Delayed or inaccurate notification can increase regulatory exposure, obstruct containment, and leave individuals at greater risk from misuse of their personal data.

Practitioner Guidance

Why practitioners should care: Article 33 works best when breach reporting is treated as an incident-response discipline, not a legal afterthought. The organisations that handle it well usually have a predefined escalation model, named decision owners, and a way to separate uncertainty from inaction.

Practitioner note: If you are unsure whether the event is notifiable, preserve evidence, escalate early, and keep the decision trail explicit. A well-documented preliminary assessment is often more defensible than a delayed attempt to reconstruct the facts after the window has already narrowed.

Related resources from NHI Mgmt Group

• What do identity teams get wrong about breach notification readiness?
• Who is accountable when a 72-hour GDPR breach notification is delayed because data discovery is incomplete?
• What breaks when breach notification obligations are not built into incident response processes?
• What do organisations get wrong about HIPAA breach notification and enforcement?