Customer data deletion requests for small teams

The scariest email a small business can receive is short: "Under GDPR/CCPA I'm requesting that you delete all personal data you hold about me." Nothing is broken, nobody is angry — and yet most small teams freeze, because nobody knows whether deleting is required, allowed, or even possible across the nine systems that hold the customer's name. The deadline pressure is real (typically one month under GDPR, 45 days under CCPA), the penalty for a sloppy response is real, and — the part nobody advertises — fake deletion requests are also a social-engineering play.

This checklist turns the panic into a sequence: acknowledge, verify, inventory, delete what's deletable, keep what the law makes you keep, tell the processors, and close in writing. It costs one afternoon to prepare and about two hours per real request after that.

1. First 48 hours: acknowledge, then verify — in that order

Two moves, and the order matters:

• Acknowledge receipt within days, not weeks. One paragraph: "We've received your request and will respond in full by [date within 30 days]." No admissions, no data listings, no promises beyond the deadline. This is also your defense exhibit that the clock was handled professionally.
• Verify the requester is the data subject before touching anything. Ask for confirmation of identity via a channel you already have on file — reply to the email they wrote from, or confirm a detail only the real customer knows (last order number, not a full data dump). A deletion request arriving from a fresh address about "their" account is a known account-takeover play: the attacker wants you to list what data exists, or to lock a real customer out of their account.
• Log the request the day it arrives. Received date, channel, requester, verification status, response due date, outcome. Regulators ask for the log, not for good intentions — and if you get three requests a year, a spreadsheet is your compliance program.
• Never confirm or deny what data exists until identity is verified. "We can't discuss account details until you verify X" is both the safe answer and the polite one.

The verification step costs one email. Skipping it is how a routine compliance request becomes the first hour of a data breach.

2. Build the inventory: where the data actually lives

The request says "all personal data." Reality is a map of copies. Before deleting anything, list where the person exists:

• The obvious systems. CRM or spreadsheet, email inbox and sent folders, support ticket tool, accounting records.
• The quiet ones. Mailing list provider, analytics, chat tools (Slack threads mentioning the customer), calendar invites, shared drives, phone contact lists.
• Other people's servers. Payment processor, shipping provider, cloud backups, and every SaaS tool the customer's data flowed into. This is the processor relay in section 4.
• Free-text searches are your friend. Search by email address across every tool you own — it finds the ticket from 2023 that the CRM export missed. Search the support inbox, then the archive.

If you can't produce this inventory in under an hour, that's the finding: the SaaS sprawl audit (one hour, one owner per tool) is the fix, and it's cheaper to do before the request than during it.

3. Delete what's deletable — and know what you must keep

Here's the part that surprises people: the right to erasure is not a right to erase your accounting records. Split the inventory into two piles:

• Delete outright: marketing profile data, behavioral analytics tied to the person, notes, chat threads, mailing list subscription, non-transactional support history.
• Keep, and say so: invoices and tax records (retention periods are set by tax law — commonly 5–7 years), fraud and chargeback records, records of consent (you need these to prove you had permission), and records of the deletion request itself. Retention rules for operational data belong in your log retention policy.
• Restrict instead of delete where required. For kept records, remove the data from marketing use, suppress the email address from all sends, and mark the record "erasure requested, retained for tax purposes until [date]." The request is satisfied by the combination, not by pretending the invoice doesn't exist.
• Delete everywhere, not just in the UI. The CRM "delete" button often leaves the record in exports, integrations, and caches. The standard is: if you know a copy exists and it's reasonably accessible, it goes too.

4. The processor relay: your vendors hold most of the data

A small team's honest inventory says the quiet part out loud: you don't hold most of the data — your SaaS vendors do. The deletion isn't done until it's done there:

• Send the deletion request to each processor. Mailing list tool, support desk, payment processor, analytics. Most have a self-serve deletion or a documented DSAR channel — use it, and save the confirmation.
• Check each vendor's role. Some act on your behalf (you instruct, they execute); a few are independent controllers for parts of the data (a payment processor keeps transaction records for financial law — that's their obligation, not your failure).
• Track the relay. One row per vendor: requested date, confirmed date, exceptions claimed. The vendor page of the vendor security review should already have a data-contact column — this is where it earns its keep.
• Don't forget backups. See section 5 — this is where "deleted" gets its fine print.

5. What "deleted" means when you have backups

Nobody can surgically remove a person from last Tuesday's backup, and no regulator expects them to. What's expected is a defensible answer:

• The standard position: data is deleted from live systems immediately; backup copies age out on the normal schedule (that's your backup retention window), and if a backup is ever restored, the deletion request is re-applied to the restored data.
• Write the rule down. One sentence in your response: "Personal data has been deleted from our active systems; backup copies are deleted on our standard 35-day rotation, and any restoration re-applies your request." That sentence is the difference between a compliance answer and an excuse.
• Suppress before expiry. Keep the email address on a suppression list so a restored backup doesn't resurrect the person into a marketing send — that's the failure mode that turns a handled request into a complaint.

6. Close in writing: the confirmation that ends the clock

The request is complete when the requester knows it is. The closing letter is short:

• What was deleted — named categories ("marketing profile, mailing list subscription, support history, analytics records"), not system dumps.
• What was kept and why — "invoice records retained for [7] years as required by tax law; a record of this request kept to prove compliance." Specific exceptions pre-empt the follow-up email.
• The backup sentence from section 5.
• The processor note — "requests forwarded to [list], confirmations attached/available."
• The date and a contact — so the next question has somewhere to go instead of a regulator.
• Keep a copy of the letter with the log entry. Response letter + log row + vendor confirmations = your entire evidence file for this request, forever.

7. Make it a procedure, not an improvisation

One request handled well is luck; three handled well is a process. After the first real request, spend thirty minutes making it repeatable:

• One page, named owner. Who receives the request, the 48-hour acknowledge step, the inventory template, the deletion/keep split, the closing letter. Store it with your other runbooks so it survives the person who wrote it.
• Pre-build the two templates — acknowledgment and closing letter — so the writing is deletion-and-fill, not composition under a clock.
• Run the inventory drill annually. The annual security review already inventories systems and access; add one line: "can we find one person's data everywhere in under an hour?" If not, the sprawl audit is due.
• Prevention beats response. Every field you don't collect is a field you never have to delete. The "we'll need it someday" column is where deletion requests go to become week-long projects.