By now everyone should be familiar with the phenomenon of massive data breaches. It’s no longer news when you can read about private data leaks and breaches in daily press on a regular basis. It’s a trend that one must accept. It just happens. But I find it puzzling that many people are surprised that those hundreds of millions of private data breaches is only a tiny fraction of a general picture. In reality, there are far more breaches nobody knows about - simply because they are of a smaller scale or based locally. This is not news worthy.
Big organizations (such as LinkedIn, Yahoo) have massive user bases, which naturally makes the breaches more severe (and louder). Smaller organizations have much fewer users so on a scale of the world or even a country this may look less severe (and often less known too). This means less visibility, and unfortunately also less sensitivity. You often won’t hear about breaches of smaller players. Many never make it to the public anyway. There are of course reports, statistics (for example, this one about medical data breach incidents in USA), and so on, but affected users risk not being made aware that their important information has been stolen.
Private data breaches are ubiquitous, but you aren’t hearing about many of them. Many affected users don’t hear about it, too.
This is obviously putting users at risk of losing control over data, and over life even. The risk often might be so high that the situation cannot be remediated easily, or not at all. That’s why it’s important to guarantee and offer transparency and help to users. Sadly, this was not always the case.
Mandatory breach notification
Fortunately, things in Europe will soon improve! Thanks to the European General Data Protection Regulation (GDPR), which will require companies and institutions to report data breaches and - perhaps what’s more - in many cases will force them to notify the public, too. In this post I provide a critical analysis of the recent WP29 breach notification guidelines. As you will notice, I point out that there many ambiguous points where decisions will need to be made by organizations, following their own respective data protection and privacy strategies. It’s not always obvious.
My analysis answers these points:
- “When is a breach serious?” (when it brings high risks to individuals)
- “I’m an organization, when do I report breach?” (often)
- “Do I need to prepare a plan?” (oh, yes)
One takeaway is that organizations will have to be able to detect and respond to incidents. Another - that they will need to have a hot-line to people versed in security and privacy, both in terms of technology and other higher-level aspects.
It’s also important to realize GDPR is not only affecting European organizations. If, for example, a US-based company has users in Europe - GDPR must be followed. Same about breach notification. This will undoubtedly result in more transparency to US users, thanks to the obligations in Europe.
Breach notification and penalties
Information about breaches will need to be passed to supervisory bodies (e.g. UK’s ICO, French CNIL, etc.). Furthermore, in many cases, organisations will need to report a breach to individuals directly, too.
The stake and risk for organizations? Not following might be costly: GDPR fines for not following are (max): €10M or 2% worldwide turnover (whichever is higher).
Organizations will no longer be able to hide serious breaches out of fear for their stock value. That’s because this “€10M” or “2%” is something that obviously shifts risk assessment in the right places (e.g. CFO).
What is a breach?
GDPR considers breach from the user perspective. Not every security incident is a breach. Breach is not only about stolen or leaked personal data. It’s much broader and should also encompass other cases, such as: loss of availability, quality, alteration, unauthorized access (someone hacked your company server, or a malicious employee did it inadvertently, or on purpose) or disclosure (leak), etc. Basically it might boil down to confidentiality, availability, integrity, but with a user-oriented specificity.
Examples of breaches
If ransomware encrypts a company database storing personal data and there were no backups, this is a breach. Even if stolen items weren’t featured in a Financial Times story (but then there’s obviously also a breach, and the organisation has much less time to handle it in line with GDPR).
On the other hand, if an organisation can guarantee that an incident is reasonably not resulting in any material damage, this need not be reported (to the public). So, for example, if a stolen database or a USB stick with sensitive data was protected (e.g. strong encryption that cannot be reversed), data can be considered safe - and no notification needs to be issued. However, if someone will accidentally put an unencrypted database backup on a company website, this is a different story.
The eternal question? Yes, if your company marketing division inadvertently sends a direct e-mail to many recipients and put the addresses in “to” or “cc” (for all recipients to see them), and not “bcc” - this should also be considered a breach. It should be reported to supervisory authority, and sometimes to the users too.
Context often matters. There will be events where it won’t be immediately clear whether a breach is subject to mandatory reporting. Imagine a situation where a company database (encrypted) is stolen. It’s supposed to be secure. But then, what if it’s not clear if encryption keys were safe or strong? What if someone gains unauthorized access to an account with elevated privileges and say, steals a bitcoin wallet? No personal data may be directly involved. But if there is as a risk that this account could be used to access them, this needs to be classified as potentially unauthorized access to data.
Consequently, we’re speaking about technology, controls, contingency plans, strategies.
Risks to users
GDPR requires reporting breaches to users when a breach may result in high risk to the rights and freedoms. This means that when a data breach occurs, organizations will need to quickly perform a rather specific risk assessment task. Organisations will need to assess what could be the possible consequences to users. This assessment is different than the usual risk assessment from information security (that concerns the security of systems). It is also different than the one from data protection impact assessment (DPIA) - unless the DPIA was done properly, thoroughly and exceptionally well. Even then, some specific risks directly resulting from a breach may still not have been included in the data protection impact assessment; its focus is indeed different - more broad and general. Likelihood and severity of a specific breach must, therefore, be properly analyzed.
This means that companies will have to have access to competences able to make broad risk-assessment related to security and privacy breaches (whether in-house or external advice).
This is because in order to properly understand the risk to users one may need to consider a number of complex aspects beyond the mere information about the type of breach, but also its context. What kind of data is affected? How many users are affected? For example, is it easy to de-identify the data? How are the users affected? Were any of the affected users vulnerable, for example, children or disabled people? And so on…
Let’s summarise some points.
- Companies must be able to detect that a breach occurred
- Companies will need to be able to act fast and assess risk
- Companies must know how to perform fast and specific user-centric risk assessment
- Companies will need to report breaches to supervisory organizations
- Companies will often need to report breaches to users publicly
The last point is interesting. How to let your users know that a breach has occurred? The wording must be wise. Users need to obtain actionable information. However, companies will want to follow specialized security and privacy PR good practices. It’s not only to inform, but also to limit damage to the company itself. You can’t imagine simply mass-mailing people that “We got hacked and this and that was affected. All data is lost. Goodbye!” (hyperbole intended), which would obviously cause additional damage to the company itself. Often even simple words matter. Try to omit some points and someone will spot there is lack of honesty and it will then backfire.
Reporting a breach
Breach notification steps can be summarized by a simple few points. Beware, these may not be so simple in practice.
What to do when a breach is detected?
Personal data likely concerned? You’ve got max 72 hours to notify the supervisory authority. My advice? If it can be done sooner than that, almost always do so. Being open and polite might be helpful in case of any potential future fallout.
If you’re not notifying within 72 hours, it’s a requirement to have good reasons for doing so. Those reasons must be well documented. Have a look at the process Cloudflare documented relatively recently (https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/), although one could argue when a notification to supervisory authorities should be sent in that case. That said, companies need to have the time to investigate potential incidents. Updates can be sent in phases when new information is available.
When to inform the public?
Personal data breach could mean a high risk to rights (privacy is one of them) and freedoms of individuals? Users need to be informed without an “undue delay”. You must therefore interpret it as “as soon as possible”. It’s not merely an obligation, but also an opportunity and a chance for companies: being upfront and honest. Notification should, of course, include appropriate details and possible steps the user can take.
How should the users be contacted? The medium must be effective. For example: directly, by phone, SMS, instant messaging, e-mail, and so on. If this is not possible or not effective - go with a public disclosure. In many cases, public disclosure should accompany other forms of contact anyway, as a good practice.
Please note that selecting appropriate channels is a matter that will also be judged by the supervisory authority, should there be a risk of fines following.
Not sure what “high risk” means? Contact competent people, or the supervisory authority. However, I cannot imagine what would happen if many organizations would choose to (needlessly) inform supervisory authorities with all detected incidents. Obviously, a flood. This is a challenge to Data Protection Authorities, but also organizations, which would need to know on their own which breaches to report, and which not to.
When a notification to individuals is not needed?
Notification is not needed when:
- No breach - congratulations!
- Technical controls and measures are in place that made the data protected
- Organisation followed right steps to remediate the situation immediately and containing an incident that did not escalate
- Disproportionate effort is required to contact individuals
Breach notification and DPIA
If a breach occurs, DPIA likely needs to be updated. This is especially the case if some of the aspects in DPIA will be concerned.
Mandatory breach notification is positive both for organizations and users. Organizations will find them problematic, but some may start treating them as an opportunity. Users, on the other hand, will have it easier, faster and simpler to understand when their data is affected and that an action on their side is needed to remain safe. That’s because it will be an organizations responsibility to let users know about the needed actions.
GDPR breach notification requires planning and specific processes, structures or even systems at organizations. It’s not only incident detection and management, but also communication to users. Teams with a good understanding of security and privacy on many levels. Sometimes, the risk to users needs to be established fast. But companies must also have in place a system and process for handling breach notifications.
The process of breach notification will be one of the most challenging to organizations. That’s because this process is not only about communicating, but also detecting, interpreting, and assessing - all need to be happening fast. If you’d like to discuss additional aspects, feel free to reach out.