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.
Half a million customer data was stolen by hackers is being reported by Swedish newspapers. Foodora a Swedish concern is owned by a German business, Delivery Hero. As one can guess by the combination of both names: 1) its about food, and 2) yes, customers book online from whichever is their favourite restaurant and get it delivered.
From what I can gather, the data was stolen from their test environment. This means that live data was stored in test which was not appropriately protected as is required by Art 32 (GDPR). Moreover it seems that the purpose limitation (Art 5.1b) and data minimisation (Art 5.1c) principles were not respected. There is probably more, but this is what I have based on a couple of newspaper articles.
So the affected data subjects are included as customer data was from 2016. The only data stolen in clear text was data which is in main public in Sweden (except if you have a protected identity), so it seems low risk, but read on…
What is not public data is the fact that the individual is a customer of Foodora, and this is a great way to social engineer a phishing attack that seems to come from Foodora to these customers.
On the plus side it looks as though Foodora have got out their communications function, sent a message to all customers warning them on what has happened, and not to click on any links in emails from them. Their quick action is impressive, very transparent, and a good example on how to act when this kind of incident occurs.
Nevertheless, I see that there will be an investigation of Foodora by the Swedish Data Protection Authority, which is scheduled to finish before December 2021.
All us DPOs who feel a bit more relaxed with the Corona times… thinking that no Data Protection Authority would be so unfeeling as to hand out a fine now…. think again..
My hat off to the Swedish DPA (Datainspektionen). A fine for SEK200k has been awarded to a Government Service Centre (SSC) which handles salaries and such for 47 Swedish government authorities. SSC is a processor to the 47 government authorities, although a controller to their own employees. It was a breach of 282k employees salary data, including their own.
In short the cause was a technical flaw in an application (Primera), and SSC failed to report not only to the controllers, but also the DPA…. but clearly the case is much more complex. Articles 24, 28, 32, 33-34 are all quoted in the report from Datainspektionen. This is a really important case and gives some really great clarifications, not only on personal data breach notification but also responsibilities of the controller/processor.
I tried to map it out below. Basically there were 2 fines:
For the delay in reporting the breach to the controller (SEK150k), Article 33.2 and;
For the delay in reporting to the Swedish DPA (SEK50k), Article 33.1.
Basically a personal data breach must be reported to the controller (if you are a processor) without undue delay. As soon as you know you have a breach, clearly you want to know why it happened, but this has to wait. What is important is to ascertain that a breach has happened, and it is personal data which has been breached. What happened in this case is that SSC wanted to understand more about why it happened, and the delays became serious.
On reporting as the controller, you have 72 hours to report to the DPA, and the same applies as above. During this time priority is to ascertain that a breach has occurred and have enough data to know if it has causes a risk to the rights and freedoms of the natural person. The cause of the breach is a ‘nice to have’ at this stage. You can always send in an updated report later when you know. These are not my opinions, these are facts.
There are always lots of politics which come into play when these kind of incidents occur. I believe SSC wasn’t just lacking in the breach process, but issues with conflicting opinions, and dilemmas.
There was also a problem with the DPA had with Evry, it was outdated, and not compliant with GDPR, but they got a warning for this, no fine.
I created some flows to get my head around this. The paper was quite long (and in Swedish), and loads of other data, e.g. there was an employee who found the bug and exploited the hole, ended up getting reported to the police… I think this was retracted by the Datainspektionen later.
I hope you find this useful? Feel free to ask questions… as I mentioned at the beginning, this is a super interesting case !!
