Insights

Five Key Things to Consider about Data Subject Access Request Handling (Part 3)

By Daragh O Brien

May 12, 2021

26min read

This is the last post in my series on 5 things to consider about Data Subject Access Request Handling. In the first two posts I looked at

The general structure of a Data Subject Access Request handling process. It’s a Game of Three Halves.
The importance of being clear about the purpose for any additional data that a Controller might request and how it will meet the test of necessity and proportionality

In this post I’ll look at the other three things I consider key for organisations to consider when designing their processes for data subject rights request handling. These are reasonably short so I’ve clustered them together for this post. I might elaborate on them further in the future.

Also, while I’ve picked five key things for this series, there are other factors and considerations that are important and Data Controllers should familarise themselves with the applicable case law and guidance in this area and consider how best to implement good practice in their organisation.

Data Controllers: You don’t need to run down the clock on these things!

Often Data Controllers can get themselves tied up in knots obsessing about the one month deadline under Article 12 and the potential for up to two months of an extension for complex cases or cases where there are a high volume of requests (I’ll park the debate about whether that is a high volume of requests over all or just from this one data subject for another day). The risk here is that Controllers sit on data waiting for the whole shebang to be processed through, and potentially waiting on external legal advice on thorny issues that might have arisen in respect of a request.

But Article 12 actually says that a Controller must respond “without undue delay“. So there is nothing stopping a Data Controller

Contacting the requester to determine if there are any categories of data they are looking for more urgently and prioritising those
Adopting a “first in first out” logistics approach and disclosing data as it becomes available after being reviewed/redacted etc.

This has the benefit of demonstrating that the Controller is engaging with the request. If delays arise later, this can be an important mitigating factor when dealing with a Regulator. It also means that the more complex aspects of a request can be identified in the first month and, if necessary, a decision to extend the response period can be made with a clear evidence base.

This means (heaven forbid) actually engaging with the requester though. It means that, in scenarios where sufficient information was provided to enable a search to be carried out for data and for that data to be found and be clearly related to the requester, the contact with data subject may be to perform verification of their identity before disclosing “quick wins” and to inform them that other data would be complex or high volume and asking for a narrowing of scope or an extension.

Storage Limitation is your FRIEND

If you don’t have it you don’t have to give it (but you still have to look for it to demonstrate you don’t have it).

Simply put – being very clear about how long you need to keep data for and getting rid of it when you don’t need it reduces the mountain that you have to climb when processing any request from a Data Subject to exercise their rights.

Another perspective on this: If you have data that you are not sure you have a lawful basis for or a specified and lawful purpose for processing, getting rid of that data is a no brainer. Because if you can’t explain why you have it and what you are using it for and what the legal basis for processing is, then you won’t be able to comply with Article 15, you won’t be able to rebut an Article 17 request, and an Article 18 request will be problematic.

This can be a challenge in organisations where there is a culture of “keep it just in case” or where there are actually clear legal or internal policy reasons for retaining data for longer. However, in such organisations the cost and overhead of dealing with SARs needs to be recognised as the cost of “just in case” and the price of compliance with a legal obligation or an internal policy decision.

Make sure any Section of the Data Protection Act 2018 you are relying on actually applies to you

I very often have to deal with SAR responses friends and colleagues have received where the Data Controller cites Section 90 of the Data Protection Act 2018 as their basis for various things that amount to saying no.

CTRL-F is not your friend when navigating the Irish Data Protection Act 2018 because it smushes together to different pieces of legislation based on EU law. Firstly it legislates for any local ‘variances’ under GDPR. Secondly it transposes the Data Protection Directive for Law Enforcement into Irish law. That happens in Part 5 of the Data Protection Act 2018. This is a Part that is helpfully entitled “Processing of Personal Data for Law Enforcement Purposes”. So, unless you are a Competent Authority for the purposes of the prevention, investigation, detection, prosecution of, or the execution of criminal penalties relating to crime, and the processing of personal data relates to that law enforcement activity, YOU CANNOT RELY ON ANY SECTION IN THIS PART OF THE ACT.

It’s an easy mistake to make, but it can waste time and might suggest to the DPC that your Data Protection Officer probably doesn’t have the expert knowledge of EU and national data protection law that is required of them under Article 37(5) of GDPR. It is essential that a Data Controller is clear as to the precise legal basis they are relying on when requesting additional information or deciding to withhold information in a response to a Data Subject Access Request. Equally, they should be clear if refusing or restricting the application of any of the other rights what their precise basis for doing so is.

Bonus Thing to Consider…

Nice default form you have put together that you have decided people need to submit their Data Subject Rights Requests on. And it’s charming that you seem to think you can refuse a request that doesn’t come in on the form. I’m sure you spent a lot of money getting it (or at least the organisation that you copied it from did). This is an understandable desire from a process perspective to have consistency. But life is, sadly, complicated at times.

The DPC’s guidance on this has been consistent for many years. Data Subjects do not have to use your form, nor do they have to use a special form of words. They don’t even (technically) have to put their request in writing.

The GDPR does not set out any particular method for making a valid access request, therefore a request may be made by an individual in writing or verbally. Where an access request is made verbally, the DPC recommends that controllers record the time and details of the request, so that they can ensure they comply with and do not misunderstand the request. Controllers may want to follow up with individuals in writing to confirm that they have correctly understood the request.

So, your process needs to consider how you take a verbal request that might come from a customer or member of staff and convert that into a recorded format that allows you to track the progress of the request and the time limits, but also ensuring that you correctly understand the request that has been made. As for the humble standard form, the DPC’s guidance is unambiguous:

Whilst such forms can help streamline the exercise of the right of access and support consistency and timely responses, controllers should keep in mind that access requests can still be validly made by other means, such as letter, email, telephone call, or even through social media. Where an access request is made, a controller may invite or encourage the individual to submit it through their designated form instead, but they should make it clear that this is not compulsory, and the deadline for responding to the access request begins to run from the time the valid request is made by any means, not only through the designated form.

Yes, forms can streamline and simplify things, but the process needs to be able to address the myriad of possible route by which a request might be made.

This is a Balancing Act

When handling a Data Subject Access Request (or indeed any of the other Data Subject rights under GDPR), it is a balancing act. There are a number of obligations to data subjects that an organisation owes simply by reason of having their data. Rights must be balanced against the need to have appropriate controls in place to prevent unauthorised access, disclosure, or deletion of data. Each step in that balancing act must meet a threshold of necessity and proportionality when considered against the nature of the data and the potential risk to fundamental rights and freedoms of the data subject.

But this balancing act is the counterbalance to the desire that organisations have to obtain and process personal data. Getting this balance right is part of the price of data. Investing in getting it right pays dividends. Not thinking about it rigorously and critically can lead to process and technical debt that impacts on the organisation, it’s compliance capability, and (most importantly) affected data subjects.