GDPR identity verification for access requests

How much identity checking can a GDPR controller do before answering a request?

If your access request channel asks requesters for a passport or an ID copy, you are likely collecting more than the GDPR allows. Under Article 12(6), a controller may request additional information needed to confirm identity only where it has reasonable doubt about who is asking, and any such check must be proportionate. A request sent from an address the customer does not usually use, or one made outside an authenticated account, can justify a follow-up question. A default demand for identity documents from every requester generally cannot be defended on that basis. The right answer depends on the data set, the channel and what you already hold. If the requester is logged into an account you maintain, the account session may already establish identity for most data. If the data is held in a system with no link to a verified account, you may need a proportionate step such as a confirmation sent to contact details already on file, or a question only the data subject could answer. Each channel and data set needs its own decision, and the decision should be written down with the reason for each request type. Pseudonymised data and activity logs remain personal data in scope, so identity checks must be designed with those records in mind too. The organization owns this decision. Its privacy or legal function sets the verification standard, approves when extra information may be requested, and handles requests where identity cannot be established. An implementation partner can prepare the technical side: intake forms that collect only the fields needed, authenticated routes for logged-in customers, request logs that record the verification step taken, and evidence showing the procedure is applied consistently. Confirm with your partner exactly which records will be created and how long they are kept, because the logs themselves contain personal data. Only an independent auditor or a national supervisory authority assesses whether your procedure complies. Neither the partner nor a certificate can settle the question on your behalf.

Which verification methods are proportionate?

Verification should start with the least intrusive check that gives reasonable confidence and escalate only when doubt remains. The cards below run from the lightest step to the heaviest, and each one notes when it fits and what personal data it collects. Requests for extra identity information must be proportionate to avoid excessive data collection.

Reply to the registered email

Send a confirmation to the email address already held for the customer and treat a reply from that address as the first check. This fits when the request arrived from the same address the controller has on file. It collects almost nothing new, but the controller should confirm that the address itself is current and that the reply came from it. If the request came from a different address, the EDPB's small business guidance treats that as a reason for doubt that may justify asking for more.

Sign-in through an existing account

Ask the requester to submit the request while signed in to the authenticated customer account, or to log in again before the request is processed. This fits requests made outside an account where the controller already runs authentication. It collects no new personal data, because the account's own credentials do the work. Check that the login flow itself is protected, since a weak sign-in process undermines the check.

One-time code to a number on file

Send a single-use code to a mobile number or device already linked to the account, then ask the requester to enter it. This fits when email evidence is weak but the controller holds a verified phone number. It collects no new data beyond the code exchange. Confirm that codes expire quickly, that they are not sent to numbers added during the same request, and that repeated attempts are limited.

Account-specific details already held

Ask a question only the account holder could answer from information the controller already has, such as the date of the last order or the reference of a recent contract. This fits when channels above are unavailable. It collects no new categories of data, but questions based on sensitive or widely public facts add risk. Choose details that are hard to guess and avoid asking for data the controller does not hold.

Document check as a last resort

Request a copy of an identity document only when reasonable doubt remains after the checks above. This is the most intrusive step because it collects sensitive identity data that the controller then has to protect. Ask only for what confirms identity, allow redaction of details not needed for matching, and delete the copy once verification is complete. Document the reason for escalating so the decision can be defended to a supervisory authority.

Why excessive ID demands draw enforcement attention

Asking for identity documents the controller does not need is a processing problem in its own right. Each copy of a passport or national ID collected for a rights request is personal data that must satisfy the data minimisation and purpose limitation principles in Article 5, and it must then be stored, secured and eventually deleted. Where the controller already holds the requester's data, the extra document often adds little confidence beyond what an authenticated account or a verified email address already provides. The request also becomes harder to exercise, which undermines the right itself. Before setting any identity check, the team should write down the minimum data needed to match the requester to the records it holds.

The problem is visible to regulators. The EDPB's 2024 coordinated action on the right of access, whose report was adopted in January 2025, involved 30 data protection authorities and 1,185 responding controllers. Among the challenges it identified were undocumented procedures and excessive identification demands. For a privacy or security team, this means the identity check is part of the procedure that regulators examine. A written verification standard that lists each request channel, the signals that trigger extra checks and the information requested in each case is the evidence an assessor or supervisory authority will expect to see. Confirm with your data protection officer or counsel that this standard is documented and applied consistently across all channels.

Enforcement follows these failures. The EDPB's news item on the Spanish supervisory authority's decision reports a EUR 100 000 fine on Securitas Direct, dated 22 September 2026, under a headline describing the making of the exercise of data subject rights difficult. Readers should obtain the decision itself, or ask counsel to review it, before drawing conclusions about which identification practices it addressed. In the meantime, review your own intake forms and answer three questions: does each requested field have a documented purpose, is there a lower-risk route for requests made from authenticated accounts, and are copies of identity documents deleted once the check is complete? Record each answer so it can be produced to an assessor.

How verification differs by channel and data set

When a request arrives through a logged-in customer account, the controller already holds a strong signal of identity. The session was authenticated under the controller's own login controls, so in most cases no further proof is needed to act on the request. The main task is to confirm that the session belongs to the account holder and that the request is not coming through a shared or hijacked session.

Use the session as the check: Accept requests submitted from an active, authenticated session without asking for an ID document.
Confirm session strength: Review whether the login uses multi-factor authentication for sensitive actions, since a weak login weakens the signal.
Watch for step-up triggers: Ask for re-authentication when the request changes the account, such as a new email address, before exporting data.
Avoid duplicate collection: Do not ask for identity documents the controller already holds from account opening.
Log the channel: Record that the request came from an authenticated session so the decision can be defended later.

Check that your portal's session and re-authentication controls are documented and tested, because the decision to skip extra checks depends on them.

What applies when the controller cannot identify the person at all?

If a controller can show it cannot identify the data subject, Articles 15 to 20 do not apply, unless the person supplies extra information that enables identification. Article 11 covers this case. It applies where the controller's purposes no longer require identifying individuals, so the controller has no duty to keep or obtain additional data just to comply with the GDPR. The burden sits with the controller. It must be able to demonstrate the inability to identify, and an assertion without evidence will not hold up. For a system team, that means recording which identifiers the platform holds, whether they link to a person, and why the controller cannot match a request to a record. Pseudonymised data remain personal data under the EDPB's guidance, so a system keyed only on an opaque ID is not automatically outside scope. Confirm with counsel or the DPO whether your holdings truly fall under Article 11 before relying on it.

The Article 11 position does not remove the duty to respond. Where the controller relies on it, the requester should still hear back, and the controller should explain what it searched, why it cannot link the request to any record, and what the person could send to allow identification. Asking for that information must itself be proportionate, so the controller should not request more personal data than the match requires. Under Article 12(4), if the controller does not act on a request, it must inform the person within one month of the reasons for not acting, and of the right to lodge a complaint with a supervisory authority and to seek a judicial remedy. Build a standard response template with those elements and a log entry for each refusal, so the one-month clock and the reasons are documented from the start.

Ask counsel or the DPO to sign off on three decisions before the position is used in practice: the list of identifiers the platform holds, the search that supports the claim of non-identification, and the wording of the explanation sent to the requester. Keep the search steps and their results as evidence, since the claim will be tested against them if a supervisory authority reviews the request. Where the controller holds some data that can be linked to the person, Article 11 will not apply to that data, so the search must cover every system and log before any conclusion is drawn.

Steps to set a verification procedure that holds up

This sequence turns identity checking from case-by-case judgment into a written procedure that limits what a controller asks for, records why each check was made, and keeps the response inside the one-month deadline.

Map every intake channel for rights requests
List each route a request can arrive by, including the web form, the support inbox, postal mail, phone, social media and any staff member who receives a request in conversation. Note which channels run through an authenticated customer account and which do not, and who owns each one. The step is done when the list is signed off by the privacy lead and every channel has a named owner who knows how to log a request and start the clock.
Define the doubt triggers in writing
Set out the specific circumstances that give the controller reasonable doubt about who is asking, such as a request sent from an address other than the one the customer normally uses or a request made outside an authenticated account. Also state what does not justify doubt on its own, so that staff do not default to checks. The output is a short trigger table that the people handling requests can apply without escalation for routine cases.
Set the proportionate check ladder
Define the verification steps in order of increasing intrusiveness, starting with the simplest, such as confirming a detail already held on the account or replying to the address on file. Only move to a further step when the lower one fails to resolve doubt, and specify the data each step may ask for so that no check collects more than the purpose needs. The finished ladder is a document that lists each step, the data it requests, and the condition for moving up.
Record each decision and its reason
Create a decision log with one entry per request that captures the channel, the trigger that raised doubt if any, the check applied, the outcome and the reason for it. Keep the log separate from the request content so it documents the verification choice without copying the extra identity data into more places. The step is complete when a sample of entries can be traced from intake to decision by someone who did not handle the request.
Set the one-month clock and explanation template
Fix the point at which the one-month period starts in the procedure, including how a pending identity check affects it, and assign who monitors the deadline. Prepare a template for the case where the controller will not act, which must give the reasons, state the possibility of complaining to a supervisory authority and seeking a judicial remedy, and be issued within the one-month period. The outputs are the deadline rule and the approved template, both checked by counsel or the DPO where one exists.
Prepare the request messages and staff guidance
Write the standard messages that ask for further information, including the wording that explains why the check is needed and what will be done with the data. Brief support and front-line staff on the trigger table and ladder so that requests are handled the same way across teams. The step is done when each message template is approved and the briefing has been delivered and recorded.
Review the procedure after each request type
After each new type of request, such as an erasure after a dispute or a request made through a third party, review the decision log to see whether the triggers and ladder worked. Update the procedure, record the change and the date, and tell staff what changed. The output is a dated revision history that shows the procedure is kept current and that checks are not drifting toward excessive demands.

What a readiness review should confirm before go-live

A readiness review tests whether identity checks work in practice before the first real request arrives. The cards below cover the written procedure, the intake channels, the proportionality of identity checks, the handling of logs and search activity, decision records and the one-month explanation. Each check should be run with a sample request in the organization's own environment, and the results kept as evidence.

Procedure is written and approved

Confirm that a written identity verification procedure exists, names an owner, and has been approved by the people accountable for data protection decisions. The procedure should state when doubt is reasonable, which additional information may be requested, and who decides. To test it, pick a scenario such as a request from an unfamiliar email address and have a staff member follow the document step by step without outside help. If they cannot reach a decision from the text alone, the procedure is not ready.

Every intake channel is listed

List each route a request can arrive through, including the web form, support mailbox, postal mail, phone line, customer portal and any messages received by staff in product teams. Each channel should map to a documented verification path, because identity doubt often arises only on channels outside the authenticated account. To test it, send a sample request through each channel and confirm that it reaches the queue, is logged with a timestamp, and triggers the correct verification step.

Identity checks match minimisation

Check that the information requested to confirm identity is no more than the purpose requires, and that requests for extra information are proportionate. Asking for a national identity document for every request is hard to justify when an authenticated session or a confirmation sent to the registered address would do. To test it, compare the fields requested in the verification form against the data already held for that person, and have a reviewer mark any field that could be dropped.

Logs and search activity handled as personal data

Verify that the systems used to verify identity, including ticketing tools, mail archives and access logs, treat records of verification and search activity as personal data within scope. Pseudonymised records still count. Confirm retention periods, access restrictions and whether these records are returned in an access response. To test it, run a sample request through the full workflow, then check where verification notes, search queries and log entries were written and who can read them.

Decisions documented for each request

Confirm that every verification decision is recorded with the date, the trigger for any doubt, the information requested, what was received and the outcome. A decision that is not written down cannot be shown to a supervisory authority later. To test it, complete a sample request where identity is first doubted and then confirmed, and check that the case record alone is enough for a second reviewer to reconstruct what happened and why.

One-month explanation template exists

Confirm that a template exists for telling a requester why a request has not been acted on, including when identity cannot be confirmed. Under Article 12(4), the explanation must be given within one month and must mention the right to complain to a supervisory authority and to seek a judicial remedy. To test it, generate the letter for a sample unverified request, check that every required element is present, and confirm the deadline is calculated from the date the request was received.

Questions buyers ask about identity checks for GDPR requests

Can we always ask for a passport when someone makes a GDPR request?

No. A controller may request additional information only where it has reasonable doubts about the requester's identity, and the information asked for must be proportionate to that doubt. Article 12(6) allows checks to confirm identity, but it does not make a passport or national ID the default. Examples of reasonable doubt include a request sent from an email address other than the one the customer normally uses, or a request made outside an authenticated customer account. For those cases, a lighter step such as replying to the registered address or asking a question only the account holder would know is usually enough. Asking for more data than the purpose needs is itself a compliance risk, because it creates a new data set that must be protected and justified. Document the reason for each extra check.

Does a logged-in user still need extra identity checks?

Usually not. When a request comes through an authenticated customer account, the session already gives strong evidence that the requester controls that account, so the controller normally has no reasonable doubt that would justify further checks. The exception is a case where something suggests the session may have been compromised, such as a sudden change of contact details before the request or an unusual access pattern. Your engineering team should confirm that the portal's authentication strength, session handling and access to the export function are adequate for this reliance. Authentication weaknesses in the portal then become a question about Article 32 security, not only about rights handling.

What does a readiness review cost, and who pays for it?

DeployOpen does not publish a price list. A quote follows from a written scope, so the cost depends on what the review covers, such as how many intake channels, identity paths and systems are examined and how many staff interviews and procedure documents are involved. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Your organization pays the implementation partner for the review; it does not pay an auditor, because the GDPR requires no audit or certificate. Ask any provider for a quote that separates the review from any follow-on remediation work, and that states which items are one-time and which recur, such as retained support.

How long does a readiness review take?

The duration depends on the written scope, and no fixed figure applies to every organization. The main drivers are the number of request channels, how many identity paths exist (for example, portal, email, phone and postal), how many systems hold the data needed to confirm identity, and how much existing procedure documentation is available. A narrow review of a single intake channel will take far less time than a review that covers several business units and processors. Ask the provider to state the deliverables and the dates they depend on, including the dates your own staff must meet for interviews and document access.

Can we verify identity ourselves without an outside partner?

Yes. The organization owns its controls and its rights-handling procedure, so an internal team can design and run identity checks without outside help. The work to plan is a written procedure that sets the trigger for doubt, the proportionate checks for each channel, the data each check may collect, how long that data is kept, and how each decision is recorded. An outside partner can add value by preparing systems, logs and evidence, or by testing the portal and intake channels, but it does not replace the controller's accountability. Confirm internally who makes the final decision on a disputed request and who can answer for it to a supervisory authority.

Does an auditor certify that our identity verification procedure is compliant?

No. The GDPR requires no audit, attestation or certificate, and no independent body issues a GDPR certificate for your identity checks. Certification under Article 42 is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the controller's or processor's responsibility for compliance. A supervisory authority judges the procedure in practice when it investigates a complaint. Any provider who claims to certify your procedure or grant a GDPR seal should be questioned closely. A readiness review produces findings and evidence for your own assessment, not a certificate or report.

How DeployOpen prepares intake and evidence for request handling

DeployOpen works on the systems that receive and verify rights requests, inside your own infrastructure. We scope the identity checks your organization is entitled to run, build the intake and verification workflow on self-hosted open-source platforms, and document each decision so your team can show why a check was proportionate.

How we scope

Written scope defines which request channels, authenticated account paths and verification steps are covered.
Scope lists the request types, such as access and erasure, that the verification workflow must support.
Scope records which systems hold identity data and which teams approve exceptions to the verification process.

How we build

We configure intake channels so requests from authenticated accounts and other channels reach the same verification queue.
We implement proportionate checks that request only the extra information needed to confirm identity.
We test that pseudonymised records and activity logs are handled consistently when a requester cannot be identified.

How we hand over

Deliverables include written verification procedures, configuration records and a log of each identity decision.
Documentation explains when additional information is requested, what is collected and how it is deleted afterwards.
Your staff receive a handover covering how to escalate doubtful requests and how to explain any delay.

How we support

Ongoing support is available as a retainer for updates to verification workflows and intake channels.
We can review verification records periodically so procedures keep matching how your team actually works.
Confirm with your counsel or data protection officer which final decisions on identity remain with your organization.

Verifying identity for GDPR data subject requests