Swedish DPA has handed out a fine to SSC a government authority of SEK200k

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:

  1. For the delay in reporting the breach to the controller (SEK150k), Article 33.2 and;
  2. 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 !!

Data brokers and data subject rights

Well I’ve been working hands-on with data subject rights for almost two years now and an area which is still grey, is when it comes to data brokers.

If the data broker has scraped public sites for personal data is one aspect. Personal data has been shared by you and I in LinkedIn, Facebook, etc., a data broker can extract and use, after all it is public data.

The other is, as is the case in Sweden when personal data becomes public data but not at the bequest of the data subject. Still the data brokers are there scraping sites e.g. hitta.se, ratsit.se, all legal due to something called an utgivningsbevis issues in the name of freedom of speech. If you want some background on this, I’ve written loads!

One of the challenges that a lot of businesses are purchasing personal data from data brokers as part of their sales activities. Then requests for access to personal data (Art 15), or to be forgotten (Art 17) come pouring in from individuals who want to know why sales personnel are contacting them when they did not opt-in, saying that it’s not compliant with GDPR.

Well the fact is, there is nothing illegal in this activity as it stands today. Once you make your personal data public you lose some rights. Of course in Sweden it is more complex as individuals have not requested their data to be public, it is like this as a default.

Now often the data subject will ask to be deleted, and does not want to be contacted again, but it is not so simple. If the organisation purchases regularly data from data brokers, deleting the data won’t solve the problem, their name needs to be added to an ‘opt-out’ list. Which means processing additional data. If not, their name will pop-up again, because you see the problem is three-fold:

(1) data is public, whether this is knowingly or not,

(2) there is no mechanism to enable the individual to place themselves on an opt-out list centrally which is accessible to all data brokers, hence

(3) data brokers do not clean, and this means that each organisation purchasing personal data need to have their own opt-out lists.

What complicates the matter further is that the GDPR requires that in order to respond to data subject requests their identity needs to be verified, although Article 11 does say that additional data should not need to be collected in order to verify identity, to be compliant with GDPR.

So where does that leave us when it comes to requests from data subjects who did not ask to be contacted by our sales agents? In short, best to add them to an opt-out list and delete their data, so long as they have never been a customer, have never been employee, etc. If they persist on exercising their rights as per Article 15, request identity which is permitted in Article 11.

Although how do you explain to them why you need to add them to a list? It seems a strange workaround, to something which clearly is not working optimally today.