Note: One of my first “big” pieces on the GDPR.  Looking over it now,  the ideas on what constitutes a breach  are still relevant for post-GDPR laws that came about in the US.

The General Data Protection Regulation (GDPR) is set to go into effect in a few months — May 25 2018 to be exact. While the document is a great read for experienced data security attorneys, it would be nifty if we in the IT world got some practical advice on some of its murkier sections — say, the breach notification rule as spelled out in articles 33 and 34.

The GDPR’s 72-hour breach notification requirement is not in the current EU Directive, the law of the land since the mid-1990s. For many companies, meeting this tight reporting window will involve their IT departments stepping up their game.

With help from a few legal experts — thanks Sue Foster and Brett Cohen — I’ve also been pondering the language in the GDPR’s notification rule. The key question that’s not entirely answered by GPDR legalese is the threshold for reporting in real-world scenarios.

For example, is a ransomware attack reportable to regulators? What about email addresses or online handles that are exposed by hackers?

Read on for the answers.

Personal Data Breach versus Reportable Breach

We finally have some solid guidance from the regulators. Last month, the EU regulators released some answers for the perplexed, in a 30-page document covering guidelines on breach notification – with bonus tables and flowcharts!

To refresh fading memories, the GDPR says that a personal data breach is a breach of security leading “to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed.”

This is fairly standard language found in any data privacy law — first, define a data breach or other cybersecurity event. This is what you’re supposed to be protecting against — preventing these incidents!

There’s also additional criteria for deciding when regulators and consumers have to be notified.

In short: not every data security breach requires an external notification!

This is not unusual in data security laws that have breach report requirements. HIPAA at the federal level for medical data and New York State’s innovative cyber rules for finance make these distinctions as well. It’s a way to prevent regulators from being swamped with breach reports.

In the case of the GDPR, breaches can only involve personal data, which is EU-speak for personally identifiable information or PII. If your company is under the GDPR and it experiences an exposure of top-secret diagrams involving a new invention, then it would not be considered a personal data breach and therefore not reportable. You can say the same for stolen proprietary software or other confidential documents.

Notifying the Regulators

Under the GPDR, when does a company or data controller have to report a personal data breach to the local supervising authority – what we used to call the local data protection authority or DPA in the old Directive?

This is spelled out in article 33, but it’s a little confusing if you don’t know the full context. In essence, a data controller reports a personal data breach — exposure, destruction, or loss of access—if this breach poses a risk to EU citizens “rights and freedoms”.

These rights and freedoms refer to more explicit property and privacy rights spelled out in the EU Charter of Fundamental Rights — kind of the EU Constitution.

I’ve read through the guidance, and just about everything you would intuitively consider a breach — exposure of sensitive personal data, theft of a device containing personal data, unauthorized access to personal data — would be reportable to regulators.

And would have to be reported within 72-hours! It is a little more nuanced and you have some wiggle room, but I’ll get to that at the end of this post.

The only exception here is if the personal data is encrypted with state of the art algorithms, and the key itself is not compromised, then the controller would not have to report it.

And a security breach that involves personal data, as defined by the EU GDPR, but that doesn’t reach the threshold of “risks to rights and freedoms”?

There’s still some paperwork you have to do!

Under the GDPR, every personal data breach must be recorded internally: “The controller shall document any personal data breaches, comprising the facts relating to the personal data breach”— see Article 33(5).

So the lost or stolen laptop that had encrypted personal data or perhaps an unauthorized access made by an employee — she saw some customer account numbers by accident because of a file permission glitch — doesn’t pose risks to rights and freedoms but it would still have to be documented.

There’s a good Venn diagram hidden in this post, but for now, gaze upon the flowchart below.

 

Let’s look at one more GDPR reporting threshold scenario involving availability or alteration of personal data.

Say EU personal data becomes unavailable due to a DDoS attack on part of a network or perhaps it’s deleted by malware but there is a backup, so that in both cases you have a loss albeit temporary — it’s still a personal data breach by the GDPR’s definition.

Is this reportable to the supervising authority?

It depends.

If users can’t gain access to say their financial records for more than a brief period, maybe a day or two, then this would impact their rights and freedoms. This incident would have to be reported to the supervising authority.

Based on the notes in the guidance, there’s some room for interpreting what this brief period would be. You’ll still need, though, to document the incident and the decision making involved.

Breach Notification and Ransomware

Based on my chats with GDPR experts, I learned there was uncertainty even among the legal eagles whether a ransomware attack is reportable.

With the new guidance, we now have a clearer answer: they actually take up ransomware scenarios in their analysis.

As we all know, ransomware encrypts corporate data for which you have to pay money to the extortionists in the form of Bitcoins to decrypt and release the data back to its plaintext form.

In the GDPR view, as I suggested above, ransomware attacks on personal data are considered a data loss. When does it cross the threshold and become a reportable data breach?

According to the examples they give, it would be reportable under two situations: 1) There is a backup of the personal data but the outage caused by the ransomware attack impacts users, or 2) There is no backup of the personal data.

In theory, a very short-lived ransomware attack in which the target recovery quickly is not reportable. In the real world where analysis and recovery take significant time, most ransomware attacks would effectively be reportable.

Individual Reporting

The next level of reporting is a personal data breach in which there are “high risks to the rights and freedoms.” These breaches have to reported to the individual.

In terms of Venn diagrams and subsets, we can make the statement that every personal data breach that is individually reported also has to be reported to the supervising authority. (And yes, all Greeks are men).

When does a personal breach reach the level of high risks?

Our intuition is helpful here, and the guidelines list as examples, personal data breaches that involve medical or financial (credit card or bank account numbers).

But there are other examples outside the health and banking context. If the personal data breach involves name and address of customers of a retailer who have requested delivery while on vacation, then that would be a high risk and would require the individuals to be contacted.

A breach of contact information alone — name, address, email address, etc — alone may not necessarily require notification. But would require the supervising authority and individual to be informed if a large number of individuals are affected! According to the guidelines, size does matter. So a Yahoo-level exposure of email addresses would lead to notifications.

The guidelines make a point that if this contact information includes other sensitive data — psychological, ethnic, etc. — then it would be reportable regardless of the number of individuals affected.

Or if the contact information, email addresses say, are hacked from a children’s website and therefore the group is particularly vulnerable, then this would constitute a high risk and a notification to the individuals involved.

Breach Notification in Phases

While the 72-hour GDPR breach notification rule was somewhat controversial, it’s actually more flexible once you read the fine print.

The first key point is that the clock starts ticking after the controller becomes aware of the personal data breach.

For example, suppose an organization detects a network intrusion from an attacker. That 72-hour window does not start at this point.

And then there’s an investigation to see if personal data was a breach. The clock still doesn’t start. When the IT security team discovers with reasonable certainty that there has been a personal data breach, then the clock starts!

When notifying the supervising authority, the data controller can do this in phases.

It is perfectly acceptable to notify the supervising initially when there has been discovery (or the likelihood) of a personal data breach and to tell them that more investigation is required to obtain details — see Article 33(4). This process can take more than 72-hours and is allowed under the GDPR.

And if turns out to be a false alarm, they can ask the supervising authority to cancel the notification.

For personal data breaches in which it is discovered there is a high risk to the individual, the notification to affected “data subjects” must be made without “undue delay”— see Article 34(1). The objective is to inform consumers about how they’ve been affected and what they need to take to protect themselves.

Notification Details

This leads to the final topic in this epic post: what do you tell the supervising authority and individuals?

For supervising, here’s the actual language in Article 33:

• Describe the nature of the personal data breach including where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned;
• Communicate the name and contact details of the data protection officer or another contact point where more information can be obtained;
• Describe the likely consequences of the personal data breach;
• Describe the measures taken or proposed to be taken by the controller to address the personal data breach, including, where appropriate, measures to mitigate its possible adverse effects.

Note the requirement to provide details on the data categories and the approximate number of records involved.

The supervising authority can, by the way, request additional information. The above list is the minimum that the controller has to provide.

When notifying individuals (see Article 34), the controller also has to offer the following:

• a description of the nature of the breach;
• the name and contact details of the data protection officer or another contact point;
• a description of the likely consequences of the breach; and
• a description of the measures taken or proposed to be taken by the controller to address the breach, including, where appropriate, measures to mitigate its possible adverse effects.

The GDPR prefers that the controller contact affected individuals directly – rather than through a media broadcast.  This can include email, SMS text, and snail mail.

For indirect mass communication, prominent banners on websites, blog posts, or press releases will do fine.

“Likely to Affect”

The first key thing to keep in mind is that there are two different thresholds to apply in a GDPR breach: one for notifying customers, and the other for alerting the Data Protection Authority (DPA).

If the personal data that has been exposed is “likely to affect” a consumer, then they will need to be notified. This is a fairly low bar to reach.

According to the compliance attorney we spoke to, any personal data identifiers – say, email addresses, online account IDs, and possibly IP addresses — could easily pass the likely-to-affect test.

In addition, if the breached personal data contains more monetizable personal data – bank account numbers or other financial identifiers—  then you can say the breach is “likely to harm” the individual. In this situation, both the consumer and the DPA will have to be notified.

Breach Response: Not Just IT

The notification sent to the DPA in the likely-to-harm case also must include detailed information about the incident.

Besides describing the nature of the breach, the notification has to mention the types of data, the number of individuals, and the number of records exposed.

The company (or data controller in EU-speak) then need to describe any likely consequences of the breach as well as any mitigation efforts to be taken.

The notification to the DPA must be made within 72 hours or “a reasoned justification” given in cases where that window can’t be met.

Of course, you’ll need IT to provide the basic information about what types of data and number of records that were involved.

But according to the attorney, a breach or incident response team must be made up of more than IT!

Minimally, the response group should include a chief privacy officer, a legal representative if the CPO is not an attorney, risk management personnel, PR, and financial.

The point is that while IT is crucial for understanding the scope of the attack, a breach impacts so much more than just IT —regulatory, financial, and legal areas— those other experts have to be involved.

This Is Not Legal Advice

The GDPR breach notification guidelines that were released last month is about 30 pages. As an IT person, you will not be able to appreciate fully all the subtleties.

You will need an attorney—your corporate counsel, CPO, CLO, etc.—to understand what’s going with this GDPR breach guideline and other related rules.

That leads nicely to this last thought: incident response to a breach requires combined efforts of IT, legal, communications, operations, and PR, usually at the C-level.

IT can’t do it alone.

The first step is to have an incident response plan.

A great resource for data security and privacy compliance is the International Association of Privacy Professionals (IAPP) website: https://iapp.org/ .

The IAPP also have an incident response toolkit put together by our attorney friends at Hogan Lovells. Check it out here.