In Part 2 of Double Dutch with Jonathan Armstrong, we unpack some survival tips from the Dutch AP’s enforcement action against Booking.com.

SUMMARY – Booking.com is a Dutch online travel agency that is headquartered in Amsterdam, whose mission is to “make it easier for everyone to experience the world.”  Well, more than 4,100 Booking.com customers did have an experience, though not one that made anything easier for anyone.  They had their personal data exposed when hackers accessed login credentials through the use of social engineering and other tactics.  Ultimately, the Dutch Data Protection Authority (AP) fined Booking.com €475,000 for failure to notify the regulatory authority of this data breach within the 72-hour statutory time frame prescribed by Article 33 of the GDPR.   

SURVIVAL TIP 1!  The 72-hour time frame to report a breach begins when you have identified the problem, not when you’ve found a solution.  Understand that there are distinct reporting obligations under GDPR Articles 33 (to regulators) and 34 (to affected individuals).   

SURVIVAL TIP 2!  Make sure that your internal processes are set up in a way that allows you to get information reported in a way that allows you to response quickly.  This applies to data processors as much as data controllers.

SURVIVAL TIP 3!  Even if you do not have a reporting obligation, analyze these incidents to see what you might have had to do under circumstances that would have required reporting, and what you could have done more effectively in the future.

SURVIVAL TIP 4!  Be proactive!  Invest in learning, invest in responsive processes, debrief after “near miss” events that do not require reporting to improve your response efforts.

SURVIVAL TIP 5!  When you are looking at GDPR compliance, make sure you understand and evaluate how compliance measures are applicable to your entire operation worldwide, not just the EU operations.

SURVIVAL TIP 6!  Make sure that each department understands their ownership responsibilities when it comes to a data breach event, and that you have a multidisciplinary response team that rehearses their response efforts.  

Matt: What is the Dutch enforcement action against Booking.com all about?

Jonathan: This is a case where the lead DPA system worked.  Booking.com, being a Dutch company based in the Netherlands, the lead DPA here was the AP.  This action is about a data breach.  Booking.com had issues with a database under its control, about 4,100 of its customers had their personal data exposed, and neither their customers nor the regulator were told quickly enough. 

Remember that there are two obligations to notify with regards to data breaches under GDPR.  

1. If you are unable to prove that there is no likelihood of harm, then you have to tell the Data Protection Authority as soon as you can, that language states “without undue delay, and where feasible, not later than 72 hours after becoming aware” of the breach. Article 33.   
2. If there is a likelihood of serious harm to individuals, then you ought to tell them as soon as practicable. The 72-hour timeline isn’t specifically mentioned here, but that timeframe is a good rule to follow, if not sooner when there might be identity theft.  Article 34.

Here, there was a possibility of identity theft, at least for some of those 4,100 people.  It should be noted that in 97 of these individual cases, the CVV code, that number on the back of your credit card, was also exposed.  And according to the AP, Booking.com knew of the data breach on January 13th, but did not tell the AP until February 7th.  Booking.com had told the affected individuals on February 4th.  Now that was a good thing, trying to reduce the harm to individuals by notifying them and telling them to be on their guard.  However, the Data Protection Authority was not brought into the picture quickly enough.  As a result, the AP fined Booking.com €475,000. 

It’s important to remember, for the reasons we’ve just talked about, that there could be additional investigations.  For example, if there were also UK individuals in that database, then there may also be reporting obligations to the UK, and the UK may possibly be able to levy a fine as well.  There’s some complexity there, given that the breach was pre-Brexit and the enforcement is post-Brexit.

Matt: Looking at the facts of this enforcement action, I kind of feel a little bit for Booking.com.  The nexus of the notification here came from numerous emails that happened in 2019, specifically January 8th, 13th and 20th.  They then performed an internal investigation, which was completed on February 4th and reported on February 7th.  Shouldn’t a company have a reasonable opportunity to conduct an internal investigation and do their due diligence prior to notification, especially given the fact that complaints come from individual consumers whose individual claims may be hard to quickly verify?  Is 72 hours a reasonable timeframe within which this can happen?

Jonathan: Well, my personal view is that 72 hours is too short.  And you’ll remember that in 2012, the original proposal was 24 hours to report a data breach.  I and others got in touch with the Commission and tried to show them what that likely meant.  It’s akin to telling burglars that were going to give you a warning before the police are on to you so that you can get out of the building quickly.  72 hours is too short, but that’s the law.

Now in extreme cases, you will be able to say to a Data Protection Authority, “We delayed the notification because…”.  There is less opportunity to delay the notification to the regulator than there is to individuals because the regulators obviously are deemed to be secure.  So, you’re not telling the rogues if you’re telling the regulator.  But what people mistakenly believe from my experience of doing 60 – 70 data breaches per year, is that they believe that the 72 hours kicks in when they’ve found the solution.  And it doesn’t.  It kicks in when you’ve identified the problem or the issue.  Oftentimes, the investigation isn’t as to whether there is a breach or not, but rather what is the nature of the breach and how do we fix it.  Too often we see IT teams delay telling the regulator until they can tell the regulator bad news and good news.  That is not what the law says.  If you have only bad news, you still have to tell the regulator.  And of course, in some cases, the regulator can help.  This was a multi-jurisdictional issue, and regulators can sometimes help by signposting you to resources that might not be available otherwise and/or through communication amongst DPAs.  Organizations must get better at acknowledging when they’ve got a problem, because that’s when the clock starts running in most cases.

What we’ve also seen happening in a number of recent cases, is that people aren’t getting their processes to tell them quickly enough.  Let’s say you’re outsourcing payroll and your payroll provider knows it has a breach.  They then sit on it for two days and then they tell you on day three.  Well, that doesn’t mean to say that you get another two days, because your payroll processor sat on it for three days.  That three days is an absolute.  Just because you didn’t supervise your contractor well enough and they failed to tell you quickly about a breach, you don’t get any leeway for that, so regulators are becoming much more aggressive on that 72 hours.   

We’re also seeing regulators, there is a Swedish case for example, take action directly against data processors for not telling data controllers quickly.  So, if you’re just processing data on behalf of somebody else, for example let’s say you’re a law firm and you’re processing data for your clients, if you lose data, then you’re also going to have to get out of the blocks pretty quickly as well.

Matt: And I assume as a data processor, it’s not a defense to say that there was no reporting clause in your contract with the controller?  You have an affirmative obligation to report data breaches, correct?

Jonathan: Yes, and by saying things like that you potentially have double jeopardy.  It’s clear from the regulators that they can fine you for the breach, they can fine you for late reporting of the breach, and they can also fine you for inadequate technical and organizational measures – an Article 32 breach.  So that’s a dumb thing to say, in most cases.  We’ve talked about it before, Matt, but we’ve got cases like H&M where the Data Protection Authority gets much more excited about other failings in the organization that it does by the data breach report, and potentially, by saying, “Oh, we didn’t report the breach quick enough because all of our systems are terrible,” you’re opening yourself up to a much wider and more damaging investigation.

Matt: You mentioned with Cordery, and the work you’re doing with your team, that you’re doing 60 to 70 data breach projects a year.  As a trend, are your clients, and organizations generally, trying to get ahead of these issues and implement technological and administrative controls to address these types of timeframes, like the 72-hour breach notification timeframe?  Or is what you’re doing more reactionary?  Are you more often reacting to a corporation or client that’s undergoing something post breach?

Jonathan: I think it depends.  Oftentimes, organizations don’t have the right processes and procedures in place when they have their first breach, but by the sixth time, they’re getting much better at it.  And I think the organizations that do this well are always analyzing near misses as well, like the airline industry.  Remember that you don’t always have to report a data breach, but it is a good practice to always analyze these incidents even if you don’t have to report the data breach.  Asking questions like:

• What could we have done better?
• How could we have notified the necessary parties about this quicker if we had to notify a regulator or any customers?
• How could we have dealt with it better?

What we’re increasingly seeing from clients is that they are aware that we are handling a lot of these data breaches, and many of these matters are reaching regulators and regulators are telling our clients to do X, Y and Z after a breach.  They then ask, “We’ve now had a breach so what are the X, Y and Z issues/requirements/solutions likely to be?”  Increasingly, we’re saying to clients:

“Okay, you’ve had a breach, here are some remedial actions that might fix it.  If you can commit to some of these actions within that 72-hour window and tell the regulator that you’ve done this self-analysis, and you think you’ve identified the problem and have some quick fixes, then your regulatory outcome is likely to be materially better because.”

Many organizations are taking the following actions (two are proactive and one is reactive, but with an eye towards future prevention):

1. They are investing in learning.
2. They are investing in processes.
3. They are debriefing after they had had an event or a near miss, which encourages them to get better each time.

Matt: With regards to breach notification, can you briefly lay out the primary differences between Articles 33 and 34?

Jonathan: It’s more or less a burden of proof issue in very simple terms.  Under Article 33 you have to tell a regulator unless you’re sure that there isn’t a risk of harm, and you should tell an individual if you think that there might be a serious risk of harm under Article 34.  I’m paraphrasing, the exact wording is slightly more cumbersome than that, but basically, you’re looking at harm.  Many more data breaches will be reported to regulators than are reported to individuals, because that threshold is somewhat different.  

In some cases, it’s good practice to tell the individuals, even if you don’t think you have a legal obligation to tell them under Article 34.  You may decide to do that because you want to be transparent with people, which would be your GDPR Article 5 obligation.  You may want to tell people because they are employees and you want them to be on their guard against identity theft.  Or you might want to tell people just because you think it’s the right thing to do.

Matt:  What is behind the AP’s fine of Booking.com?  This €475,000 fine is in line with the Twitter fine from the Irish DPC in 2020, which was about €450,000.  Recently, though, on the other end of the spectrum, the Dutch AP imposed a fine on a political party for a breach notification failure that was only about €7,500.  That particular case only involved about 101 data subjects, but can we assume that based on the size of some of these fines, despite the two-tiered fine structure prescribed by the GDPR that scared the heck out of everyone at the dawn of the GDPR, that these breach notification enforcement actions are going to hover in the mid-€400,000 range for actions that are not intentional, but are more negligent?  Is this amount becoming somewhat of a standard for this type of action? 

Jonathan: I think it’s probably too early to say.  I think that you’re right to say that the Twitter action is significant.  And of course, what we had there was this procedure where at an EDPB level, the different DPAs chipped in what they thought the fine amount should be.  My suspicion is that the Dutch AP saw the writing on the wall and the consensus that came from the Twitter case, so they wanted to get a number around the same level, because they knew that that would make the process easier at an EU-wide level.  Especially, given that some of the data subjects were within the EU, but not in the Netherlands.  I think we might find some DPAs pick around about this figure as something that everyone can live with, some DPAs that think the fines should be higher, and some think it should be lower.  At least you might manage to smooth the process at an EU level by picking around this number.  I think what we’ll find though, is that we’ll see fines that are much lower and much higher.  There are a number of factors that DPAs are taking into account with regards to fines, including:

• the technical measures that they applied,
• how soon they were out of the blocks,
• the number of data subjects affected,
• the types of data affected (whether that includes sensitive or special categories of data, whether that includes data that could lead to identity theft, etc.), and then critically,
• what the organization has learned.

If you come to the regulator quickly, with a package of measures that fix…, to use a Dutch analogy, that put a finger in the dike and stop the flood coming in, if you can be self-aware and go to the regulator with those measures, then your eventual resolution is likely to be more favorable.  Your outcome may not involve a fine at all, or it might reduce the level of fine that you could otherwise expect.

Matt: I’m surprised that it took us this long talking about two Dutch enforcement actions to use the Dutch boy with his finger in the dike expression as an analogy, so kudos!  Thank you for putting that in there! 

But Jonathan, the Booking.com action is obviously not the first enforcement action for a breach notification failure under the GDPR.  Why is this specific action significant?

Jonathan: I think it’s significant in many respects.  It’s one where we’ve had a bit more openness and transparency, a lot of the data breach cases we’re seeing, there are not that many details.  Some regulators give you a lot of details, some not many at all.  Such transparency makes it significant. 

Also, because it is a fairly typical data breach, this data breach is probably very similar to another 30 or 35 that have been across our desk in the last three years or so, yet seeing such a breach in the context of an enforcement action is important to demonstrate lessons.  It’s quite often that organizations are relatively good at wrapping their arms around data security at their home office, but they forget to focus on who else is handling data on their behalf, in this case, in the Middle East.  If you’re an organization that has an international presence, it’s a reminder that you need to do all that training around GDPR.  Take action regarding data protection and security under GDPR throughout your whole operation, not just the EU based bits.

Matt: What are the takeaways from this case?  What are the survival tips?  If booking.com came to you under these circumstances following a breach, what would you have told them?  What can we tell organizations that they should be doing with regards to breach notification to avoid these types of actions?

Jonathan: I think first of all, and it sounds obvious, but data security is important.  When you’ve had a breach, it should be priority number one for the data breach team over all else.  That should not need saying, but it does.  You know, I’ve had client’s say, “But it’s Thanksgiving weekend. I’ll deal with it Tuesday when I’m back after Thanksgiving,” or, “It’s a bank holiday weekend in X, Y, Z country. I’ll deal with it Tuesday.”

Matt: [Jokingly] Are you telling me that the 72 hours also includes holidays?!  You don’t get a break from reporting a breach if it’s Christmas or New Year’s Eve?

Jonathan: I seriously had an IT manager saying that he’d rang his preferred counsel in the US who had assured him that the 72-hour time frame did not run over Thanksgiving weekend!  AND that there was a specific clause in GDPR that said that!  You try not laughing at that! 

You often get people that say, “I’m busy with the launch of X, Y and Z, and I can’t be putting my mind on this.”  Unfortunately, I had a project about 10 days ago where there was a project lead, the company had lost lots of data, but she’s moved on now.  “She’s dealing with other stuff.”  People have got to give data breaches top priority.  They have to think to themselves, “If I was one of these 97 people who had my credit card details and my CVV number posted on the internet, would I expect people to get out of the blocks pretty quickly?”  Well, yes!  I would.  Basically, the Golden Rule applies: Treat other people as you want to be treated yourself.

Matt: Jonathan, do you think one survival tip would be that rather than task somebody from Risk or somebody from IT to handle these issues, they should have a designated, or dedicated, team handle such incidents?

Jonathan: I think most organizations that do this well do two things in terms of resources:

1. First of all, they say that whoever owns the process owns the risk. If it’s Payroll or HR that decided to use that payroll provider, then they own that risk.  And when that payroll provider messes up, then HR must shoulder most of the load.  
2. At the same time, those same organizations that do it well also have a data breach response team. And that team rehearses, it has muscle memory and is task orientated.  It knows how to deal with data breaches.  Usually, such teams are multidisciplinary.  Normally, these teams will consist of folks from IT, Legal, Compliance, Public Relations and Investor Relations.  These teams may also include HR because a lot of breaches involve employees, either it’s employee data that’s gone, or it’s an employee that potentially responsible for the issue.  Maybe the team includes somebody from vendor management as well, if that’s a separate bit of your organization.  

Those organizations that do it really well rehearse these situations to make sure that they know how they all work together.  They know the various roles and responsibilities. And they can get out of the blocks quickly.  In addition, organizations that do it very well have some formal system in place for handling data breaches.  That might be an automated system, and at Cordery, full disclosure, we’ve developed one.  It might be a war room with whiteboards, or whatever the Zoom equivalent is, to make sure that somebody’s got their eye on the time so that they ensure they stick to the required deadlines.  Those organizations that rehearse these situations achieve materially better outcomes after a data breach.

Matt: Are you doing such tabletop exercises with your clients at Cordery?

Jonathan: Yes, absolutely.  I think the last time I looked we have been somewhere north of 500 people have been through what we call Cordery Data Breach Academy.  Sometimes they’ve done this as part of their Continuing Professional Development (CPD) for information security professionals.  We’ve done courses in partnership with various professional associations, sessions in a competitive environment where organizations compete against other organizations using gamification, and we have done in-house sessions.  However you might undertake these exercises, you absolutely should do them, and make sure you rehearse them under the current regulations, not the regime of four and five years ago.  Organizational teams should rehearse with real questions.  One of the things we do is we often is to set up a situation that is similar to a real-world scenario.  For example, we try to use correspondence from regulators that is very similar to the real correspondence that we’ve seen in particular cases.  And it is important to note that such responses change rapidly in areas like ransomware.  Regulators are much better at handling ransomware reports now than they were six months ago in my experience.  You must keep evolving your practice and keep rehearsing.

Matt: I definitely think our viewers would be interested in Cordery’s Data Breach Academy.  I would love to get some more information on that, which we will post here.  And Jonathan, I think you may have given me my first idea for an ESI Survival Guide branded tchotchke, if you will.  Maybe this is something we could monetize in the ESI Survival Guide webstore.  I’m envisioning a giant digital LED clock.  An ESI Survival Guide GDPR Data Breach Notification Clock.  Whenever there is an issue, you can get the clock, stick it on the wall and have the countdown set for 72 hours!  They probably won’t be available anytime soon, but it’s an idea that I’ll stick in the ole idea bank.

Click here for more information on the Cordery Data Breach Academy.

With that, Jonathan, thank you my good sir!  As always, it’s great to sit down with you and talk about these exigent issues.  I love these sessions where we teach viewers, but at the same time I get to learn new things.  Your insights are always fantastic and very much appreciated.

ESI-SG: For everyone that took the time to read this piece, we hope you gained some value out of our session.  We appreciate your support, and please feel free to check out other content here on the site, on Instagram: @esisurvivalguide.com or on Twitter: @eDiscoveryGuide. 

This is Matt with ESI Survival Guide, telling you all to please stay safe out there in the electronic wilderness.  See you next time!