Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

When do we…

When does personal data make a security incident a GDPR breach?

4 decision pointsThe pack behind this answer: Security Incident Management

Add to board 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.
  1. 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

  2. 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

  3. 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.

    In the pack

  4. 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.

    In the pack

  5. 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.

    In the pack

  6. 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.

    In the pack

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

Practical checklist

  1. Bring in the Data Protection Officer, or the privacy lead where none is appointed, in the first hour.
  2. List the personal data on the affected systems, mailboxes, devices and files, and whose it is.
  3. Ask whether anyone not entitled to it saw or reached it, treating it as possible until the logs show otherwise.
  4. Ask whether any of it was altered, by attack or by mistake.
  5. Ask whether any of it was lost, destroyed or out of reach, even for a time.
  6. Put every breach in the breach record, notified or not (RD-08).
  7. 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