Five Key Things to Consider about Data Subject Access Request Handling (Part 1)
Handling Data Subject Rights requests, and ensuring appropriate processes for doing so, is arguably part of the price organisations pay for obtaining and processing data relating to people As with many aspects of Data Protection, it requires a balancing of rights and obligations that often seem to be competing with each other. In this post I’ll look at seven things organisations need to consider in respect of handling Right of Access requests. Ultimately, this is a process design and governance challenge applying Data Protection by Design and Privacy by Design principles where a one size approach may not fit all scenarios. Organisations that are implementing new systems or processes for handling personal data should consider how they will handle requests for data subject rights as part of their planning and scoping. Organisations that have processes in place are also advised to keep their processes under review to ensure they are effective and comply with the latest guidance or decisions from Regulators on this important aspect of data protection law.
It’s a Game of Three Halves.
When thinking about the life cycle of a data subject access request, it’s recognising it’s a game of three halves.
- Search for and retrieve data
- Review any applicable exemptions or exclusions
- Disclose data to the requester
Each of these stages raise different issues and considerations for the design of a process, and different questions regarding the balancing of rights and obligations. This game has some fundamental rules that need to be balanced. Data Controllers are obliged under Article 12(2) GDPR to facilitate the exercise of rights, so a process cannot serve as an unreasonable blocker. Data Controllers are required to respond to a request “without undue delay” under Article 12(1). And Data Controllers also have to ensure that they have appropriate controls in place to prevent unauthorised disclosure of personal data under Article 5(1)(f).
Search and Locate
Searching for and locating data first requires that the Data Controller is able to do such a search. That means that an initial request must contain sufficient information from the requester to enable an initial search to be done. Unless there is enough information provided to start the search, a request for access isn’t valid and the clock doesn’t start ticking. This may mean that a Data Controller has to ask for additional information to be provided to enable them to conduct a search.
It is possible that a search will identify that no data about the data subject based on the information provided by the Requester. In such a case, a Data Controller can respond that no data was found based on the information provided and suggest that if there is additional information the Requester might have that could facilitate searching, they can submit a new request. Alternatively, the search may reveal multiple possible records that may or may not relate to the data subject. In such cases, a Data Controller would be right to ask for additional information to make sure they were retrieving data about the right person.
Dialogue with the requester is an important part of this “Search and Locate” phase as each request may raise different issues. Good dialogue early on can help narrow and clarify the scope of a large or complex request, can identify any reasonable grounds for concern about the validity of the request or the bona fides of the requester, and can help provide an evidence base for any increased requirement for information from the requester.
The key test here is whether the data is necessary and proportionate in the context of the process to request that information to enable effective and timely responses to a request for data. The DPC’s guidance on Data Subject Access Requests states that an access request is valid “the request is sufficiently clear to act upon” and that the identity of the requester is “sufficiently clear”. The threshold here for the “Search and Locate” phase of a DSAR request is therefore simply that the data being sought is clear and there is clarity as to who the request relates to. If further information or clarification is needed, it may be requested. The DPC guidance is also clear that a proof of identity request is not appropriate if there is no real doubt about the identity of the requester and that, if sought, it should be the minimum necessary and proportionate for the purpose.
Which is why the distinction between the “Search and Locate” phase and the “Disclosure” phase is so important. The purposes, and therefore the threshold of what might be necessary and proportionate, are distinctly different. That’s not to say that asking for verification of identity during the search phase is not permitted. It may be necessary. It may be proportionate. That is a case by case determination, taking into consideration the fundamental data protection principle of necessity under Article 5(1)(c) GDPR.
Review and apply exemptions or exclusions
There are a limited range of exemptions and exclusions that can be applied to the right of access under GDPR. When handling a request, consideration will need to be given to whether any of these apply. For example, is the data in question an opinion about the requester which was given under a presumption of of confidentiality? Does the data contain references to a third party that would be likely to impact on their fundamental rights and freedoms? Does legal privilege apply to any of the data?
Depending on what exemptions or exclusions apply, different decisions may need to be taken with respect to the processing of the request. These decisions will, of necessity, be on a case by case basis. In many cases, redaction of third party data may be required. In others it may not be appropriate. That said, erring on the side of caution is often advised as it is easier to unredact and release something if a Supervisory Authority determines that you should have released it than to put the smoke back in the bottle if you release data that should not have been disclosed.
Disclosure of the Data
“Trust but verify” is allegedly a Russian proverb, but it serves as a good principle to live by when we come to consider the “Disclosure of Data” step of a Subject Access Request. The balancing act that needs to be performed at this stage is between the need to facilitate the Data Subject’s request under Article 12(2), the obligation under Article 5(1)(f) to protect data against unauthorised disclosure or access, and the obligations under Article 5(1)(c) regarding data minimisation (aka the Necessity Principle).
It’s also a good example of where Data Protection by Design (Article 25 GDPR) comes to the fore in defining and implementing effective processes. There are various requirements jostling for priority and it is necessary to design a process that balances these obligations effectively.
It’s also important to note that the purpose for which data is being processed by a Data Controller has now changed. Previously in the DSAR game, the purpose was to be able to find data and ensure that you were able to exclude unrelated persons of the same/similar name or other characteristics from your searches. Now the purpose is to make sure that you minimise the risk of that data being given to a third party who should not be receiving it. That means you need to consider how any approaches to requesting additional information will be effective, or whether you can use information already in possession of the Data Controller as the basis for a validation check.
In this context, it’s important to consider the DPC’s decision in respect of Groupon. In that case, Groupon requested a nationally issued photo ID be provided by a data subject looking to exercise a right as a Data Subject. However, Groupon had not required any such identity card to be provided when opening an account and had no data to match any submitted ID card against.
Groupon in effect required the data subject to submit a copy of a national ID card in order to process his erasure request even though the provision of a copy of such data was not a
requirement at account opening stage and, therefore, Groupon had no means to check the veracity of any national ID card information that the data subject may have submitted
The DPC also notes that what they describe as a “less data-driven” approach (verification of ownership of an email address associated to the account) was subsequently implemented by Groupon, which further evidenced that the request for photo ID was not necessary.
While the Groupon case relates to the Right of Erasure, it still triggers the same balancing requirement between the necessity principle and the obligations under Article 5(1)(f) in respect of security of data against unauthorised disclosure and destruction. So, for any request for data to be necessary and proportionate, an organisation will need to show that no less data-intensive approaches are available. The Groupon decision also highlights that Controllers should consider how they can use data that they already have to introduce proportionate validation and verification checking. It may well be necessary and proportionate to request photo ID and other data to be provided. But the Controller needs to be able to demonstrate that. But if you also provide less data-intensive approaches to exercise a data subject right that don’t require the provision of this kind of information, it will be harder to establish the necessity of such measures.
Finally, the DPC’s decision in Groupon also highlights the importance of Controllers having clear grounds for determining that there is a reasonable basis for determining “reasonable doubts” as to the identity of a requester. This needs to be a reasoned decision on a case by case basis and that evaluation will drive the assessment of whether additional information requested is necessary and proportionate.
By thinking of a DSAR request as a game of three halves, organisations have the opportunity to design their processes in a way that supports effective engagement with data subject rights, balances the competing obligations under the legislation, and can help differentiate your organisation from others in your approach. Those approaches should include consideration of how exceptions can be handled, particularly in scenarios where the data subject’s circumstances don’t fit a cookie-cutter template process.
Below are some links to other Castlebridge content on the topic of Subject Access Requests. These predate GDPR so should be read with that caveat.
Other Posts in this series
As other posts in this series are published, we’ll add their links here.