A data subject request never arrives looking like a crisis. It’s an email, sometimes a single sentence, often without the words “GDPR” or “access” anywhere in it. Acknowledging it is trivial. Finishing it - finding every copy of the person’s data, deciding what the law actually requires you to hand over or delete, doing it across every system and every processor, and proving you did - is where the month disappears. Most teams are good at the first part and quietly improvising the rest. The regulation grades the rest.
A Request Doesn’t Have to Look Like One
The first failure happens before any data is touched: not recognising the request. The regulation doesn’t require a magic word, a form, or even the term “GDPR.” A customer emailing support to ask “what do you have on me?” has made a valid access request, and the one-month clock starts the day it lands - in whichever inbox it lands in. So the first operational problem isn’t legal, it’s routing: every channel a person can reach you on - support, sales, social, a reply to a marketing email, a phone call someone wrote down - has to funnel into one place where requests are logged and the clock is tracked. Requests that sit unrecognised in a shared inbox for three weeks are the most common way a deadline is quietly blown.
Three Rights That Look Similar and Aren’t
Access, erasure, and portability get bundled together because they all start with the same sentence - the user wants something about their data. Operationally they pull in different directions, and treating them as one workflow is how teams hand over too much, delete too little, or export the wrong thing.
| Right | What you actually owe | Where it commonly goes wrong |
|---|---|---|
| Access (Art 15) | A copy of their data plus the context: purposes, recipients, sources, retention, transfers | Raw data with no context; partial or vague disclosure |
| Erasure (Art 17) | Deletion where a valid ground applies - but it is not absolute | Treating it as automatic; deleting in one system, missing the rest |
| Portability (Art 20) | Data they provided, machine-readable, only under consent or a contract | Confusing it with access; exporting inferred or other-basis data |
Portability is the narrowest of the three: it covers only data the person gave you, processed by automated means under consent or a contract, and exists so they can carry it elsewhere - not a second copy of everything you hold.
Access: Responding Isn’t the Same as Fulfilling
The right of access is more than a data dump. Article 15 entitles the person not just to a copy of their data but to the surrounding picture - why you process it, who you share it with, where it came from, how long you keep it, whether it leaves the region, and whether any of it feeds automated decisions. A response that returns a CSV of raw fields with none of that context is incomplete, even though it feels like you’ve answered. You also have to handle other people’s data caught up in the same records: redact or withhold third-party information rather than disclosing it by accident.
Spotify did respond to access requests - which is exactly why the case is instructive. Following complaints, Sweden’s data protection authority found the information provided was too general and incomplete: it handed users “some” of their data without explaining how to obtain the rest, and fell short on the surrounding context Article 15 requires - purposes, recipients, and international transfers. The authority imposed a fine of SEK 58 million (around €5 million) in June 2023; an administrative court later upheld the violation but reduced the amount to SEK 40 million. The lesson lands for anyone running a request process: the bar isn’t “we sent something back.” It’s whether the person can actually understand what you hold about them and how it’s used. A fast, partial, jargon-filled response can still be a breach.
Deletion: It’s Not Done Until It’s Gone Everywhere
Erasure is the right most people assume is simplest and is actually the hardest to finish - for two reasons. First, it isn’t automatic. You only have to delete where a valid ground applies (the data is no longer needed, consent is withdrawn, the processing was unlawful), and you can lawfully keep data you need for a legal obligation or to defend a claim. A compliant response says what you deleted, what you kept, and why. Second, and more operationally brutal: deletion has to reach every place the data lives - primary database, analytics, backups, the CRM, the email platform, and every processor you’ve shared it with, since Article 19 requires you to tell those recipients to delete too. Removing the row in the main system and forgetting the six downstream copies is the textbook failure, and it’s the one that comes back as a complaint when the person keeps getting your emails.
A traveller asked an airline to delete the email address it had been using to market to him. The company did delete it - and then sent him a newsletter eleven days later, because the address still lived in a system the deletion never reached. The Hungarian authority found the company had failed to act without undue delay and had breached both the right to erasure and the duty to build deletion into its systems by design. It was a single email address and a reprimand rather than a large fine, but the shape of the failure is the one that scales: deletion treated as an event in one database rather than a state that has to hold across every system and processor. Data subject rights sit in the regulation’s higher fine tier - up to €20 million or 4% of global turnover - and erasure is the second most-complained-about right after access, so the stakes climb fast when the pattern repeats at volume.
Portability: The Right Everyone Overclaims
Portability is the most misunderstood of the three, usually treated as “access, but as a download.” It’s narrower. Article 20 covers only the data the person actively provided to you, only where you process it under consent or a contract, and only where it’s handled by automated means - and it has to come out in a structured, commonly used, machine-readable format so they can take it to a competitor. It does not cover data you inferred or derived about them, and it doesn’t apply to processing under other legal bases. Confusing portability with access leads teams to either over-export - handing over derived profiles they never owed - or under-deliver a PDF nobody can import. The fix is to know, per data element, where it came from and on what basis. Which, again, is impossible without the data map underneath.
Looks Handled vs. Actually Handled
Pattern-matching from real request reviews - the gap between a request that looks closed and one that’s actually finished tends to follow the same shape:
| Looks handled | Actually handled |
|---|---|
| ✗ Request noticed whenever someone reads the inbox | ✓ Every channel routes to one logged queue, clock running |
| ✗ Access answered with a raw data export | ✓ Data plus purposes, recipients, sources, retention, transfers |
| ✗ Erasure treated as automatic and absolute | ✓ Grounds assessed; what’s kept and why is explained |
| ✗ Deleted in the main database only | ✓ Propagated to backups, analytics, CRM, and every processor |
| ✗ Portability treated as a second access right | ✓ Only provided data, machine-readable, under consent/contract |
| ✗ Identity “verified” by demanding a passport scan | ✓ Proportionate verification - no excessive ID, no stalling |
| ✗ “We replied” | ✓ A logged, dated, defensible record of what was done |
Build the Workflow Around the Clock and the Map
A request process that holds up has two anchors. The clock: one intake queue, every channel feeding it, a logged received-date, and the one-month deadline tracked from there - with the two-month extension used deliberately and communicated within the first month, not discovered late. The map: a current data inventory, so that “find everything about this person” is a query, not an archaeology project. Identity verification sits in between - confirm who you’re dealing with, because handing data to an impostor is itself a breach, but ask for the minimum needed and never use verification as a delay tactic. Everything else - access, deletion, portability - is the same retrieval problem with a different rule applied at the end.
Final Thought
Data subject requests are where privacy stops being policy and becomes operations. The law is generous to the individual and unforgiving about process: a month to respond, no charge, and a high bar for what “done” means on each right. The organisations that handle them well aren’t the ones with the prettiest banner or the longest policy - they’re the ones who can take any person’s name, find every trace of them in minutes, apply the right rule to each right, do it everywhere at once, and show their work afterward.
The test: when the next request lands, can you say - without a scramble - where this person’s data lives, what each of the three rights actually entitles them to, and how you’ll prove in six months exactly what you did. If that’s a project rather than a process, the next deadline is already at risk.
Frequently Asked Questions
One month from receipt under Article 12(3). You can extend by a further two months for complex or numerous requests, but you must tell the requester about the extension and the reason within the first month.
No, in most cases — requests are free. You can charge a reasonable fee or refuse only where a request is manifestly unfounded or excessive, and the burden of proving that is on you (Article 12(5)).
Access (Article 15), erasure (Article 17), and portability (Article 20). They look similar but differ in scope: access is a copy plus context, erasure applies only where a valid ground exists, and portability covers only data the person provided, in a machine-readable format.
No. There is no magic word, form, or even the term GDPR required. If a user asks for something about their data, the clock starts — failing to recognise the request is the first and most common failure.