When we hear about a breach, we tend to imagine a huge scandalous data breach of massive proportions where all the data gets leaked to some malicious criminal entity on the internet. Whilst that may at times be the case, it is not the only scenario where an incident could be considered a breach.
What is a breach?
Under GDPR a personal data breach is defined as:
[dt_quote type=”pullquote” layout=”left” font_size=”big” animation=”none” size=”1″]a breach of security leading to the [dt_highlight color=”” text_color=”” bg_color=””]accidental[/dt_highlight] or unlawful destruction,[dt_highlight color=”” text_color=”” bg_color=””] loss[/dt_highlight], alteration, unauthorised disclosure of, or [dt_highlight color=”” text_color=”” bg_color=””]access[/dt_highlight] to, personal data transmitted, stored or otherwise processed;[/dt_quote]
I’ve highlighted 3 keywords on purpose.
- A database administrator (dba) accidentally dropping a table containing personal data would qualify as a breach.
- An employee passing by a colleague’s work station and seeing a list of client names on their screen in passing, even though it was unintentional, is a breach.
- Forwarding an email thread without cleaning it up, wherein the thread there might be personal information, that the person receiving the email, does not need to know is a breach.
- Not shredding the list of colleagues and their lunch orders with their dietary requirements and sharing it directly with the delivery guy could also be considered a breach.
- Organising a small company event, and taking a couple of pictures and uploading it directly to the company’s social media page without making sure you have everyone’s consent is a breach.
These occurrences are so mundane, so common, that most of the time, we do not tend to think of these instances as breaches, but in reality they are.
Breach Notification
Before anyone starts panicking about notification to the supervisory authorities and the data subjects, keep in mind that not every breach requires notification. It requires logging and record keeping but not necessarily reporting and notification.
Article 33 of the GDPR states:
[dt_quote type=”pullquote” layout=”left” font_size=”big” animation=”none” size=”1″]In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55,[dt_highlight color=”” text_color=”” bg_color=””] unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons[/dt_highlight]. Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay[/dt_quote]
In most of the above examples, no harm is likely to come to the individuals whose data has been breached.
The dba can restore the data from the back-up. If no back-ups are available then your IT department has bigger problems than a notification to the controller or supervisory authority…. Just saying…
The employee who saw the list of client names is most probably under an employment NDA.
The email thread is debatable, depending on the information within the thread and to whom it was forwarded. The same applies for the employee names and their dietary requirements and the photo on social media. In this case, as soon as discovered, I would personally advise the person, not as part of a notification obligation but as a common human courtesy. In the case of the photo, it should also be taken down.
Record Keeping
These breaches may not require a notification, but they must be recorded and analysed. If something can be done to lessen the probability of re-occurrence, than it should also be documented, followed upon and actioned. Though remediation and risk mitigation seem like big words and complicated processes these can sometimes be very simple; A reprimand, a training session, a general company wide email to raise awareness could all contribute to lessening the probability of such a risk reoccurring.
Quoting from the Regulation:
[dt_quote type=”pullquote” layout=”left” font_size=”big” animation=”none” size=”1″]The controller shall document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken. That documentation shall enable the supervisory authority to verify compliance with this Article[/dt_quote]
Documentation is important for several reasons some of which are:
- Documenting these incidents/breaches will raise awareness in and of itself.
- Indicative of a larger issue when the same breach repeats itself.
- Contributes towards your risk register
- Gives confidence in case of an audit.
The first 3 are pretty self explanatory and I do not feel the need of going into them. The 4th item however could do with some more detail. Place yourself in an auditors’ shoes. Imagine you are auditing a company that claims they never had a breach so they don’t have any such records. Keeping in mind how wide ranging the definition of a breach is and how frequently these happen during every day operations, what would you think?
My personal thoughts – 2 options
- They don’t know what they’re talking about and hence their privacy program in all probability has a number of gaps.
- They’re hiding something, possibly a larger breach.
Either way, not very good thoughts for an auditor to have. Especially if that audit is being done by or on behalf of a supervisory authority who also has the power to slap you with fines of €20 million or more.
Summary
To summarise :
- breaches can be small everyday occurrences,
- claiming to never have had a breach is a bad idea,
- documentation is good.
Till the next one.
Would you like be notified when new posts come out? Drop us a note via the contact us section and we’ll add you to our mailing list.