A customer writes "delete my data" — and you have one month to reply. During that time you need to check every system where you store their information: CRM, calendar, SMS gateway, email, accounting and backups. If you don't do this, you risk a complaint to UODO and a fine. But you don't always have to delete — sometimes the law allows you to refuse, and sometimes it actually requires you to keep the data.
On this page you'll find a detailed guide: when you must delete, when you can refuse, how much time you have, and how to go through all your systems step by step. At the end — a ready-to-use procedure you can implement right away.
When you must delete (Article 17 GDPR)
Article 17 GDPR, the right to be forgotten, imposes an obligation to delete data in specific situations. You must do it when the data is no longer needed for the purpose for which it was collected — for example, the client ended their collaboration and you have no reason to keep it. Under Article 17 GDPR, you must delete data when consent is withdrawn and there is no other legal basis for processing.
The second case is consent withdrawal. If the client withdrew consent for marketing data processing and you have no other legal basis (such as legitimate interest), you must delete that data. The third situation is objection to direct marketing — then you remove the data from the marketing list, even if you have another basis.
The fourth case is unlawful processing — if the data was collected or processed illegally. The fifth concerns situations where the law requires deletion — for example, a child's data from information society services. Finally, the sixth case is data that must be deleted as part of fulfilling a legal obligation.
Remember: the right to erasure is not absolute. UODO explicitly states that the controller may refuse if the data is necessary for fulfilling a legal obligation or for establishing, asserting or defending claims. More details are on the UODO website Right to erasure in practice.
When you can refuse
The right to erasure doesn't mean you must delete everything. You can refuse in several precisely defined situations. First, when the data is needed to fulfill a legal obligation — for example, invoices must be kept for 10 years under the Accounting Act.
Second, when the data is necessary for establishing, asserting or defending claims. If the client owes you money, you can keep their data until the matter is resolved. Third, when processing is necessary for a task in the public interest or for archival purposes.
| Situation | Basis for refusal | Example for service business |
|---|---|---|
| Invoices and accounting | Accounting Act | B2B invoices kept for 10 years |
| Medical records | Patient Rights Act | Patient card — 20 years from last entry |
| Legal claims | Art. 17(3)(e) GDPR | Unpaid invoice, court case |
| Legal basis for processing | Art. 17(3) GDPR | Another consent or contract still valid |
If in doubt — whether a particular message is marketing, what legal basis applies — a lawyer or DPO will assess. Don't make decisions yourself on matters that may have legal consequences.
Deadline: how much time you have to reply
UODO clearly sets the deadline: you must reply promptly, no later than one month after receiving the request. The date of receipt is the moment from which you count — which is why properly registering the request is so important.
If the case is complex — for example, you have a lot of information about this person, data is spread across many systems, or you need to consult a lawyer — you can extend the time by another two months. But you must inform the client before the first month expires and explain the reason for the delay.
A request received on May 5 means you have until June 5. If you need an extension, send information by May 5 that the case is complex and you need an additional two months.
Scenario:
- 01request
- →02registration
- →03search
- →04decision
- →05reply
- →06completed
Receiving the request: channels and registration
A data deletion request can come to you through many channels. Most often it's email — the client writes to the company address or the address from the privacy policy. They can also call and file a request by phone, send a contact form on the website, write through a messenger (Messenger, WhatsApp) or even bring a letter in person.
Key is determining when you received the request. From this date you count the month for the response. That's why every request must be immediately registered in CRM with the exact date and time. If the request came by traditional mail, the date received is the day the letter hit your inbox — not the sending date.
The request card in CRM should include: name and surname of the person filing, email or phone for verification, date and time of receiving the request, channel of receipt, description of the request (quote or summary), status (in progress / awaiting decision / reply sent), responsible person, response deadline, result (data deleted / refused / partially deleted), reply date.
Where data is stored besides CRM
CRM is not the only place where you keep customer data. In a typical service business, data is scattered across many systems, and you need to check each one before responding to the request.
Booking calendar — if you use Booksy, Calendly or another system, you must remove entries concerning that client. SMS gateway — you send reminders? Remove the phone number from the marketing list and from the sending history. Email — messages from and to the client, also in employee inboxes. Telephony and call recordings — if you record calls (and have consent), you must delete the recordings or at least the identifying data.
Employee spreadsheets — if employees keep their own notes about clients in spreadsheets, that data is also subject to the request. Backups — here's the tricky part: backups aren't usually deleted on an ongoing basis, but you should know they exist. If you restore the system from a backup, the data will return — so you need a procedure for what to do in such a situation. Processors — if you use external services (SMS gateway, mailing, accounting), you must also check them and possibly send a deletion request.
| Place | Who deletes | How to verify |
|---|---|---|
| CRM | You or responsible person | Search by client ID, delete or anonymize |
| Booking calendar | You (system access) | Check visit history and future bookings |
| SMS gateway | You (provider panel) | Contact list, sending history |
| Employees with access | Search address in all inboxes | |
| Call recordings | Provider or you | Search by phone number |
| Employee spreadsheets | Employees (instruction) | Search shared drive |
| Backup | IT administrator | Protocol — restoration requires re-deletion |
| External providers | Provider (request) | Deletion confirmation in writing |
What about invoices and KSeF
Invoices are a separate category. If you issue electronic invoices, they go to the KSeF system where they are archived for 10 years — regardless of the client's wishes. KSeF stores them automatically, so even if you delete the invoice from your CRM, it stays in KSeF. You cannot delete it before 10 years pass. More information on the KSeF website.
What about medical records
If you run a medical facility, the Patient Rights Act applies to you. Medical records must be kept for 20 years from the end of the calendar year in which the last entry was made. This is not optional — it's a legal obligation.
Partial deletion: what you can and cannot do
Deletion is often not black and white. You can delete marketing data but keep invoices. You can anonymize order history instead of deleting — this is partial deletion and is perfectly allowed.
Typical scenario: the client wants you to stop sending newsletter and marketing SMS. You remove them from the mailing list and SMS gateway. But you keep data from invoices, because the law requires keeping invoices for 10 years. And you keep basic contact data, because they may have an unpaid invoice and you need a way to contact them.
Another scenario: the client demands full deletion, but you do accounting and must keep invoices. In this situation you can refuse deletion in the part concerning accounting documents — but you must clearly explain this in your response. Anonymizing order history (instead of complete deletion) is a solution that requires DPO consultation — don't make such a decision alone.
Replying to the client: what it should contain
A reply to a data deletion request is a formal document, but it doesn't have to be complicated. It should contain several key elements.
First, confirmation of receiving the request and thank you for the submission. Second, information about the decision made — whether data was deleted, whether refused (and on what basis), or whether only part was deleted. Third, a detailed list of what was deleted — CRM, SMS, email, calendar — so the client sees you actually acted.
Fourth, explanation of what was kept and why — for example, "invoices are kept for 10 years under the Accounting Act". Fifth, instructions on where to file a complaint — if the client disagrees with your decision, they can file a complaint with UODO. This is a mandatory element of the reply. Finally, your contact details or DPO contact — so the client knows who to turn to with questions.
Send the reply by the same channel the request came through, or by a more secure method (email with delivery confirmation). Keep a copy of the reply in CRM as an attachment to the case.
Procedure "do it yourself": step by step
If you want to implement a data deletion request handling procedure in your company, start with a simple test: file a request on yourself. Ask a colleague or DPO to send a request to your company to delete "your" data — and go through the entire path from receipt to reply. Measure how long it took and where you encountered difficulties.
Step one is System Map. Create a list of all places where you keep customer data: CRM, calendar, SMS, email, accounting, backups, employee spreadsheets, external providers. For each system, specify: who has access, how to search for the client, how to delete data.
Step two is Request Template in CRM. Create a case template with fields: date received, channel, client data, reply deadline, status. Add automatic reminder 7 days before deadline.
Step three is Identity Verification. Establish a procedure: how do you confirm that the person filing the request is actually your client? This can be an email to the registered address, SMS to the number in the database, or a phone call.
Step four is Request Registry. Keep a registry of all received requests — who filed it, when, what result, reply date. This is your documentation that can protect you in case of a UODO audit.
Step five is Reply Templates. Prepare reply templates for typical situations: complete deletion, partial deletion, refusal with reason. Insert specific data and systems.
How it looks in the system
When handling a data deletion request in the system, the entire process is organized and automated. The client sends a request — by email, form or messenger. The system automatically creates a task with a deadline (default 30 days) and assigns it to the responsible person.
The task contains a list of all modules where the system sees this client's data. You see CRM (client profile, history, notes), SMS gateway (sent messages), calendar (bookings), integrations (all connections to other systems). The system shows where the data is and helps delete or anonymize it.
For each item, the system marks whether it can be deleted or if there's a legal exception (invoices, medical records). The decision about exceptions — whether to keep data based on law — belongs to the company and requires DPO consultation in questionable cases.
After deleting data, the system generates a reply to the client with a list of what was deleted and what was kept with the reason. Everything is saved in the registry — you have proof that you acted in accordance with GDPR.
What remains for humans: client identity verification, decision on legal exceptions (whether you really must keep invoices, whether you can anonymize), signing the reply before sending, consulting a lawyer or DPO in matters causing doubt. The rest — searching, deleting, generating reply — works in the system.
See how deletion request handling works in practice:
- CRM and automations — one funnel for requests from every channel
- Customer Data — one card instead of five lists in five systems
- Tasks — deadline, person, status and reminder
- Integrations — connecting systems so data is in one place
- Admin panels — dedicated panel for running your company
Read more on this topic:
Verifying the identity of the requester
UODO indicates that the controller has an obligation to verify whether the person filing the request is who they claim to be. You cannot simply delete data based on a message from an unknown address — this is risky and could cause you problems.
In practice, verification works like this: you ask the client to confirm their identity in a way you have in your system. If the client is in your CRM, you can send a verification link to their registered email address or call the phone number you have in your database. If it's a new person, ask for a copy of an identity document — but remember that the document itself becomes personal data that you must process in accordance with GDPR.
If you have doubts — whether it's really that client, whether the message is not fake — consult with the DPO. It's better to spend an extra day verifying than to delete the wrong person's data.
Frequently asked questions
Do I have to respond to a deletion request that came through Facebook Messenger?
Yes, every channel is a formal communication channel. If you received a request through Messenger, WhatsApp, a form on the site, or by phone — you must register it and respond. A phone request is best confirmed in writing (by email), so you have proof of exactly what the client demanded.
Can I refuse to delete data if the client has an unpaid invoice?
You can keep data necessary for pursuing claims — but only what is needed for that purpose. The mere information about an unpaid invoice (amount, date, number) doesn't require full client data. In doubtful cases, consult a lawyer or DPO.
What if the request concerns data I've already deleted?
Reply honestly: "the data was deleted earlier, due to the end of collaboration" — and show when that happened (if you have such a record). This is a perfectly correct reply. UODO requires action, not a specific data state.
Do I have to delete data from backups?
Backups are a tricky topic. In practice, you don't delete them on an ongoing basis — but if you restore the system from a backup, remember the data will return. That's why the procedure should include re-deletion after restoration. Ideally, encrypt backups and have a secure restoration procedure.
How much does handling one deletion request cost?
Preparing the procedure is a one-time cost. Handling one request with a smooth procedure takes about 30–60 minutes (verification, searching, deleting, reply). Without a procedure — it can take several hours of searching blindly. That's why a system map and procedure is an investment that pays off with the first request.