Booking.com reported the breach too late

So the question is when do you press the red BREACH button?

  1. Is it when you first become aware a personal data breach could have occurred?
  2. Is it when you are sure that a personal data breach has occurred which triggers an investigation,
  3. or is it on conclusion of this investigation?

Booking.com decided on option 3.

Booking.com have been fined €475k because of this. They did report the breach but what is significant about this fine is that a minor incident reported by a customer of a hotel was dismissed on 9 Jan, then a second identical report from another customer of the same hotel triggered an investigation on 13 Jan. However, the report of the breach was not until 7 Feb, 3 days after the internal security investigation was concluded. The fine is because booking.com should -according to the Dutch DPA- have reported the breach on the 13 Jan.

In fact it is common practice, to not report the breach until one is sure there has been a breach, and sometimes even the circumstances of the breach. This case shows that this is not an advisable route.

3 Replies to “Booking.com reported the breach too late”

  1. This I missed @Konstantin!
    It is super interesting. Clearly, thinking about it the hotel is the controller. I wonder though if the confusion occurred just because they hadn’t done their homework, or because they are a controller in other ways. e.g. the user is using/registered with booking.com, but not purchased any services, even beforehand booking.com is determining the purpose and means of processing, which makes them a controller. It is the Booking.com algorithms which determine which hotels are listed first and at what price.. they are the controller.

    I wish I could see the contract between the hotel and booking.com, because I am wondering if they can claim to be a data processor..? or are they a joint-controller?

    1. It looks like they are two separate controllers (not joint), but unfortunately DPA didn’t look deeply into this. As far I as understood, DPA simply decided that Booking is a controller just because Booking reported the breach. But it is a very good question!

      I looked into some threads at LinkedIn, Dutch guys say that in Dutch civil law, Booking would likely not be liable for this breach. And that Booking (right from the outset) should have taken a position that they are not controller.

      But I agree with you that in-depth analysis is need to properly assign roles. There is no evident answer lying on the surface.

  2. This is a beautiful case for many reasons! Another one nuance that I like is Booking’s controllership. Booking reported data breach (as if they were controller) but later stated in its reaction to the draft fining decision that they were not controller for the hotel’s breached data. A series of good questions arise:
    – by reporting a breach, do you automatically admit that you are controller?
    – if you admit controllership, does a DPA need to further investigate this? Or ‘admission is a queen of evidence’?
    – if you first report a breach as a controller and then deny controllership – is it consistent? Can you have it both ways? My unpopular opinion – yes! 🙂

Leave a Reply to Konstantin Tiazhelnikov Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.