Data subject access requests create an interesting paradox for organizations. You're legally required to hand over personal information when someone asks for it. But you're equally obligated to protect that same information from falling into the wrong hands.
This tension sits at the heart of identity verification under GDPR. Get it wrong, and you're either breaching data protection laws by disclosing information to an imposter, or you're unlawfully refusing a legitimate request.
A 2019 security researcher demonstrated just how broken identity verification can be. With nothing more than his fiancée's permission (and her email address), he submitted data subject requests to 150 organizations. The results were alarming. Nearly a quarter of responding companies accepted just an email and phone number as proof of identity before handing over credit card details, social security numbers, passwords, and other sensitive data. Another 16% requested ID documents that were trivially easy to forge.
The researcher wasn't even trying particularly hard. He used basic information that any determined fraudster could obtain. Yet organizations rolled out the red carpet and handed over treasure troves of personal data.
This isn't a theoretical problem. Identity verification failures have real consequences for data subjects and organizations alike.
Table of contents
- Legal requirements for verifying identity
- What counts as reasonable verification
- Common verification methods and their effectiveness
- Balancing security with accessibility
- When you can request additional information
- Special considerations for different request types
- Handling requests from representatives
- What happens when verification fails
- Documentation requirements
- Training staff on verification procedures
- Technology solutions for identity verification
Legal requirements for verifying identity
GDPR Article 12(6) gives controllers the explicit right to request additional information to confirm the identity of a data subject. But this isn't just a right. It's an obligation when you have reasonable doubts about who's making the request.
Recital 64 of GDPR spells it out clearly: "The controller should use all reasonable measures to verify the identity of a data subject who requests access, in particular in the context of online services and online identifiers."
Courts treat recitals as interpretive guides. When judges need to understand what GDPR actually means, they look at these recitals. So Recital 64 carries serious weight.
The UK Data Protection Act 2018 reinforces this requirement. Controllers must take reasonable steps to verify identity before acting on a request or releasing information to someone they don't already know.
Here's where it gets practical. The one-month deadline for responding to subject access requests doesn't start ticking until you receive either the information needed to clarify the request OR the information needed to confirm the requester's identity, whichever comes later.
This timing matters. Organizations sometimes panic about the clock and rush to fulfill requests without proper verification. Bad idea. The law explicitly gives you time to verify identity first.
The Information Commissioner's Office (ICO) has been clear on this point. You must comply with a request within one month of receiving it, or within one month of receiving any requested information to confirm the requester's identity. The law recognizes that verification takes time.
But there's a catch. You can't use verification as a stalling tactic. The requirement is for "reasonable measures," not perfect certainty. You can't demand excessive documentation or create unnecessary hoops for requesters to jump through.
What counts as reasonable verification
Reasonable verification depends on context. What's appropriate for a low-risk request might be woefully inadequate for high-risk personal data.
The ICO considers several factors when evaluating whether verification measures are reasonable:
- The nature of the personal data you hold
- How sensitive that information is
- The potential harm from unauthorized disclosure
- How much you already know about the requester
- The channel through which the request arrived
If someone contacts you through their registered account on your system, you've already got built-in verification. They authenticated themselves when they logged in. Requesting additional proof of identity would be excessive in most cases.
But if someone emails you from a Gmail account claiming to be a customer and asking for all their data? That requires more scrutiny.
Online contexts present particular challenges. You're dealing with digital identities rather than face-to-face interactions. Recital 64 specifically calls out online services and online identifiers as areas requiring careful attention to verification.
The key principle is proportionality. Your verification measures should match the risk. High-risk data demands stronger verification. Routine data from existing customers who've authenticated through normal channels needs less.
Consider what information you're about to disclose. Medical records? Financial data? Employment history? These categories demand robust verification. Basic contact preferences for marketing emails? Less critical.
You also need to think about the potential damage. If someone gains unauthorized access to another person's data through your response to a fraudulent request, you've created a data breach. And you'll be liable for it.
Common verification methods and their effectiveness
Organizations use various methods to verify identity. Not all of them work equally well.
Knowledge-based authentication asks requesters to provide information that only the real data subject should know. This might include account numbers, recent transaction details, or answers to security questions.
The problem? Much of this information isn't actually secret. Fraudsters can obtain account numbers, transaction histories, and answers to common security questions through social engineering or data breaches.
Mother's maiden name? Available in genealogy databases. First pet's name? Often shared on social media. These traditional security questions provide minimal actual security.
Better knowledge-based questions focus on recent interactions or account activity that wouldn't be publicly available. "What was the amount of your last transaction?" or "What payment method did you use on your most recent order?" These are harder to guess or research.
Document verification requires requesters to submit copies of government-issued ID. This could be a passport, driver's license, or national ID card.
Document verification sounds robust. But it has weaknesses. Fake IDs are readily available. Even genuine documents can be stolen or photographed without the owner's knowledge. And you're asking people to send copies of sensitive identity documents via email or postal mail, creating new privacy risks.
If you request document verification, you need secure channels for submission. Encrypted email at minimum. Better yet, a secure portal where documents can be uploaded safely.
Two-factor authentication works well when you already have the data subject's contact information on file. You send a code to their registered phone number or email address. They provide that code back to confirm they control those communication channels.
This method assumes your existing records are accurate and that the communication channels haven't been compromised. It's quite effective for routine requests but can fail if someone has already hijacked the email account or phone number.
In-person verification offers the highest level of certainty but creates significant barriers for requesters. Most organizations can't require data subjects to physically visit an office to make a request. The burden would be unreasonable.
Callback verification involves calling the data subject at a number you already have on record. This works for phone-based requests but requires you to have accurate phone data.
The table below summarizes common verification methods:
| Verification method | Strength | Weaknesses | Best use cases |
|---|---|---|---|
| Knowledge-based questions | Medium | Information may be publicly available or easily guessed | Routine requests from known customers |
| Document verification | High | Risk of forgery, creates new privacy concerns | High-risk data disclosure |
| Two-factor authentication | High | Requires accurate existing contact info | Requests from authenticated users |
| In-person verification | Very high | Creates unreasonable burden on requesters | Extremely sensitive cases only |
| Callback to registered number | Medium-high | Requires accurate phone records | Phone-based requests |
Balancing security with accessibility
Here's the tension. Verification needs to be robust enough to prevent fraud but accessible enough that legitimate requesters can actually exercise their rights.
Make verification too difficult, and you're effectively denying people access to their data. The law doesn't look kindly on that. GDPR rights are fundamental. Creating insurmountable barriers to exercising those rights violates the regulation's spirit and letter.
But make verification too easy, and you're handing out personal data to anyone who asks. That's a data breach waiting to happen.
The sweet spot lies in risk-based verification. Match your requirements to the sensitivity of what you're disclosing.
For low-risk requests (say, confirming what marketing emails someone is subscribed to), minimal verification might suffice. An email to the address on file with a confirmation link could be enough.
For medium-risk requests (general account information, purchase history), moderate verification makes sense. This might involve answering questions about recent account activity plus confirmation via a registered email or phone number.
For high-risk data (financial information, health records, data that could enable identity theft), you need stronger measures. Multiple verification factors, document checks, or even in-person verification might be justified.
Think about your existing relationship with the requester too. If someone has been a customer for years and is making a request through their authenticated account, you already have substantial evidence of their identity. Requesting additional verification might be overkill.
New requesters with no existing relationship to your organization deserve more scrutiny. You don't know them. You have no baseline to work from. Asking for stronger verification is reasonable.
The ICO recommends a proportionate approach. Don't demand more information than you need. Don't create unnecessary obstacles. But do take the steps necessary to satisfy yourself that the person making the request is who they claim to be.
When you can request additional information
You can request additional information to verify identity whenever you have reasonable doubts about who's making the request.
But you can't go on a fishing expedition. You can only ask for information necessary to confirm identity. You can't use verification as an excuse to gather more personal data than you need.
The information you request should be:
- Necessary for verification purposes
- Proportionate to the risk
- Limited to what's actually needed
- Handled securely once received
If you request copies of ID documents, you should delete them once verification is complete. Don't keep identity documents on file indefinitely. That creates new data protection obligations and risks.
You must inform requesters clearly about what additional information you need and why you need it. Vague requests for "proof of identity" aren't sufficient. Be specific.
Tell them:
- What documents or information you require
- Why you need this information
- How you'll use it
- How you'll protect it
- When you'll delete it
The one-month response deadline stops while you're waiting for verification information. But you need to request it promptly. You can't wait three weeks and then suddenly decide you need verification.
If the requester provides inadequate verification information, you can ask again. But you need to explain clearly what was inadequate and what would be acceptable.
Special considerations for different request types
Access requests carry different risks than erasure requests. The verification requirements should reflect these differences.
Access requests involve disclosing information. This creates the highest risk of unauthorized disclosure. Someone pretending to be the data subject could gain access to sensitive personal data.
Strong verification is appropriate for access requests, particularly when the data is sensitive or could be misused.
Erasure requests (right to be forgotten) involve deleting data rather than disclosing it. The risk profile is different. An impostor making an erasure request causes inconvenience and potential service disruption, but doesn't gain access to the data.
You still need to verify identity for erasure requests. But the threshold might be slightly lower than for access requests. The harm from mistakenly honoring a fraudulent erasure request is generally less severe than from mistakenly disclosing data.
Rectification requests ask you to correct inaccurate data. Verification is important here too. An impostor could change contact information, payment details, or other data to facilitate fraud.
If someone requests rectification of their email address or phone number, that's actually a red flag. Fraudsters often try to change contact information first, then make access requests to the new address.
Restriction requests ask you to limit processing of personal data. These carry lower risk than access requests but higher risk than erasure. Moderate verification is appropriate.
Data portability requests combine access and potential transfer to another controller. These deserve the same verification scrutiny as standard access requests.
Objection to processing requests vary in risk depending on what processing the data subject is objecting to. Verify accordingly.
Handling requests from representatives
Sometimes a third party makes a request on behalf of a data subject. This could be:
- A parent acting for a child
- A legal representative with power of attorney
- A solicitor representing a client
- An executor dealing with a deceased person's estate
- Someone with a court order
These situations require verification of both the representative's identity and their authority to act on behalf of the data subject.
For parental requests on behalf of children, you need to verify:
- The requester's identity
- Their parental relationship to the child
- Their parental responsibility (which isn't always automatic)
Birth certificates can verify the parental relationship. But they don't necessarily prove parental responsibility. Separated or divorced parents may have complex custody arrangements.
For power of attorney situations, you need to see the actual power of attorney document. Not all powers of attorney grant authority to make data protection requests. Check that the document specifically covers this.
Solicitors representing clients should provide evidence of their professional status and their client's authorization. A letter on law firm letterhead signed by the client usually suffices.
Executors should provide proof of their appointment, typically through probate documents.
Court orders speak for themselves. If a court has ordered you to disclose information to someone, verify that the order is genuine and check its specific terms. But you'll need to comply.
Be cautious with representative requests. They're a common vector for fraud. Fraudsters know that claiming to act as a legal representative can bypass normal verification.
Don't accept vague claims of representation. Require documentation. And contact the data subject directly if you have any doubts, assuming they're an adult with capacity.
What happens when verification fails
Sometimes you can't verify the requester's identity to your satisfaction. What then?
You can refuse the request. But you must:
- Inform the requester within one month
- Explain why you couldn't verify their identity
- Tell them what additional information would allow verification
- Inform them of their right to complain to the ICO
- Inform them of their right to judicial remedy
Don't simply go silent. Failing to respond is itself a violation of GDPR. You must communicate your decision and your reasoning.
Your refusal letter should be clear and specific. "We cannot verify your identity" isn't enough. Explain what verification you attempted, why it was insufficient, and what would satisfy your requirements.
Give the requester a chance to provide better verification. Maybe they submitted a blurry photo of their ID and a clearer image would work. Perhaps they answered verification questions incorrectly but could try again.
But if someone repeatedly fails verification, or if the verification attempts themselves raise red flags, you can refuse the request outright.
Be prepared to defend your decision. If the requester complains to the ICO, you'll need to demonstrate that:
- You had reasonable doubts about their identity
- Your verification requirements were proportionate
- You gave the requester adequate opportunity to verify themselves
- You communicated clearly about your requirements
The burden is on you to show your refusal was justified. The ICO won't look favorably on organizations that use verification as a blanket excuse to deny requests.
Documentation requirements
Document your verification process. For each request, record:
- When you received the request
- What verification you required
- When you requested it
- What verification the requester provided
- Your assessment of that verification
- Your decision and reasoning
This documentation serves multiple purposes. It proves compliance if regulators investigate. It provides evidence if the requester disputes your decision. And it helps you maintain consistent verification practices.
Your records should show that you applied verification consistently. You can't have strict verification for requests you don't want to fulfill and minimal verification for convenient requests.
Consistency matters. If you verify identity one way for some requesters and differently for others in similar circumstances, that suggests discriminatory treatment or arbitrary decision-making.
Your documentation should demonstrate a risk-based approach. Higher-risk requests got stronger verification. Lower-risk requests got lighter checks. The documentation should show your reasoning.
Keep verification records separate from the personal data you hold about the data subject. Don't permanently add verification documents to their main file unless you have a legitimate reason to retain them long-term.
Once you've completed the verification and fulfilled (or denied) the request, you should delete most verification documents. You don't need to keep copies of someone's passport indefinitely. A record that you verified their identity is sufficient.
Training staff on verification procedures
Front-line staff who receive data subject requests need clear guidance on verification. This isn't something to figure out case by case.
Your organization should have written procedures that specify:
- What types of requests require what levels of verification
- Acceptable verification methods for different scenarios
- How to request verification information from requesters
- What to do when verification fails
- Who to escalate unusual cases to
- How to document verification decisions
Train staff on these procedures. Don't assume they'll understand data protection law or verification requirements intuitively. They won't.
Many verification failures happen because front-line staff don't know what they should be checking. Someone calls claiming to be a customer, knows a few basic details, and the staff member hands over information without proper verification.
Staff need to understand the risks. What happens if they disclose data to the wrong person? There are consequences. For the data subject whose information gets exposed. For the organization that faces regulatory action. And potentially for the staff member whose judgment error caused the breach.
But staff also need to understand they can't make verification impossible. The goal is appropriate verification, not creating barriers that prevent legitimate requesters from exercising their rights.
Give staff clear decision trees. If X, then Y. If the requester is calling from a number on file, do this. If they're emailing from an unknown address, do that. If they claim to be a legal representative, follow these steps.
Empower staff to ask for help. If they're unsure whether verification is adequate, they should have a clear escalation path to someone with more expertise.
Regular refresher training helps too. Data protection law evolves. Verification techniques improve. Staff need updates.
Technology solutions for identity verification
Software can streamline identity verification while maintaining security. Several approaches work well.
Account-based verification leverages existing authentication. If someone logs into their account and makes a request through your authenticated portal, you've already verified their identity through the login process.
This is often the cleanest solution for existing customers. Build data subject request functionality into your customer portal. Let people make requests through authenticated sessions.
Email verification links work for straightforward requests. Send a unique link to the email address on file. The requester clicks it to confirm they control that email. Simple and effective for low-risk requests.
SMS verification codes function similarly. Send a code to the registered phone number. The requester provides the code back. This confirms they control that phone.
Identity verification services use sophisticated document checking, facial recognition, and other techniques to verify identity remotely. These third-party services can handle the verification process and provide you with confirmation.
If you use identity verification services, remember you're still the controller. You're responsible for ensuring the service processes data lawfully and securely. Due diligence is required before engaging these services.
Automated verification workflows can route requests based on risk level. Low-risk requests get minimal verification. High-risk requests trigger stronger checks. Medium-risk requests fall somewhere between.
Automation ensures consistency. The same request from different people gets the same verification requirements. This reduces the risk of discriminatory or arbitrary treatment.
Technology can also help with documentation. Automated systems record verification steps, decisions, and timing. This creates the audit trail you need for compliance.
But don't over-rely on automation. Some requests will need human judgment. Edge cases, unusual circumstances, or requests that raise red flags might need review by someone with expertise in data protection.
Technology should support your verification process, not replace human oversight entirely.
Building compliant verification into your operations
Identity verification for GDPR requests isn't optional. It's a legal requirement that protects both data subjects and organizations.
The key is finding the right balance. Verify sufficiently to prevent unauthorized disclosure. But don't create barriers that prevent legitimate requesters from exercising their rights.
Take a risk-based approach. Match verification requirements to the sensitivity of the data and the circumstances of the request.
Train your staff. Give them clear procedures and the authority to make appropriate verification decisions.
Document your process. Record what verification you required, what you received, and how you decided whether it was adequate.
And use technology where it helps. Automated verification can improve consistency and create better audit trails.
Getting verification right requires clear policies, trained staff, appropriate technology, and good judgment. That's where compliance software comes in.
Platforms like ComplyDog streamline the entire data subject request process, including identity verification. Built-in workflows guide staff through appropriate verification steps based on request type and risk level. Automated documentation creates the audit trails regulators expect. And centralized management ensures consistent verification practices across your organization.
By integrating verification requirements directly into your request handling process, compliance tools help you protect data subjects while meeting your GDPR obligations. Visit complydog.com to see how the right software can transform your approach to data subject requests and identity verification.
