Update: Since going live with the below, the EDPB has published its draft guidelines addressing key aspects of a data subject’s right of access. More to follow soon.
Last month, a large number of EU and US companies received queries about their data access request procedures under the General Data Protection Regulation (including the UK’s interpretation of the same, the “GDPR”) and the California Consumer Privacy Act (“CCPA”). See below for an example. The requests were problematic for two reasons: (a) they expressly stopped short of making a formal access request, but still demanded a response within the time limits set out under applicable legislation; and (b) many recipients questioned the authenticity and bona fides of the requests based on their volume, wording and origin.
Researchers from Princeton University admitted to sending the requests as part of a research project, and apologized for the confusion caused. While this revelation rendered those specific queries moot, companies continue to receive a large volume of requests, sometimes on a massive scale, including from automated request generators (such as datarequests.org and Mine). The Princeton incident offers a timely reminder to all companies to review their processes and protocols for identifying and responding to data subject requests in compliance with applicable laws.
What rights do individuals have?
The GDPR and CCPA grant individuals rights, including the rights to access or delete their data (“DSRs”). Deadlines vary: under the GDPR, a company must respond within one month, extendable by two months for numerous or particularly complex requests. In some jurisdictions (such as the UK), controllers may pause the clock while they seek further clarification on the scope of the DSR from the requestor or authenticate their identity. Under the CCPA, companies must respond within 45 days, extendable by another 45 days where reasonably necessary. Under both the CCPA and the GDPR, deadline extensions must be justifiable.
Companies must also assist data subjects with exercising their rights. The GDPR contains a broad obligation to this end, with the GDPR recitals elaborating that this includes providing mechanisms for individuals to make requests. The CCPA similarly requires companies to designate multiple channels for submitting DSRs. Although neither regime expressly requires a company to respond to requests to explain its DSR processes, regulators may, in light of the foregoing obligations, interpret ignoring such requests as obstructing the exercise of DSRs.
Managing requests
To respond to DSRs in a timely fashion, companies must have in place a robust DSR procedure which includes the following steps:
Identify and escalate
Under the GDPR, a DSR is valid regardless of how it is technically made, which means it can be submitted by email, phone, letter or even in person. Regardless of how it was submitted and whether or not it expressly mentions the name DSR, a request should be investigated further. Likewise, the CCPA requires companies to treat requests received outside the designated channels as legitimate, or direct the requestor to use the designated channels.
Companies should train employees and vendors to recognize and escalate DSRs to a team set up to handle such requests in full, so that they can be dealt with within the set timeframes.
Authenticate
Before responding to the substance of a DSR, companies must authenticate the requestor’s identity. Failure to do so could cause the company to erase or disclose information without authorization, which is in itself a breach of privacy laws.
There is no set approach to doing this – a company should select a method of authentication appropriate to its business and the risks presented by the data it processes. For example, on the one hand, for an online service where user accounts are linked to an email address, the service provider may seek to authenticate an individual by requiring a response via the connected email account, such as clicking a link. A financial institution, on the other hand, which processes higher risk data, and generally conducts identity checks on customers during its onboarding process, may ask for photo identification. Companies may go further and require the individual to answer security questions regarding their account, such as date of account creation, home address or date of birth, to the extent the company already processes that data.
Although a company must not action a DSR before it authenticates the data subject’s identity, it may not use authentication as an excuse to delay or avoid responding to the request.
Communicate
Companies should keep individuals informed of the status of their DSR, and should without delay reach out if more information is needed (e.g. for clarification of scope or for authentication purposes). If there are any delays, the company should relay this to the individual promptly.
To respond or not to respond?
Where a customer submits a DSR, it is usually clear that the company should authenticate and respond to the request. If, however, companies have good reason to suspect that a request is not a genuine attempt by an individual to exercise, or seek more information about, a DSR (for example, if the communication is generated by a bot, contains malicious content, is not from a genuine user/customer and/or is spam) they may choose to ignore such a request. If there is any doubt, however, unless the communication presents a real threat, such as pretexting, companies should treat a request as genuine to avoid non-compliance.
Where requests ask for more information prior to submitting a DSR, a company may be able to facilitate by simply directing the requestor to the company’s FAQs or privacy policy. Whilst revisiting their DSR practices, companies should ensure that such documents are up to date, accurate and contain the information necessary to aid individuals to submit DSR requests.
How should companies deal with requests that appear to originate from a request generator? Companies should not ignore such requests on this basis alone. Automated requests should be treated as legitimate attempts to exercise DSRs absent any evidence to the contrary. A company receiving any request through a third party, via a request generator or otherwise, should satisfy itself that (a) the third party has the authority to act on behalf of the individual, e.g. by asking to see signed authorization, and (b) the data subjects’ identity has been authenticated. If the company is in any doubt it should contact the individual directly to confirm.
Example of Princeton Group research request
To Whom It May Concern:
My name is [NAME], and I am a resident of [CITY/STATE/COUNTRY]. I have a few questions about your process for responding to [General Data Protection Regulation (GDPR)/California Consumer Privacy Act (CCPA)] data access requests:
- Would you process a [GDPR/CCPA] data access request from me even though I am not a resident of the European Union/California?
- Do you process [GDPR/CCPA] data access requests via email, a website, or telephone? If via a website, what is the URL I should go to?
- What personal information do I have to submit for you to verify and process a [GDPR/CCPA] data access request?
- What information do you provide in response to a [GDPR/CCPA] data access request?
To be clear, I am not submitting a data access request at this time. My questions are about your process for when I do submit a request.
Thank you in advance for your answers to these questions. If there is a better contact for processing [GDPR/CCPA] requests regarding [DOMAIN], I kindly ask that you forward my request to them.
I look forward to your reply without undue delay and at most within [one month/45 days] of this email, as required by [Article 12 of GDPR/Section 1798.130 of the California Civil Code].
Sincerely,
[NAME]