The cost of getting it wrong
Data subject requests are where GDPR compliance meets reality. You can have the best privacy policy in the world, but if you mishandle a request from a real person, that is when complaints are filed and fines are issued.
Supervisory authorities across Europe consistently enforce data subject rights. For SMEs, the fines are not the millions you read about in headlines, but they are painful enough: EUR 5,000 here, EUR 15,000 there, plus legal costs and reputational damage.
Here are six mistakes that keep coming back in enforcement decisions, and how to avoid each one.
Mistake 1: Ignoring requests entirely
What happened: A German company received an access request by email. They did not respond at all. The requester complained to the state data protection authority. The company was fined EUR 10,000.
This is not an isolated case. The Spanish AEPD regularly issues fines for unanswered requests, often in the range of EUR 2,000 to EUR 10,000. The pattern is always the same: someone asks for their data, the company does nothing, the person complains.
What they should have done: Respond to every request, even if you believe it is unfounded. If you cannot comply, explain why in writing.
Lesson: No response is always the wrong response.
Mistake 2: Missing the 30-day deadline
What happened: A Belgian company received an erasure request. They acknowledged it, started working on it, but only completed the deletion after 47 days. The Belgian GBA found that the late response violated the GDPR, regardless of the fact that the deletion was eventually carried out.
The deadline trap is common: companies receive a request, start identity verification, and only then begin the actual work. By the time they respond, the month has passed.
What they should have done: Register the request on day one and start the clock immediately. Set a reminder at two weeks and at three weeks. If the request is complex, inform the requester of a two-month extension within the first month.
Lesson: The clock starts when the request arrives, not when you start working on it.
Mistake 3: Charging fees when not allowed
What happened: A dental practice charged a patient EUR 25 for providing a copy of their medical records in response to an access request. The patient complained. The supervisory authority ruled that the first access request must be provided free of charge, and the practice was ordered to refund the fee and received a warning.
Under the GDPR, the first request is free. You may only charge a “reasonable fee” for requests that are “manifestly unfounded or excessive” - for example, if the same person submits the same access request every week. In practice, this threshold is almost never met.
What they should have done: Provide the data free of charge. Only consider charging if the request is clearly repetitive and excessive, and document your reasoning.
Lesson: Almost never charge. When in doubt, it is free.
Mistake 4: Demanding excessive identification
What happened: A company asked a customer to provide a full, unredacted passport copy before processing their access request. The customer had an account and was emailing from the registered email address. The Dutch AP criticised the company for disproportionate identification requirements, noting that the customer could have been verified through their existing account.
Excessive identification is a double problem: it violates the principle of data minimisation (you are collecting more data than needed) and it creates a barrier that discourages people from exercising their rights.
What they should have done: Verify identity through the existing account. If the customer is emailing from their registered email, that is usually sufficient. Only request ID documents for unknown persons, and always allow redaction of unnecessary fields.
Lesson: Proportionate verification only. Use what you already have.
Mistake 5: Providing incomplete responses
What happened: An Austrian company responded to an access request by providing data from their CRM system. However, they failed to include email correspondence, paper files, and data held by a third-party processor on their behalf. The Austrian DSB found the response incomplete and issued a fine.
This mistake is often not intentional. Companies search their main database and forget about emails, cloud storage, paper archives, backup systems, and data held by processors.
What they should have done: Search all systems where personal data may be stored. Create a checklist:
- CRM and customer databases
- Email systems (search by name and email address)
- Accounting and invoicing software
- HR systems (for employee requests)
- Cloud storage (Google Drive, Dropbox, OneDrive)
- Paper files and archives
- Data held by processors (hosting providers, email marketing tools, analytics)
- Backup systems
Lesson: Search everywhere. An incomplete response is nearly as bad as no response.
Mistake 6: Deleting data you should have retained
What happened: A company received an erasure request and, in a panic, deleted everything - including invoices they were legally required to retain for seven years, correspondence related to an ongoing dispute, and records needed for tax purposes. When the tax authority later asked for those records, they could not produce them.
The right to erasure is not absolute. You must assess each category of data before deleting:
| Data type | Delete? |
|---|---|
| Marketing preferences, newsletter subscriptions | Yes, delete |
| CRM notes with no legal basis | Yes, delete |
| Invoices within retention period | No, legal obligation to retain |
| Data related to ongoing disputes or claims | No, legitimate interest to retain |
| Employment records within mandatory retention | No, legal obligation to retain |
| Contract data within statutory retention period | No, legal obligation to retain |
What they should have done: Assess each dataset individually. Delete what should be deleted, retain what you are legally required to keep, and explain to the requester exactly what was deleted and what was retained (and why).
Lesson: Do not panic-delete. Assess first, then act.
How to get it right
Every one of these mistakes is preventable with a clear process. If you have not set one up yet, start with our step-by-step guide to building a data subject request process. It covers everything from designating a contact point to documenting your response.
The pattern across all six mistakes is the same: they happen when there is no process, no register, and no templates. Fix those three things and you fix the problem.
GDPRWise scans your current setup and identifies gaps in your data subject request process before they become complaints.