skip to content

Breach Notification and DPO

5 roadmaps6 questions

The 72-hour clock for notifying a supervisory authority, the higher bar for telling affected individuals, the internal breach register, and when a Data Protection Officer is mandatory. Interviewers ask about the timeline because it dictates how fast detection and escalation have to work.

part ofCompliance & governance standardsoverview, primer and where to startread it →
on this pageshow

explore

questions

6

Under the GDPR, what counts as a personal data breach, and does it only mean data being stolen?

level: juniorimportance: must knowfreq 66%

answer

  1. a security failure, not any violation
  2. Art. 4(12) wording
  3. three security properties
  4. losing access counts too

basics

~20 s

Under GDPR Art. 4(12), a personal data breach is a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. It covers confidentiality, integrity and availability failures, not just theft.

solid answer

~40 s

Art. 4(12) of the GDPR defines a **personal data breach** as "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data". EDPB Guidelines 9/2022 sort breaches into three types: **confidentiality** (disclosure or access), **integrity** (alteration) and **availability** (loss of access or destruction). So ransomware that encrypts a clinic's booking database is a breach even with no sign of exfiltration, and so is an employee accidentally deleting records with no backup. It must be a *security* failure, though: processing without a lawful basis is a GDPR infringement, not a personal data breach. Every breach is documented under Art. 33(5); whether it is also notified depends on risk.

go deeper

for a junior

Recall the Art. 4(12) wording and the three breach types: confidentiality, integrity and availability. Show that losing access to data counts, not only leaking it.

for a middle

Classify a concrete event, such as ransomware, a lost stick or a bad script, into one or more breach types. Then separate 'is it a breach' from 'must it be notified'.

for a senior

Show that classifying an event as a breach opens a decision chain: record it, assess risk, notify the authority, possibly tell individuals. Explain why an availability-blind team leaves no record.

for a principal

Frame how a definition that covers availability and integrity shapes what an organisation's detection and escalation have to catch before any clock can start.

## The definition in the Regulation The GDPR defines the term in **Art. 4(12)**: a personal data breach is *"a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed."* Three parts of that sentence do the work: - **"a breach of security"**: the trigger is a security failure. A GDPR infringement that is not a security failure, such as processing without a lawful basis or keeping data too long, is a different problem under different Articles. It is not a "personal data breach". - **"accidental or unlawful"**: intent does not matter. A misaddressed email, a lost USB stick or an accidental deletion qualifies as much as an intrusion. - **the five outcomes**: destruction, loss, alteration, unauthorised disclosure, unauthorised access. Only two of them, disclosure and access, are defined by data reaching someone. EDPB Guidelines 9/2022 add a useful distinction: all personal data breaches are security incidents, but not every security incident is a personal data breach. A phishing attempt blocked before it reaches any personal data is an incident, not a breach. ## Three kinds of breach The EDPB guidelines borrow the classic information-security triad to classify breaches. One event can fall into several at once. | Type | What happened | Example | |---|---|---| | **Confidentiality** | unauthorised or accidental disclosure of, or access to, personal data | a customer file emailed to the wrong recipient | | **Integrity** | unauthorised or accidental alteration of personal data | a faulty script overwrites delivery addresses | | **Availability** | accidental or unauthorised loss of access to, or destruction of, personal data | ransomware encrypts records with no usable backup | The availability row is the one candidates forget. The guidelines say a **permanent** loss or destruction of personal data is always an availability breach. A **temporary** loss caused by a security incident is also a breach. Unavailability caused by **planned maintenance** is not, because it is not a "breach of security". ## Worked example: ransomware at a clinic A clinic's booking database is encrypted by ransomware. The investigation finds no evidence that anything was copied out. 1. **Is it a breach?** Yes. Patients' appointment data has been made unavailable by a security failure, so this is at least an availability breach. The lack of exfiltration evidence rules out nothing about availability. It only changes the confidentiality question, which stays open until the investigation can answer it. 2. **Does it have to be notified?** That is a separate question. Under **Art. 33(1)** the controller notifies the supervisory authority unless the breach is *unlikely to result in a risk* to people's rights and freedoms. The EDPB guidelines give examples in both directions. Patient data that is unavailable, even for a while, can put people at risk because appointments and treatment are disrupted. Data restored from a backup in good time, with no other malware, may not need reporting. 3. **Does it have to be recorded?** Yes, always. **Art. 33(5)** requires the controller to document *any* personal data breach, notifiable or not. ## Why the label matters Calling something a breach does not mean calling the regulator. It starts the GDPR's decision chain: 1. Is this a personal data breach under Art. 4(12)? 2. If yes, record it (Art. 33(5)). 3. Is it likely to result in a risk to individuals? If yes, notify the supervisory authority (Art. 33(1)). 4. Is it likely to result in a *high* risk? If yes, also tell the affected individuals (Art. 34(1)), unless an Art. 34(3) exception applies. A team that only looks for "data stolen" will miss availability and integrity breaches entirely. Those breaches then never reach the record or the risk assessment, and the controller cannot show the supervisory authority that it complied. ## Common traps - **"No exfiltration, so no breach."** Wrong: loss of access and destruction are breaches in their own right. - **"It was an accident, so it doesn't count."** Wrong: the definition says "accidental or unlawful". - **"Any GDPR violation is a breach."** Wrong: the term is limited to security failures. - **"Not notifiable means nothing to do."** Wrong: the Art. 33(5) record is still required.

  • Under the GDPR, is a system outage during planned maintenance a personal data breach?
    No. EDPB Guidelines 9/2022 say personal data that is unavailable because of planned system maintenance is not a 'breach of security' under Art. 4(12). An unplanned outage caused by a security incident is different: it can be an availability breach. Like any breach, it is documented under Art. 33(5) even if it does not need notifying.
  • Under the GDPR, does a breach have to involve an outside attacker?
    No. Art. 4(12) covers 'accidental or unlawful' events, and the EDPB notes that security incidents include failures inside the organisation's own processing. A misaddressed email, a lost device or a bad deployment that corrupts records can all be personal data breaches.

saying these in an interview costs you the question

  • A breach only happens when an attacker copies personal data out.
  • Ransomware with no sign of exfiltration is not a GDPR breach.
  • An accidental loss doesn't count because nobody acted maliciously.
  • Processing without a lawful basis is itself a 'personal data breach'.
  • A breach that doesn't need notifying doesn't need recording either.
open as a page

Under GDPR Art. 33, when does the 72-hour clock start, and what must the notification to the supervisory authority contain?

level: middleimportance: must knowfreq 72%

basics

~20 s

Under GDPR Art. 33(1), the controller notifies without undue delay and, where feasible, within 72 hours of becoming aware of the breach. The notice gives at least the Art. 33(3) items and may be completed in phases.

open as a page

Under the GDPR, a laptop with full-disk encryption is stolen and its key is held elsewhere; must anyone be notified?

level: middleimportance: must knowfreq 58%

basics

~20 s

Under the GDPR the theft is still a breach and is recorded. With effective encryption, an uncompromised key and another copy of the data, it is usually unlikely to cause risk, so neither the authority nor individuals are notified.

open as a page

Under GDPR Art. 37, when must an organisation designate a Data Protection Officer, and could its CTO hold that role?

level: middleimportance: should knowfreq 54%

basics

~20 s

Under GDPR Art. 37(1), a DPO is mandatory for public authorities, and where core activities involve large-scale regular and systematic monitoring or large-scale special-category or criminal data. A CTO is a poor fit: Art. 38(6) bars conflicting duties.

open as a page

Under the GDPR, a spreadsheet of customer records is emailed to the wrong business partner, who confirms deletion; must you notify, and what goes in the breach record?

level: seniorimportance: should knowfreq 46%

basics

~20 s

Under the GDPR it is a confidentiality breach whatever the recipient does. A trusted partner's confirmed deletion may make risk unlikely, so no notice may be due, but Art. 33(5) still requires recording facts, effects and remedial action.

open as a page

Under the GDPR, when your processor discovers a breach of your customers' data, who must notify whom, and when does your 72-hour clock start?

level: seniorimportance: should knowfreq 50%

basics

~20 s

Under GDPR Art. 33(2), the processor notifies the controller without undue delay, with no risk assessment first. Per EDPB guidance, the controller is in principle aware once informed, and then owns the Art. 33 and 34 decisions.

open as a page