When do we…
When does personal data make a security incident a GDPR breach?
Add to board memoOpen the memo
The short answer
- Recommendation
- Treat it as a personal data breach whenever personal data was disclosed to or reached by someone not entitled to it, altered, or lost or out of reach, even for a time. Record every breach, then decide who must be told from the risk to the people concerned.
- Reasoning
- The GDPR definition, as the pack quotes it, needs no attacker and no data leaving the organisation: an accident counts, and so does data that is only made unavailable. A personal data breach is two problems at once, an incident to contain and a legal decision about who must be told. An incident that only touches personal data is not a breach when the evidence shows nothing was disclosed, altered or lost. Protection such as encryption lowers the risk and leaves it a breach. Whether to notify is a separate question.
- Considerations
- Where you cannot yet tell whether personal data was involved, reached, changed or lost, take the breach branch until the evidence rules it out.
- One incident can be more than one kind. Ransomware that encrypts records is an availability breach, and a confidentiality breach too if the data was copied first.
- The notification clock runs from awareness. In the pack, notification to the supervisory authority, where needed, is due within 72 hours of awareness (RD-06), and a report is never held back to avoid a deadline.
- If you process the data for another organisation, tell that organisation without undue delay; it decides whether to notify. This is not legal advice.
The decision, step by step
Select any step for the reasoning behind it and where the pack covers it.
- Start
- Step
- Decision
- Outcome
Keyboard: Tab to a step, arrow keys move along the flow, Enter pins its explanation, + and − zoom, 0 fits the diagram, Esc closes. The text version below has the same content.
Where a step quotes a number, it is the default in the CISO Times pack. Your own standard may set a different one.
Read as text
The same flow written out: each step, its reasoning and where the pack covers it. 11 steps.
Start
An incident may involve personal data
Personal data is any information relating to an identified or identifiable living person. The pack's examples show where it sits in an incident: a mailbox, shipping records on office PCs, a spreadsheet attached to an email. A personal data breach is two problems at once: an incident to contain, and a legal decision about who must be told.
In the pack
- P09-A08 Personal Data Breach Response PlaybookScenario and triggers
- P09-A08 Personal Data Breach Response PlaybookDefinitions
Step
Bring in the Data Protection Officer within the hour
In the pack the Data Protection Officer, or the privacy lead where none is appointed, is told within the first hour whatever the severity. The data owner says what data was involved, whose it is and how sensitive. The question 'whose records are these, and what is in them?' should take minutes.
In the pack
- P09-A08 Personal Data Breach Response PlaybookFirst-hour actions
- P09-A08 Personal Data Breach Response PlaybookInvolve the Data Protection Officer
- P09-A08 Personal Data Breach Response PlaybookContain
- P09-A08 Personal Data Breach Response PlaybookRecover
Decision
Does the incident touch personal data at all?
List the personal data held on the affected systems, mailboxes, devices and files, and whose it is. If you cannot yet rule personal data out, take the yes branch until you can. If there is none, the privacy track closes; record the assessment and its evidence.
- Yes, or not known: Was it disclosed to, or reached by, someone not entitled to it?
- No: No personal data: the GDPR questions do not apply
In the pack
- P09-A08 Personal Data Breach Response PlaybookThe tree
- P09-A06 Ransomware Response PlaybookContain (rule K7)
Decision
Was it disclosed to, or reached by, someone not entitled to it?
A breach of confidentiality. Examples in the pack: an email to the wrong recipient, a stolen unencrypted laptop, an attacker reading a mailbox, an employee looking up a neighbour's record. The misdirected spreadsheet of 212 customers' names, addresses and order histories was one, even though the recipient deleted it the same day. If the logs cannot yet show whether data was reached or taken, treat it as possible.
- Yes, or not known: It is a breach, even if the data was encrypted
- No: Was it altered without authority, or by mistake?
In the pack
- P09-A08 Personal Data Breach Response PlaybookIs it a personal data breach?
- P09-A08 Personal Data Breach Response PlaybookINC-2026-016: customer order spreadsheet sent to the wrong business customer
- P09-A06 Ransomware Response PlaybookDecision tree (rule D2)
Decision
Was it altered without authority, or by mistake?
A breach of integrity. Examples in the pack: bank details changed on a supplier or payroll record, addresses overwritten by a faulty import, records tampered with. A mistake counts as much as an attack. If you do not yet know which records changed, take the yes branch.
- Yes, or not known: It is a breach, even if the data was encrypted
- No: Was it lost, destroyed, or out of reach, even for a time?
In the pack
- P09-A08 Personal Data Breach Response PlaybookIs it a personal data breach?
Decision
Was it lost, destroyed, or out of reach, even for a time?
A breach of availability. Records encrypted by ransomware count even if nothing was taken; so does a database deleted with no backup. In the pack's ransomware example, shipping records on the encrypted PCs were out of reach for about a day and a half: an availability breach, recorded though not notified. If you cannot yet tell, take the yes branch.
- Yes, or not known: It is a breach, even if the data was encrypted
- No: Not a breach: record the assessment and its evidence
In the pack
- P09-A08 Personal Data Breach Response PlaybookIs it a personal data breach?
- P09-A08 Personal Data Breach Response PlaybookINC-2026-014: the GDPR part of the ransomware incident
Outcome
Not a breach: record the assessment and its evidence
Not every incident touching personal data is a breach. In the pack's example a staff mailbox holding personal data was taken over, but the audit log showed nothing had been read out or forwarded: recorded as assessed, not a breach. Keep the assessment and its evidence; it answers the question if it is ever asked. Revise it if new evidence appears.
In the pack
- P09-A08 Personal Data Breach Response PlaybookIs it a personal data breach?
- P09-A04 Incident Classification, Severity & Escalation MatrixClassifier
Outcome
No personal data: the GDPR questions do not apply
Record the assessment and close the privacy track. The incident still goes through the rest of the reporting screen: NIS2, DORA where it applies, contracts, insurance and a crime report can each apply without any personal data.
In the pack
- P09-A08 Personal Data Breach Response PlaybookThe tree
- P09-A08 Personal Data Breach Response PlaybookThe other reporting questions
Step
It is a breach, even if the data was encrypted
One incident can be more than one kind: ransomware that encrypts records is an availability breach, and a confidentiality breach too if the data was copied first. Protection lowers the risk and leaves it a breach. A lost laptop with full-disk encryption on, its key not with it and its data backed up is still a personal data breach. Its protection is why it can be Severity 3 and unlikely to need notification.
In the pack
- P09-A08 Personal Data Breach Response PlaybookIs it a personal data breach?
- P09-A08 Personal Data Breach Response PlaybookSeverity mapping
- P09-A04 Incident Classification, Severity & Escalation MatrixCategories
Step
Put it in the breach record, notified or not
Every personal data breach goes in the breach record: what happened, when and when you became aware, the data and people concerned, the effects, the risk assessment, whether the authority and the people were told and why, and the remedial action. The authority may ask to see it, including for breaches that were not notified.
In the pack
- P09-A08 Personal Data Breach Response PlaybookComplete the breach record (rule RD-08)
Outcome
Assess the risk to the people to decide who is told
Whether to notify turns on the risk to the people whose data it is: unlikely to result in a risk, a risk, or a high risk. The clock for notifying the supervisory authority runs from awareness, so start the assessment now. The misdirected spreadsheet was a risk and was notified; the ransomware availability breach was unlikely to result in a risk and was recorded only.
In the pack
- P09-A08 Personal Data Breach Response PlaybookAssess the risk to the people concerned
- P09-A08 Personal Data Breach Response PlaybookStart the clock at awareness
Practical checklist
- Bring in the Data Protection Officer, or the privacy lead where none is appointed, in the first hour.
- List the personal data on the affected systems, mailboxes, devices and files, and whose it is.
- Ask whether anyone not entitled to it saw or reached it, treating it as possible until the logs show otherwise.
- Ask whether any of it was altered, by attack or by mistake.
- Ask whether any of it was lost, destroyed or out of reach, even for a time.
- Put every breach in the breach record, notified or not (RD-08).
- Assess the risk to the people concerned as unlikely, a risk or a high risk, choosing the higher level when in doubt.
Evidence to have ready
- The assessment and its evidence for an incident judged not a breach, such as the audit log showing nothing was read or forwarded.
- The breach record: kind of breach, what happened, when it happened and when you became aware, the data and people, effects and remedial action.
- The risk assessment with its factors and reasons, and whether the authority and the people were told, when, or why not.
- The Data Protection Officer's assessment and the executive incident lead's decision, with the date.
Assumptions
- You are the controller of the data. If you process it for another organisation, you tell that organisation without undue delay and it decides whether to notify.
- The pack's definition and test follow the GDPR as the pack states it. National rules and your supervisory authority's guidance may add detail; this is not legal advice.
Not covered here
- Whether a breach must be notified, to whom and by when. That is “When do we have to notify a regulator, and under which regime?”.
- Which reporting clock runs first when other regimes apply too. That is “When one incident triggers NIS2, DORA and GDPR at once, which clock runs first?”.
- Whether the event is a security incident at all. That is “How do we decide whether something is an incident or just an event?”.