Personal-data breach

A personal-data breach happens when the security of personal data is compromised. It can affect confidentiality, integrity or availability: information may be seen by the wrong person, altered incorrectly, lost, destroyed or made unavailable when needed.

Breaches are not limited to hackers. Common examples include emailing a file to the wrong recipient, losing an unencrypted device, exposing a database through a configuration error, deleting records without a recoverable backup, changing a person’s record incorrectly or allowing a supplier account to be compromised.

A system outage with no personal-data impact may be a security incident but not a personal-data breach. An event involving personal data may be both. Do not delay triage while debating labels: record what happened, contain it, preserve evidence and determine whether personal data was affected.

The notification trigger, risk threshold and deadline differ by jurisdiction. Some clocks begin when the controller becomes aware, not when the incident first occurred or when the investigation ends. Record those timestamps separately.

Activate the incident or breach-response plan. Escalate to the responsible privacy and security contacts. Contain the event without destroying evidence. Record when it occurred, was detected and became known to the controller; what systems, people and data are affected; likely cause; recipients; protective measures; and actions taken.

Assess possible harm to people. Consider the sensitivity and volume of data, identifiability, whether protection such as encryption remains effective, who has the information, the likelihood of misuse, vulnerable groups and possible physical, financial, reputational or other consequences.

An employee sends a spreadsheet of customers to the wrong external address. The organisation asks the recipient to delete it, checks whether it was opened, preserves the email evidence, assesses the fields and affected people, records its awareness time and applies every relevant notification test. Recalling the email does not erase the need for assessment.

Notification and communication

Do not assume every breach must be announced publicly, or that low apparent risk permits silence in every jurisdiction. Check the selected lens immediately. Regulator and individual notifications may have different thresholds, deadlines, content and channels.

Where people must be informed, use clear language: describe what happened, the likely consequences, what the organisation is doing, what the person can do and how to get help. Avoid speculation and do not conceal material facts.

Suppliers and overlapping jurisdictions

Contracts should require processors and other suppliers to alert the controller quickly enough for it to assess every applicable clock. A supplier’s promise to notify “within 72 hours” may be too slow where the controller faces a shorter deadline. If people, establishments or systems span jurisdictions, run each notification test independently and coordinate communications without assuming that reporting in one country satisfies another.

After the immediate response

Complete the investigation, record decisions and evidence, remediate the cause and review the response. Maintain a breach register even for incidents that did not meet an external-notification threshold where the applicable framework expects accountability records.

Related terms: breach notification; security incident; risk of harm; DPO; controller; processor; sensitive data; response plan

To be expanded during editorial review.