01
The short answer
Controllers and processors should plan ahead procedures to quickly detect and contain a breach, assess the risk to people, and decide whether to notify the data protection authority and communicate the incident to affected individuals.
If your company acts as a processor, three rules remain fixed: document every breach, notify the authority within 72 hours unless the risk is unlikely, and communicate it to individuals without undue delay when the risk is high.
02
What counts as a data breach
A personal data breach is a security breach leading to the destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. It is not only about losing data: it covers incidents affecting confidentiality, integrity or availability, whether accidental (an email sent to the wrong recipient, a lost USB stick) or deliberate, such as phishing.
03
The steps to put in sequence
Steps
- Detect and contain the incident as soon as it is discovered
- Assess the actual risk to the individuals involved
- Notify the data protection authority within 72 hours, unless the risk is unlikely
- Communicate to affected individuals without undue delay if the risk is high
- Always document details, assessment, effects and measures taken, even without notification
04
A hypothetical example
Scenario: an employee at an SMB mistakenly sends a customer list to the wrong external recipient. The team detects the send, blocks access to the file where possible, and assesses whether the exposed data (names, contacts) poses a risk to people. If the risk cannot be ruled out, the company notifies the authority within 72 hours and considers informing the affected customers, documenting each step.
05
Prevention and verification controls
- A unique identifier for each user and authentication to access systems
- Separate authorisation profiles based on actual needs
- Periodic review of authorisations and removal of outdated ones
- Data encryption and pseudonymisation where possible
- A dedicated security policy for remote work and personal devices (BYOD)
06
What a company can set up with the support of a software partner
A company can ask its software partner to set up a traceable incident register, with fields for detection date, description, people involved, risk assessment and measures taken. Distinct roles (who detects, who assesses, who notifies) and a consultable history help meet the required documentation discipline, which nonetheless remains an operational choice to define with the relevant professional.
07
Frequently asked questions
Is every security incident a data breach? No: all personal data breaches are security incidents, but not every security incident involves personal data.
Do you always have to inform affected individuals? No, only when the risk to them is high; in some cases, such as encrypted data with uncompromised keys, individual communication is not necessary but equally effective information must still be ensured.
Must an unreported breach still be documented? Yes: Article 33(5) requires documenting at least the fundamental details, the assessment, the effects and the measures taken.
08
Practical next step
Draft an internal procedure today with the five steps outlined and assign a responsible person for each phase, so you can respond without hesitation when needed.
FAQ
Frequently asked questions
What is the difference between a security incident and a personal data breach?
Every personal data breach is a security incident, but not every security incident involves personal data: it depends on what was exposed or affected.
How quickly must a breach be notified to the authority?
Within 72 hours of discovery, unless it is unlikely that the breach poses a risk to the individuals involved.
Do you always need to communicate the breach to affected individuals?
Only if the risk to them is high. In cases such as encrypted data with intact keys, individual communication is not mandatory but equally effective information must be ensured.
✓