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.
DPA of Baden-Württemberg (Germany) fined a health insurance company 1’240’000 EUR for insufficient implementation of TOMs resulted in personal data of app. 500 individuals being accidentally processed for advertising purposes without due consent.
The fine is quite high, especially given that there have been some mitigating factors in this case:
not too many data subjects concerned
cooperation with DPA
TOMs were not absent at all, the level of implementation thereof was just insufficient
Besides, no data breaches or other factors posing a (high) risk to data subjects were identified.
The investigation resulted in one of the highest fines issued under Article 32 (if not highest). This can be explained, in particular, by the adoption of the German model for calculating fines under the GDPR.
Anyway, this is another one reminder for controllers and processors about the importance of putting TOMs in place appropriate to the risk as ‘somewhat good’ TOMs will unlikely be enough.
An interesting GDPR enforcement case came from Belgium in late May. Imagine that a data controller is sending unsolicited postal communications and ignoring data subject rights to object (Article 21) and to be forgotten (Article 17). On top of that, it misidentified legal basis and relied on the legitimate interest instead of consent (of course, no balancing exercises have been conducted and no safeguards have been put in place).
What could happen to such a data protection ‘nihilist’? Article 83(5) suggests that its DPO may start looking for another job. However, things may go upside down if the controller is a… non-profit organisation.
Not to keep an unnecessary suspense, the data controller in the case above was fined mere 1000 EUR (nope, I did not miss additional ‘zeros’). Of course, factoring in that it was the first case against this organisations and that the controller is a non-profit organisation with no regular turnover.
This all may be well true, but it seems that such ‘enforcement’ naturally tears the fabric of the GDPR as it factually gives all non-profit organisations carte blanche to violate ‘tastefully’ for their first time.
In Finland one of the first fines handed out to a water supply management company which used location data in the vehicles used by employees which is considered systematic monitoring. A DPIA should be conducted.
Taken from DLA Piper blog Followed from a complaint made by an individual. Kymen Vesi processed location data of its employees by locating their vehicles. This location data was used to monitor the employees’ working hours. The Data Protection Ombudsman stressed in its decision that a data controller must carry out a DPIA when the processing likely results in high risk to the rights and freedoms of data subjects. Kymen Vesi should have carried out a DPIA since the processing of location data concerned data subjects in a vulnerable position (employees) and the data was used for systematic monitoring. In reference to the criteria list set in WP29 guidelines on DPIA and determining whether processing is likely to result in high risk, the processing conducted by Kymen Vesi satisfied three of the criteria (processing of location data, data subjects in vulnerable position and systematic monitoring of data subjects) when usually a DPIA is already required when two of the criteria are satisfied.
Read the rest of the blogpost from DLA Piper blog.
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 !!
