Delete their record in your own system, keep only what you need on a do-not-contact list, and answer them within one month. Meta’s copy of the messages ages out on its own 30-day schedule, and the chat on the customer’s phone is theirs — you cannot reach it and you are not asked to.
The hard part is not the deleting. It is knowing how many copies exist, which ones you are the controller of, and what you are allowed to hold back so you do not message the person again next Tuesday.
Where the data actually sits
A WhatsApp conversation with a customer leaves traces in more places than most records of processing admit. Five, typically:
| Copy | Who controls it | What happens on a deletion request |
|---|---|---|
| Your platform’s database — contact, consent trail, message history | you | you delete it; this is the request |
| Meta’s Cloud API infrastructure | Meta as processor; as controller for safety and integrity | ages out on Meta’s own schedule, no action from you |
| The customer’s phone | the customer | out of scope, and out of reach |
| Downstream systems fed from WhatsApp (CRM, sheets, ad platforms) | you | you notify per Article 19 and delete per Article 17 |
| Your do-not-contact list | you | usually the one thing that stays |
Only rows one, four and five are yours to act on. Much deletion-request panic is really about the two copies nobody can do anything about.
What Meta holds, and for how long
Meta’s own documentation for the WhatsApp Business Platform is specific: messages “have a maximum retention period of 30 days in order to provide the base features and functionality of the Cloud API service” — retransmission, for example — and user identifiers are deleted “within 30 days of the last status update (sent, delivered, read) of a message, unless otherwise directed”. Messages at rest are encrypted. That is from Meta’s Data Privacy & Security page for the platform, re-checked 1 November 2026.
So there is no “delete my customer from Meta” button to press, and no need for one. The WhatsApp Business Data Processing Terms (last updated 22 August 2025) commit WhatsApp to assisting you with data subject requests “insofar as this is possible” — which, given a 30-day rolling window, mostly means the copy takes care of itself.
Since Meta’s terms restructuring of 23 September 2026 those terms bind only users of the Business app; for the platform, the equivalent assistance duty sits in the Meta Global Processor Terms, incorporated into the Cloud API Terms (last updated 23 September 2026). Those terms also let Meta use the data as a controller in its own right for the safety, security and integrity of the service (section 2.7), so not every copy Meta holds is one it keeps on your behalf. The 30 days cover the running service: when you stop using the Cloud API, the same terms commit Meta to delete remaining personal data within 90 days or return it on request, and the WhatsApp Terms for WhatsApp Business Platform say account data is kept for up to 90 days after termination, with copies possibly persisting in backups for a limited time.
If you use the WhatsApp Business app instead, there is one more copy: the chat backup in Google Drive or iCloud, which you have to delete yourself.
Your database is different. It keeps the conversation for as long as you keep it. That is the copy the request is about, and the one an authority would ask you about.
What you must delete, and what you may keep
The right to erasure applies in defined circumstances, not on demand. Article 17(1) GDPR lists them, and two cover almost every WhatsApp marketing case: the person withdrew consent and no other lawful basis applies, or the data is no longer necessary for the purpose it was collected for. Both are usually true the moment someone says “stop and delete me”.
Now the part people get wrong in the other direction. Erasing everything is not always the compliant answer, because Article 21(3) obliges you to stop marketing to someone who objects — and you cannot check a new import against a list of people you no longer have. The UK’s ICO addresses this head-on in its direct marketing guidance: “you should put their details onto a suppression or ‘do not contact’ list, instead of deleting them”, and if someone asks for deletion, “you are likely to need to delete that information (unless you need to keep a small amount for another reason, such as on a suppression list)”. Its worked example is a customer who objects and asks for deletion; the company deletes everything except the suppression entry, and the ICO’s verdict is that the company complied.
That is UK guidance, not an EU authority, so treat it as the prevailing interpretation rather than settled EU law; for your own case, that judgement belongs to a lawyer.
Practically, the balance looks like this:
- Delete: name, custom fields, tags, message history, notes, anything you inferred about them.
- Keep, minimally: the phone number on a do-not-contact list, stored separately from your marketing data, used for nothing but blocking.
- Keep, if you can justify it: records a law makes you keep — invoices under tax law, per Article 17(3)(b) — and records needed for the establishment or defence of legal claims, per 17(3)(e). “We might want the history someday” is neither.
Then tell the person plainly what you deleted, what you kept and why. A deletion confirmation that quietly omits the suppression entry is the thing that turns a closed request into a complaint.
The messages, specifically
One trap worth checking in your own stack: deleting a contact and deleting their messages are often two different operations. Plenty of systems detach the message rows rather than erase them, leaving the conversation — often with a name or number inside the stored payload — in the database after you have reported the deletion as done.
Before you answer your first request, delete a test contact and then go look at the message table. Whatever you find there is what you will have to describe if someone asks.
And remember the copy nobody looks at: your backups. In the EDPB’s coordinated 2025 review of the right to erasure, adopted 10 February 2026, half of the responding authorities flagged deletion in backups as a gap. Know your backup rotation, and say in your answer when the last copy ages out.
The clock, and the people downstream
Article 12(3) GDPR gives you one month from receipt to tell the person what you did. You can extend by two further months where the request is complex or you have received many — but the extension itself has to be communicated inside the first month, with reasons. Silence is the failure mode that gets escalated.
The month runs from when the request arrives, not from when it reaches the right desk. The EDPB’s Guidelines 01/2022, written for access requests under the same Article 12, start the clock when a request reaches one of your official channels — “it is not necessary that the controller is in fact aware of the request”. A request sent as a WhatsApp reply at 23:40 on a Friday counts from that moment. If your inbox is shared, someone has to be responsible for spotting it, because “no one saw it” is not an extension.
Nor can you send the person to a different channel. The same guidelines say they are “not required to use these specific channels and may instead send the request to an official contact point of the controller”. Italy’s Garante applied that against BBVA in a decision of 3 September 2026, rejecting the bank’s argument that a customer should have used the email address in its privacy policy; in the EDPB’s summary, controllers “cannot disregard a valid request merely because it was not submitted through a preferred channel.” That case was a marketing objection, not erasure, but the duty comes from Article 12, which covers both.
And then there is Article 19: you must communicate the erasure “to each recipient to whom the personal data have been disclosed, unless this proves impossible or involves disproportionate effort”. For a WhatsApp setup, the recipients are rarely exotic — the CRM you sync to, the email tool, the spreadsheet an agency exported last quarter. Write that list down once, while nothing is on fire.
What this means for you
A workable process fits on one page:
- Log it. Date received, channel, exact wording. The wording matters, because “unsubscribe” and “delete everything you have on me” are different requests.
- Identify. Match the phone number to the contact record. Do not demand ID documents by reflex — you may ask for confirmation only where you have reasonable doubt about identity, and for someone messaging from the number you hold, you usually do not.
- Delete. Contact, custom fields, tags, notes, message history. Then check the message table actually emptied.
- Suppress. Move the number to your do-not-contact list, and nothing else with it.
- Notify downstream. Every system you fed from WhatsApp, per Article 19.
- Answer. Within the month: what was deleted, what was kept, why, and how to complain to a supervisory authority if they disagree.
In Nybero, steps three and four are separate actions on the contact record: an opt-out marks the contact as opted out and writes a dated consent-trail entry, while a delete removes the contact together with that trail and its tag links. Message rows are detached rather than erased, so the message text, any name used as a template parameter, answers submitted through WhatsApp forms and the photos, voice notes and files the customer sent all stay, even though the contact record with the phone number is gone — and there is currently no self-serve way to purge them, in the app or through the API, so if the request covers the conversation history, ask support to clear them and say so in your answer to the person. That is the trap from the previous section, in our own product. And the order matters: a delete takes the consent trail with it, so if you need proof of the opt-out, record it before you delete, not after.
Nothing here is legal advice, and the suppression-list balance in particular is an interpretation, not a rule with a citation. If you have never run the drill, take one test contact through all six steps today and see where your stack disagrees with your privacy notice.
Updated 1 October 2026 for Meta’s terms restructuring of 23 September 2026 and the post-termination deletion periods; sources re-checked 1 October 2026.
Updated 1 November 2026: added Meta’s own controller role for safety and integrity, the EDPB position and the Garante’s BBVA decision on requests sent through an unexpected channel, and the media and form answers that stay in Nybero after a contact is deleted; sources re-checked 1 November 2026.
