[BreachExchange] The GDPR and the European double breach whammy

[Audrey McNeil]

https://www.cloudfoundry.org/blog/the-gdpr-and-the-
european-double-breach-whammy/

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.

Documenting:

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20180410/cb5493a6/attachment.html>