Under the GDPR, how may a controller verify a requester's identity, and when may it refuse or charge for a data subject request?

middleshould knowfreq 44%

answer

doubt triggers the check
only what is necessary
free unless manifestly unfounded
the controller carries the burden
Art. 12(5) and 12(6)

basics

~20 s

Under GDPR Art. 12(6), a controller with reasonable doubts may ask only for the extra information necessary to confirm identity. Requests are free; under Art. 12(5) it may charge a reasonable fee or refuse only manifestly unfounded or excessive ones, and must prove that.

solid answer

~50 s

Under the GDPR, both questions are answered in Art. 12. Where the controller has reasonable doubts about who is asking, Art. 12(6) lets it request the additional information necessary to confirm identity — so for an account-based service the proportionate check is usually proof of control of the account, not a new identity document. Recital 64 adds that a controller should not keep data solely to react to possible requests, and Art. 11 relieves it of identifying people it genuinely cannot identify, unless they supply information that allows it. Requests are free (Art. 12(5)); only a manifestly unfounded or excessive request — the text's example is a repetitive one — may be met with a reasonable fee or a refusal, and the controller bears the burden of demonstrating that. A refusal is explained within one month, with the options to complain and seek a judicial remedy (Art. 12(4)).

Under the GDPR, both questions are answered in `Art. 12`. Where the controller has **reasonable doubts** about who is asking, `Art. 12(6)` lets it request the additional information *necessary* to confirm identity — so for an account-based service the proportionate check is usually proof of control of the account, not a new identity document. Recital 64 adds that a controller should not keep data solely to react to possible requests, and `Art. 11` relieves it of identifying people it genuinely cannot identify, unless they supply information that allows it. Requests are **free** (`Art. 12(5)`); only a **manifestly unfounded or excessive** request — the text's example is a repetitive one — may be met with a reasonable fee or a refusal, and the controller bears the burden of demonstrating that. A refusal is explained within one month, with the options to complain and seek a judicial remedy (`Art. 12(4)`).

code

json · 15 lines

json

{
  "requestId": "dsr-2026-0412",
  "receivedAt": "2026-03-02",
  "rightsInvoked": ["portability"],
  "channel": "email",
  "identityCheck": {
    "reasonableDoubt": true,
    "reason": "sender address not registered on any account",
    "additionalInfoRequested": "confirmation link sent to registered account email",
    "requestedAt": "2026-03-02"
  },
  "dueBy": "2026-04-02",
  "extension": null,
  "outcome": "pending"
}

go deeper

for a junior

Recall that data subject requests are free, that identity may be checked only when there is reasonable doubt, and that a refused request still needs a reply within one month.

for a middle

Explain the necessity limit in Art. 12(6), what Art. 11 does when a controller cannot identify someone, and why the controller, not the requester, must demonstrate a request is manifestly unfounded or excessive.

for a senior

Design the intake: proportionate identity checks per channel, a log recording receipt date and each decision, and a path for refusals that gives reasons and complaint options on time.

for a principal

Balance the two failure modes: releasing data to an impostor against over-collecting identity documents. Set an organisation-wide verification standard that is proportionate per channel and defensible later.

The situation

A video-streaming subscription service receives three requests in the same week: an access request sent from inside a subscriber's logged-in account, an erasure request by email from the address registered on that account, and a portability request from an email address the service has never seen, naming a subscriber. Under the GDPR, the controller must answer all three within the Art. 12(3) timeline, and it must not hand one person's data to somebody else. Art. 12 governs how.

Verifying identity without collecting more data

Art. 12(6): where the controller has reasonable doubts concerning the identity of the natural person making a request under Arts. 15 to 21, it may request the provision of additional information necessary to confirm the identity of the data subject. The wording has three consequences:

Doubt is the trigger. A request made from inside an authenticated session usually raises no reasonable doubt that further documents would resolve, so demanding extra proof as a routine step goes beyond what the paragraph allows.
Necessity limits the ask. What may be requested is what is needed to match the requester to data already held. For an account identified by email and a payment reference, confirming control of the registered address is proportionate; collecting a government identity document the service never held adds new personal data in order to verify old.
Scope. The paragraph names requests under Arts. 15 to 21.

Recital 64 frames the duty from both sides: the controller should use all reasonable measures to verify identity, in particular in the context of online services and online identifiers, and it should not retain personal data for the sole purpose of being able to react to potential requests.

When the controller cannot identify the person

Art. 11 covers processing that does not require identification. If the controller's purposes do not, or no longer, require identifying the person, it is not obliged to maintain, acquire or process additional information just to comply with the Regulation. Where it can demonstrate that it is not in a position to identify the person, it informs them if possible, and Arts. 15 to 20 do not apply — unless the person provides additional information enabling identification. Art. 12(2) closes the loophole from the other side: the controller shall not refuse to act on a request unless it demonstrates that it is not in a position to identify the data subject.

Free by default, with a narrow exception

Art. 12(5): communications and actions under Arts. 15 to 22 are free of charge. Where requests are manifestly unfounded or excessive, in particular because of their repetitive character, the controller may either:

charge a reasonable fee taking into account the administrative costs of providing the information or taking the action, or
refuse to act on the request.

The controller bears the burden of demonstrating the manifestly unfounded or excessive character. Three requests exercising three different rights in one week are not repetitive by that measure: each asks for something different. The same access request filed every few days with nothing changed in between is closer to the text's own example.

Timing and refusal

Step	Provision	Rule
Respond	Art. 12(3)	Without undue delay, at the latest one month from receipt
Extend	Art. 12(3)	Two further months for complexity or number of requests, announced within the first month with reasons
Decline	Art. 12(4)	Without delay and at the latest within one month, with reasons and the possibility of a complaint and a judicial remedy
Channel	Art. 12(3)	An electronic request is answered electronically where possible, unless the person asks otherwise

For the unknown email address, the service cannot yet link the requester to the subscriber, so it asks for information necessary to confirm identity — for example, a confirmation sent to the registered address — instead of either ignoring the request or releasing the data. It records the date of receipt, because the text measures the month from receipt.

Keeping a record

Several of these rules put the burden of proof on the controller: that a request was excessive (Art. 12(5)), or that it could not identify the person (Arts. 11(2) and 12(2)). A per-request log — received date, rights invoked, identity step taken, deadline, any extension notice and the outcome — is how that burden is met later.

Common mistakes

Demanding a passport scan for every request, including those from authenticated sessions.
Ignoring requests that arrive through an unexpected channel.
Treating several different requests from one person as excessive.
Charging a standard administrative fee for every request.
Refusing without telling the person why and where they can complain.

## The situation A video-streaming subscription service receives three requests in the same week: an **access** request sent from inside a subscriber's logged-in account, an **erasure** request by email from the address registered on that account, and a **portability** request from an email address the service has never seen, naming a subscriber. Under the GDPR, the controller must answer all three within the `Art. 12(3)` timeline, and it must not hand one person's data to somebody else. `Art. 12` governs how. ## Verifying identity without collecting more data **Art. 12(6)**: where the controller has *reasonable doubts* concerning the identity of the natural person making a request under Arts. 15 to 21, it may request the provision of additional information **necessary to confirm the identity** of the data subject. The wording has three consequences: - **Doubt is the trigger.** A request made from inside an authenticated session usually raises no reasonable doubt that further documents would resolve, so demanding extra proof as a routine step goes beyond what the paragraph allows. - **Necessity limits the ask.** What may be requested is what is needed to match the requester to data already held. For an account identified by email and a payment reference, confirming control of the registered address is proportionate; collecting a government identity document the service never held adds new personal data in order to verify old. - **Scope.** The paragraph names requests under Arts. 15 to 21. Recital 64 frames the duty from both sides: the controller should use all reasonable measures to verify identity, in particular in the context of online services and online identifiers, and it **should not retain personal data for the sole purpose of being able to react to potential requests**. ## When the controller cannot identify the person **Art. 11** covers processing that does not require identification. If the controller's purposes do not, or no longer, require identifying the person, it is not obliged to maintain, acquire or process additional information just to comply with the Regulation. Where it can demonstrate that it is not in a position to identify the person, it informs them if possible, and Arts. 15 to 20 do not apply — **unless** the person provides additional information enabling identification. **Art. 12(2)** closes the loophole from the other side: the controller shall not refuse to act on a request unless it demonstrates that it is not in a position to identify the data subject. ## Free by default, with a narrow exception **Art. 12(5)**: communications and actions under Arts. 15 to 22 are **free of charge**. Where requests are **manifestly unfounded or excessive**, in particular because of their repetitive character, the controller may either: 1. charge a reasonable fee taking into account the administrative costs of providing the information or taking the action, or 2. refuse to act on the request. The controller **bears the burden of demonstrating** the manifestly unfounded or excessive character. Three requests exercising three different rights in one week are not repetitive by that measure: each asks for something different. The same access request filed every few days with nothing changed in between is closer to the text's own example. ## Timing and refusal | Step | Provision | Rule | |---|---|---| | Respond | Art. 12(3) | Without undue delay, at the latest one month from receipt | | Extend | Art. 12(3) | Two further months for complexity or number of requests, announced within the first month with reasons | | Decline | Art. 12(4) | Without delay and at the latest within one month, with reasons and the possibility of a complaint and a judicial remedy | | Channel | Art. 12(3) | An electronic request is answered electronically where possible, unless the person asks otherwise | For the unknown email address, the service cannot yet link the requester to the subscriber, so it asks for information necessary to confirm identity — for example, a confirmation sent to the registered address — instead of either ignoring the request or releasing the data. It records the date of receipt, because the text measures the month from receipt. ## Keeping a record Several of these rules put the burden of proof on the controller: that a request was excessive (`Art. 12(5)`), or that it could not identify the person (`Arts. 11(2)` and `12(2)`). A per-request log — received date, rights invoked, identity step taken, deadline, any extension notice and the outcome — is how that burden is met later. ## Common mistakes - Demanding a passport scan for every request, including those from authenticated sessions. - Ignoring requests that arrive through an unexpected channel. - Treating several different requests from one person as excessive. - Charging a standard administrative fee for every request. - Refusing without telling the person why and where they can complain.

Under the GDPR, may a controller keep a closed account's data so it can verify future requests from that person?
Not for that reason alone. Recital 64 says a controller should not retain personal data for the sole purpose of being able to react to potential requests, and Art. 11(1) says it need not keep or acquire information just to identify someone for the Regulation's sake. Any retention needs its own purpose, such as a legal obligation.
Under the GDPR, does asking for identity information pause the one-month clock?
The text of Art. 12(3) runs the month from receipt of the request and says nothing about pausing it. How the waiting time is treated is a question of regulator guidance, not of Art. 12's wording, so the safe practice is to ask for identity information immediately, ask only for what is necessary, and record both dates.

saying these in an interview costs you the question

Always demand a passport copy before answering any data subject request
A request from an unverified sender can be ignored and creates no duty
Several requests from one person in a week are excessive by definition
A standard administrative fee may be charged for every request
The data subject must prove their request is reasonable

Under the GDPR, how may a controller verify a requester's identity, and when may it refuse or charge for a data subject request?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The situation

Verifying identity without collecting more data

When the controller cannot identify the person

Free by default, with a narrow exception

Timing and refusal

Keeping a record

Common mistakes

▾common follow-ups2 questions

▾red flags5 flags

The situation

Verifying identity without collecting more data

When the controller cannot identify the person

Free by default, with a narrow exception

Timing and refusal

Keeping a record

Common mistakes

answer

go deeper