If a request for personal data is made under the GDPR rights but the requestor refuses to give ID for verification what should the company do?

Question

A request for personal data to be deleted is made under the GDPR rights but the requestor refuses to give ID for verification and only provides an email address.

Answer 1

If the data controller has “reasonable doubts concerning the identity of the natural person making the request”, then “the controller may request the provision of additional information necessary to confirm the identity of the data subject” (Art 12(6) GDPR). Until the data subject provides this information, the request is paused.

But what are reasonable doubts, and what additional information can the controller request? The GDPR itself provides no clear guidelines, though general principles apply – the additional information must be necessary, adequate, and proportionate for the identity conformation purpose. The controller's obligation to comply with access requests must be balanced with the controller's obligation to ensure the security of data by rejecting invalid requests. Just accepting any request without any verification would also be a breach of the GDPR.

For example:

• If the company identifies data subjects by email address, then demonstrating control over the email address would be an appropriate verification step. But just mentioning the email address would not be enough since it could be someone else's email address.
• If the company provides a website where data subjects have created user accounts, then being able to log in to the account would be an appropriate verification step.
• In these examples, asking e.g. for government photo ID would not be appropriate because that doesn't help strengthen the link between the person making the request and the personal data being processed. Such data collection would be disproportionate and unnecessary.
• In contrast, if you walk into a bank and ask for a copy of your data, it would be entirely appropriate for them to ask for government ID because (a) the higher general risks warrant stronger checks, and (b) such ID will help confirm that the person making the request is indeed the proper account holder. The bank will also have been legally required to request ID when the account was originally opened, so that asking for ID as an identity verification measure during this later request won't involve collection of more data than they already have.

(These examples were made up by me and are not official, but read on.)

The EDPB has issued draft guidelines on the right of access 01/2022, which also discuss the issue of additional information for identity verification in sections 3.2 and 3.3. In particular, paragraphs 73-78 talk about IDs:

73. It should be emphasised that using a copy of an identity document as a part of the authentication process creates a risk for the security of personal data and may lead to unauthorised or unlawful processing, and as such it should be considered inappropriate, unless it is strictly necessary, suitable, and in line with national law. […] it is also important to note that identification by means of an identity card does not necessarily help in the online context (e.g. with the use of pseudonyms) […].

75. In any case, information on the ID that is not necessary for confirming the identity of the data subject, […] may be blackened or hidden by the data subject before submitting it to the controller, except where national legislation requires a full unredacted copy of the identity card (see para. 77 below). […]

76. […]

Example: The user Ms. Y has created an account in the online store, providing her e-mail and username. Subsequently, the account owner asks the controller for information whether it processes their personal data, and if so, asks for access to them within the scope indicated in Art. 15. The controller requests the ID of the person making request to confirm her identity. The controller's action in this case is disproportionate and leads to unnecessary data collection. […]

Example: A bank customer, Mr. Y,, plans to get a consumer credit. For this purpose, Mr. Y goes to a bank branch to obtain information, including his personal data, necessary for the assessment of his creditworthiness. To verify the data subject’s identity, the consultant asks for notarised certification of his identity to be able to provide him with the required information.

The controller should not require notarised confirmation of identity, unless it is strictly necessary, suitable and in line with the national law […]. Such practice exposes the requesting persons to additional costs and imposes an excessive burden on the data subjects, hampering the exercise of their right of access.

77. Without prejudice to the above general principles, under certain circumstances, verification on the basis of an ID may be a justified and proportionate measure, for example for entities processing special categories of personal data or undertaking data processing which may pose a risk for data subject (e.g. medical or health information). However, at the same time, it should be borne in mind that certain national provisions provide for restrictions on the processing of data contained in public documents, including documents confirming the identity of a person (also on the basis of Art. 87 GDPR). Restrictions on the processing of data from these documents may relate in particular to the scanning or photocopying of ID cards or processing of official personal identification numbers.

To summarize: controllers can request IDs only in comparatively niche scenarios, and must then take additional safeguards to protect the sensitive document (e.g. instructing the data subject to redact parts of the ID, not making copies, and immediately deleting the ID after successful verification). A lot here comes down to national laws, which may explicitly require or forbid use of the ID in this context.

The EDPB guidelines are not binding or normative, especially since this guidance is still in the public consultation phase. However, the guidelines present an overall consensus of the national data protection authorities in the EU, and the guidelines are regularly cited by courts.

In practice, many controllers do ask for disproportionate amounts of data. Sometimes this seems to be an attempt to discourage data subject requests, which would clearly be non-compliant. In some cases, this is due to a narrow interpretation of “reasonable doubts” in which they try to eliminate any doubt about the identity.

If the data subject and data controller cannot agree on a suitable identity verification process, then the data subject can:

• Art 77: lodge a complaint with a data protection authority, and/or
• Art 79: sue the data controller in court, both for compliance (fulfilling the request) and for compensation (if damages were suffered).

It is worth noting that the data controller is responsible for being able to demonstrate compliance (Art 5(2) accountability principle), such as demonstrating the apparent reasonable doubts to a supervisory authority or to a court. When the controller requests ID, the controller has the burden of proof to show that this is compliant.

Answer 2

First and foremost the company should seek legal advice from a professional. The GDPR is a bit of a legal minefield: if someone makes a request under the GDPR rights and it turns out that person is someone else then they claim to be, the organisation risks problems; if someone makes a request under the GDPR rights and the company wants that person to provide more information than allowed for the specific request before the request is accepted, the company risks problems.

So in short if the company is not strict enough they risk problems, but if the company is too strict they risk problems as well, so the company has to thread a fine line to prevent legal problems. amon's answer demonstrates this quite clearly.

A legal professional can write down clear instructions for the company, that they can follow for every request under the GDPR rights. It's a one time investment that can save the company a lot of money.