The GDPR and the European double breach whammy
The old one-two punch: Protect yourself from data and security breaches through prevention and preparation.
Data and security breaches are a hot topic across the world. The EU General Data Protection Regulation (GDPR) has a specific focus on data breaches. Another piece of legislation, the EU Network and Information Security (NIS) Directive, focuses on security breaches. In conversations with customers, I still get many questions around the actual implementations, so a quick refresh below. But let me start with the obvious.
Prevention is better than the cure, so invest and prepare.
Nobody wants to experience a breach. Apart from its impact to users, it has a huge brand and financial impact. As data becomes a central point of business operations, the potential risk for a breach has never been so high. A big focus should therefore be on prevention. This means investing in security measures to ensure that only the right people have access to the data, and that this access is limited to only the data necessary to perform their roles. Organisations need to look at their collection of data, management and the point of data deletion (if there is one), as part of a data lifecycle and stewardship. One example: during testing stages, testers love to use real life (personal) data. This however means that personal data potentially finds its way into other databases. You could instead reduce risk by using masked or synthetic data in test environments.
You should always prepare for the worst. Draw up remediation and response plans, train your people to identify signs of a breach and to report as soon as they expect something has gone wrong.
What if something does go wrong?
Under the GDPR, you will have to report to the appropriate authorities within 72 hours. In some cases, you will have to report to the users directly. Simple, right? Well, as most practitioners probably know, the real world is a bit more complex than that. To that end, the EU member state data protection authorities (DPAs), released some guidance in February. A quick overview:
What triggers notification?
A breach needs to result in a risk to the rights and freedoms of individuals. If it doesn’t, you are off the hook…kind of (see below regarding the documentation obligation). If it does, you will have to report to the authorities.
Assessing risk/high risk.
Assessing this risk is a combination of the severity of potential impact and likelihood of it occurring, using a range of factors.
When to report?
Within 72 hours as of the moment “there is a reasonable degree of certainty that a breach occurred.” It is not explicitly stated that this awareness is from the moment a person in the company notices something or when a team investigating a potential breach has such level of certainty. So, if you go with the latter, better to document that process. In case you are a processor, you need to report to the controller “without undue delay.” The clock for the controller starts the moment the processor became aware of a breach, even if the processor hasn’t informed the controller yet. Increased pressure and contractual language from the controller towards the processor regarding their notification obligations will be the natural result.
To whom should you report?
If the breach is isolated to one Member State, you would report to the respective DPA in that member state. If the breach affects individuals across borders, then you report to your lead DPA (we could devote a whole blog on that topic in itself).
Do I need to report to users individually?
If there is a high risk to the rights and freedoms of individuals, yes, and notification via a direct, dedicated message to affected users is preferred. If this is not possible and public notification is required, a website banner or advert in print media is deemed sufficient. It is important to note that according to the guidelines, a press release or corporate blog is not enough.
In line with the overall focus on documentation in the GDPR, it is recommended to keep track of an internal register detailing: the cause of the breach; what took place; what data was affected; what were the consequences; what remediation steps have you taken; what is the reasoning behind the decisions you made; and what proof of communication can you provide. If there is an audit and you can’t provide answers to these questions, you will have some more explaining to do.
And here is the double whammy:
If a data breach occurs because of a security breach, you risk an additional fine. Also, you might be required to report the data breach under the GDPR but also the security breach under the Network and Information Security (NIS) Directive.
Prepare, aim for global approach (as much as possible)
To date, there is scattered implementation guidance for the security breach under the NIS. Another complicating factor is that many companies operate on a global basis and are faced with other breach notification regimes with potential divergent requirements and timelines. Unfortunately, I don’t expect global harmonization of requirements any time soon. The best you can do is prepare, be consistent as much as possible across the world, and act in a transparent way.
How do you plan to prepare? What questions do you have? We welcome you to comment below on your thoughts.