A subject access request is a compulsion mechanism aimed at a company's entire store of information about one person. Account history, support tickets, internal notes, location records, purchase history, the recordings of calls the person forgot they made. Fulfilled correctly, it is the single most useful thing a privacy law has ever given an individual. Fulfilled to the wrong individual, it is a data breach the company performed deliberately, on request, with a legal deadline pushing it along.
What the law asks the company to do
Under the GDPR, Article 15 grants the right and Article 12 sets the mechanics. The controller has one month to respond, extendable by two further months for complex requests. The response must be free in ordinary circumstances. Refusing without good grounds risks a complaint to a supervisory authority and the enforcement that can follow.
Article 12(6) is where identity enters. Where the controller has reasonable doubts about the identity of the person making the request, it may ask for additional information necessary to confirm it. Recital 64 tells controllers to use all reasonable measures to verify identity. Article 11 says a controller that genuinely cannot identify the subject is not required to acquire more data just to enable compliance.
Read together, those provisions describe a duty without a method. The law does not specify what verification is adequate, because adequate verification depends on what the company holds and how much collateral damage a mistaken disclosure would cause. That judgement is delegated to whoever is staffing the privacy inbox.
The experiment that made this concrete
At Black Hat USA in 2019, James Pavur and Casey Knerr presented work in which Pavur sent subject access requests impersonating his fiancée, with her consent, to around 150 companies. The requests carried a name, an email address and a phone number, all of which are trivially obtainable, and no proof of identity.
Roughly a quarter of the companies handed over personal data on that basis alone. Among the material returned across the study were home addresses, dates of birth, partial payment card numbers, past travel details, account credentials and answers to security questions. A smaller group asked for identity documents that would have been straightforward to forge. Only a small minority handled the request in a way that would have stopped the attack.
The failure was not that companies ignored the law. It was that they complied with it, quickly, to whoever asked.
Subsequent academic work in Europe reproduced the pattern against different sets of companies. The specific numbers vary by sample. The shape does not.
The bind, stated plainly
A company answering these requests is squeezed from three directions at once, and the squeeze is structural rather than a matter of carelessness.
- Verify too little and you disclose one person's file to another person, which is a breach in its own right and an account takeover starter kit.
- Verify too much and you are now collecting passport scans and selfies from people whose only offence was asking a lawful question. You have expanded your holdings of sensitive identity documents in the name of protecting them, which sits badly against data minimisation and creates a new asset for an attacker to steal.
- Verify slowly and the statutory clock runs out.
The California regulations are more prescriptive than the GDPR here, setting matching thresholds for how many pieces of information must line up and requiring a signed declaration under penalty of perjury for the most sensitive categories. That is a workable answer for a company with structured customer records. It helps less when the requester has no account and the company holds a pile of observational data keyed to an email address, which is exactly the situation with the data broker industry.
If a company can be persuaded that an email address identifies you, then whoever controls that email address is you, as far as the company is concerned. This is the same failure mode as password reset, with a longer deadline, a richer payload and a human reading the request instead of a state machine.
Verification methods, ranked by what they prove
| Method | What it proves | What it costs |
|---|---|---|
| Name plus contact details in the request | Nothing. All of it is public or purchasable. | Nothing, which is why it remains common. |
| Reply-to the address already on file | Control of that mailbox. Useful, and the bar an inbox compromise clears. | Nothing. Should be the floor, never the ceiling. |
| Fulfil through the authenticated account | Possession of the credential and any second factor. Strongest available for account holders. | Engineering work, and it excludes requesters who never had an account. |
| Knowledge-based questions | Familiarity with the person, which an ex-partner, relative or stalker has in abundance. | Cheap, and worst against the adversary who most often files these requests. |
| Identity document upload | Possession of a document, or of a decent forgery. | You are now storing passport scans. Delete them on completion, and say so. |
The other abuse: volume
The access right also gets used as pressure. Coordinated campaigns file thousands of requests against a single organisation to consume its staff time. Litigants use requests to obtain material they could not get through discovery. Employees in disputes file them to force disclosure of internal correspondence about themselves.
Article 12(5) permits a controller to charge a reasonable fee or refuse where a request is manifestly unfounded or excessive, and regulators have accepted that in narrow circumstances. It is a deliberately high bar, because the alternative is a regime where inconvenient requests get labelled excessive. The tension has no clean resolution, and the current settlement leans toward the requester, which is probably correct.
Practical positions
If you operate a service, the defensible design is to fulfil access requests inside the authenticated session wherever an account exists. Send the export to the address on file, never to a new address supplied in the request. Require a step-up authentication before generating it. For requesters with no account, disclose only what can be tied to the identifier they proved control of, and say clearly what you are withholding and why. Log every fulfilment, including who approved it, because that record is what turns a mistaken disclosure into an incident you can investigate.
If you are the subject, the useful instinct is to welcome friction. A company that pushes back on your request with a real verification step is a company that will push back when someone else files one in your name. The pattern also argues for per-service email aliases: an attacker who knows your name and your main address cannot guess the identifier that a given company knows you by, and an access request filed under the wrong identifier returns nothing.
Rights of access are worth having, and the case for them does not depend on pretending this problem away. A right that compels disclosure is only as good as the check on who is asking, and for the first years of the GDPR that check was frequently a stranger's word.