Most data protection requests never come through the privacy form on your website. They turn up as one more email in the queue, or as a single line in the chat: "I want you to delete everything you have about me." That puts customer service first in line, so customer service decides whether the clock starts on time.
This is a condensed guide for support teams. It isn't legal advice. Check your routines with whoever owns data protection at your company. The guidance referred to comes from the Swedish supervisory authority (IMY), but the rules come from the GDPR itself, so they work the same way across the EU.
Requests that show up in support channels
Any data subject right can arrive in any channel. In everyday support they usually look like this:
| The customer writes | The right involved | What should happen |
|---|---|---|
| "What data do you have about me?" | Right of access | Compile the data and provide it |
| "Delete my account and everything you have" | Right to erasure | Check whether an exception applies, then answer with a decision |
| "You have my address and name wrong" | Right to rectification | Correct it and confirm |
| "Stop sending me your mailings" | Objection to direct marketing | Stop the mailings, always |
| "I want to move my data to another service" | Data portability | Provide it in a machine-readable format where the right applies |
| "Stop using my data until this is sorted" | Restriction of processing | Pause processing during the assessment |
The marketing objection is the most common and the simplest. You always follow it, with no assessment needed. The rest need judgement, so they need a routine.
How to recognise a request
Go by what the message says, not what form it comes in. The customer doesn't have to use a particular form, write "GDPR" or cite an article. A line in the chat, a sentence in an ongoing ticket or a note at the end of a complaint all count, and the deadline runs from when you received it. In practice that means:
- Everyone knows the phrasings. "Delete my data", "what do you have about me", "stop contacting me". Put the list in the team routine.
- Requests get their own ticket type and are handed over the same day, so they can be tracked and counted.
- The agent doesn't judge exceptions alone. Support recognises the request, confirms receipt and passes it to the person who owns the question.
If an annoyed customer ends a complaint with "just delete me then", treat it as a request and ask what they want deleted. Don't explain it away.
Deadlines and cost
You have one month. It can be extended by two months if the request is complicated or many requests have arrived at once. The catch most teams miss is that you have to tell the person about the extension, and why, within the first month. Otherwise you've missed the deadline even if you answer in week six. As a main rule, answering is free of charge.
Identification: only when needed
IMY's guidance is that asking for an identity document is rarely necessary, and can create a security risk of its own. A good rule of thumb is to never ask for stronger identification than you used when the customer relationship started. If all you have is an email address, a request from that address is normally enough. If the customer has an account, a logged-in session is the best check.
Erasure isn't always yes
The right to erasure has exceptions, for example when data is still needed to meet a legal obligation. For an online store, accounting is the classic case. So the honest answer is often "both": the account and the marketing history are removed, while orders and invoices stay as long as the law requires. Write that as a standard reply in plain language and have it reviewed once. If customers also ask how your tools store their data, answer from what you know is true. Supportifier's security and data handling page is an example of the facts worth having at hand before someone asks.
When something has gone wrong
Support is often the first to notice a possible breach: a reply sent to the wrong person, an attachment with someone else's data. A notifiable breach must be reported within 72 hours of the organisation becoming aware of it. So raise the alarm straight away, through a named recipient and a route that also works at evenings and weekends. Whether the breach is notifiable is decided by the person responsible, not in the inbox.
Checklist
- A shared list of phrasings that count as a request
- A dedicated ticket type, tracked against the one-month deadline (for example in a shared inbox with owners, status and SLA targets)
- A named recipient and deputy who take requests over the same day
- Four standard replies: receipt, access, erasure with exceptions, extension notice
- An identification level set per channel
- An alarm route for breaches
- Two numbers to follow: requests per month, and the share answered within a month
Originally published at https://www.supportifier.se/en/blog/gdpr-requests-customer-service
Top comments (0)