Complaints to the Danish Data Protection Authority – process review and optimization

Working in Information Security triggers me to sometimes look into technical or process issues that might have security implications in services that I’m relying on.

A case led me to understand and underlying issue that most data controllers have :

There is no clear overview of all their data flows and all vendors that process data in their company.

Be it personal data that is regulated by the GDPR, business data that can be used by competitors for an extra edge or technical data that can be used to exploit their systems.

Based on the analysis of the complaint process, the Complaint Resolve Time can be reduced by 20%

This article focuses on the personal data part, how it was reported to Datatilsynet (the Danish Data Protection Authority) and how the complaint was handled by Datatilsynet.

Image result for data subject complaint

Conclusions

Based on data handling complaint (ref. 2018-31-1075) opened in November 2018 (case still ongoing), the following process issues have been identified.

Issue 1


The case was prolonged by 28 days*, because the DPA did not check the accessibility of research resources (the website link) provided by the complainer nor was it initially open to using them, invoking security concerns.


Why is this a problem ?
There is a risk of the DPA getting infected because of executing/accessing external resources. At the same time, the complainers that are limited in the resources that they can use will not be able to effectively report and thus valuable information will be lost and the timeline for handling complaints will be prolonged.


What could be done ?

Complainers should be allowed to use multiple forms of sharing the information and the DPA information security should have a pre-vetted list of accepted resources and/or a fast way of verifying if these resources are malicious.

Issue 2

The case was prolonged by 45 days*, because of the unclear problem statement formulated by the complainer and the fact that the case was passed to multiple stakeholders within the DPA that needed to decide which unit of the DPA should handle it.


Why is this a problem ?
The data subject may not always know the exact article the complain is related to. DPA staff need additional time to triage the case and forward it to the Article specific unit.

What could be done ?
Empower the complainer to triage the case by including preliminary questions when filling the complain form and by issuing guidelines.

Issue 3

The DPA is missing on valuable information by not handling OR inventorying complaints related to general data handling issues.

Why is this a problem ?
The DPA informed that only cases related to violations of my personal data will be handled. If general security issues are reported about a data controller / processor, this can highlight that there is an emerging risk of data breach in the future, which is of interest to the DPA.


What could be done ?
The DPA can start receiving and acknowledging complaints related to general security issues and prioritize data audits based on the the number/severity of remarks related to specific controllers / processors data security posture.

Process overview

process-overvie
Diagram 1 – high level process overview for complaint handling and data handling

Description

  • the Complainer / Data subject is responsible for step 1 (prepare evidence) and step 2 (file a complaint) , while contributing to step 8
  • the DPA staff are responsible for step 3 to 9
  • Issue 1 from the Conclusions is related to step 1 (prepare evidence) and step 3 (acknowledge and triage) of the Complaint process ; if the website link would have been accessed when the ticket was acknowledged the case would have shortened by 28 days
  • Issue 2 from the Conclusions is related to step 2(file a complaint) , step 3 (acknowledge and triage) and step 4 (validate) of the Complaint process ; if step 2 and step 3 would have been merged via preliminary questions or options, the case would have been shortened by 45 days
  • Issue 3 from the Conclusions is related to step 4(validate) ; if there would have been a direct way to validate and inventory general security issues, the DPA would have gained valuable information that could potentially prevent data breaches in the future
  • The underlying problem of this case and many more to come is that most data controllers do not have an overview of all their data flows and all vendors that process data, nor do they adequately verify their security posture

Research and Complaint Timeline

The following timeline highlights all steps in the research and complaint process.

  • 12/10/2018 – I received an invoice payment reminder from data processor. Beginning of research.
  • 14/10/2018 – I requested the right to see what data is the controller processing on me and who are the data recipients for this data.
  • 5/11/2018 – data request is fulfilled and I receive an email stating the data processed and the recipients ; the recipients list did not include the processor that triggered the beginning of the research, not did it include IT service providers used by the data controller.
  • 5/11/2018 – the research is finalized and is shared with the data controller, highlighting the fact that they have a security issue with their data processor and the fact that they do not share the entire list of data recipients.
  • 6/11/2018 – the data controller acknowledges the situation but offers no clear action plan.
  • 12/11/2018 – I contact the data controller again to receive a status update ; the reply is received on the same day, the data controller not wanting to disclose any action points nor any intention of remediation of the issue.
  • 12/11/2018 – I inform the data controller that Datatilsynet will be notified about this.
  • 21/11/2018 – complaint is issued ; I informed Datatilsynet via DigitalPost.
  • 26/11/2018 – follow-up with Datatilsynet via DigitalPost and on email ; auto reply received on email.
  • 28/11/2018 – reply from Datatilsynet on DigitalPost that they have too many requests to process and will get back ; no timeline provided.
  • 05/12/2018 – reply from Datatilsynet on DigitalPost saying that they need more information, refusing to use the information on the blog (¨as a principle does not log in to unknown websites¨).
  • 05/12/2018 – follow-up up by asking what can I do so that they will navigate to the blog to read the article.
  • 10/01/2019 – no reply received ; follow-up with Datatilsynet on DigitalPost by asking for a direct meeting on the subject.
  • 14/01/2019 – called by a representative of Datatilsynet saying that my case was passed on from the department handling Article 32 to him ; we concluded that the case needs to be forwarded back to the same department and that I have to send an email detailing this.
  • 04/02/2019 – follow-up with Datatilsynet on DigitalPost by specifying clearly that this is a Article 32 case.
  • 05/02/2019 – reply from Datatilsynet on DigitalPost mentioning that i cannot complaint based on the general processing of data but of my data specifically.
  • 11/02/2019 – follow-up with Datatilsynet on DigitalPost by specifying 3 complaints ; 1 on Article 32 and 2 on Article 12.
  • 18/03/2019 – no reply, follow-up on eBoks.
  • 19/03/2019 – reply from Datatilsynet on DigitalPost mentioning decisions on each complaint points , where no.1 was not accepted, but for no.2 and .3 Datatilsynet gave the data controller 3 weeks to provide any input (up until 09-04-2019).
  • 05/05/2019 – no reply, follow-up on eBoks, asking how will this case proceed and what are the next steps.
  • 13/05/2019 – reply from Datatilsynet on DigitalPost along with the data controllers reply and an unofficial English translation.
  • 14/05/2019 – another reply from Datatilsynet on DigitalPost informing about the next steps and approximate closure period which is within 4 months, after which I will be informed
  • 15/05/2019 – reply to Datatilsynet on DigitalPost, mentioning that the data controllers statements are too vague and that the DPA / security requirements between controller and processor do not seem in place.
  • 12/08/2019 – almost 3 months after the last reply from and my last message to Datatilsynet, I follow-up on DigitalPost
  • 22/08/2019 – follow-up on DigitalPost
  • 17/10/2019 – reply from Datatilsynet, where the conclusion is that the data processor had to ensure that data was not transmitted outside EU.

Final notes

Having GDPR in place, the number of complaints is increasing. As more people (data subjects) will become more security and privacy conscious, the number is set to grow again.

Businesses (data controllers and processors) will have no choice but to simply understand and secure the data that they process. Ideally, this shouldn’t be done with fines but with a proactive mindset. Sadly, we are not there yet and more complaints are to be filled and more fines to be issued – it’s also understandable, as Bruce Schneier puts it :

 Public scrutiny is the only reliable way to improve security, while secrecy only makes us less secure

Schneier: Full Disclosure of Security Vulnerabilities a ‘Damned Good Idea’

To be mentioned

So was the process optimized after all ?

I tried reaching out multiple times to the Data Protection Authority to share the results. Several phone calls, direct emails, even going there to drop the printed article. No luck yet.

Specifics on the analysis :

  • *number of days – has been calculated based on working days in Denmark ; this was seen from the complainers perspective, with no prior knowledge of inner process workings
  • the data controller and data processor related to this case are providing services and processing personal data for the data subject in question. They are FDM and FakturaIT as listed in the detailed article about their breach of GDPR.