A Customer Asks What You Hold. The Clock Has Started

It arrives as a message on Instagram. A customer from eighteen months ago wants to know what you hold about them and asks you to delete it. There is no legal language, no formal letter, and no indication that this is a process with a deadline attached. It is, and the clock started when you read it.

For a business of one or three people this is one of the few compliance obligations that genuinely lands on the owner's desk with a timer on it. The good news is that the rules are readable and the deadline is generous. The difficulty is entirely about where your customer data actually sits, and that question got harder in the last two years for reasons that have nothing to do with data protection law.

What counts as a valid request?

Almost anything that makes clear a person wants their own personal information. The formality people expect is not required, and assuming otherwise is the most common way a small business misses a deadline it did not know had started.

The regulator's guide to subject access is explicit on this. A person can make a request verbally or in writing, including via social media. A request is valid when it is clear that the person is asking for their own personal information, and it does not need specific terminology or any reference to the legislation. The right itself gives them a copy of their personal information plus supplementary information about how you use it.

Two practical consequences follow immediately. Someone on your team who is not you can receive a valid request, which means a message to a shared inbox or a shop social account is a request received by the business. And a request phrased as a complaint still counts: "what have you got on me and why are you emailing me" is a subject access request wearing ordinary clothes.

How long do you actually have?

One month, and up to two further months where the request is genuinely complex. The dates matter more than the duration, because the extension is not something you can decide about in week six.

The guidance sets the deadline at one month from receipt, and it allows that month to run instead from the day you receive whatever you legitimately needed first, such as proof of identity or authorisation from a third party. The extension of up to two further months is available where the request is complex or where you have received a number of requests from the same person, and it requires you to notify the individual and explain why inside the initial month.

The clarification rule is the one worth memorising, because it is the only lever you have. When you ask for clarification, the one month limit pauses on the day you request it and resumes the day after you receive it. It pauses rather than resets, so a late clarification question buys you very little. Asking on day two is worth something. Asking on day twenty five is worth almost nothing.

Fees are mostly not available. In most cases you cannot charge to comply, and reasonable fees apply only where a request is manifestly excessive or where additional copies are asked for. So the cost of a request is your labour, and your labour is decided by how well you know where things are.

Where does the data actually live in a small business?

In more places than the owner remembers, and the list has grown. Answering this question in advance is the whole job. Doing it during a live request is what turns a one hour task into a lost week.

Start with the obvious and keep going. Your shop or order system. Your payment provider. Your email platform. Your accounting software. Your shipping labels and carrier accounts. Your support inbox, which for most small sellers is a personal mailbox with fifteen years of history in it. Your phone, if customers message you there. Your reviews platform. Your social direct messages.

Then the layer that is new. Every assistant you pasted a customer message into. Every meeting transcription tool that recorded a call. Every tool with a browser extension that read a page while you were logged in. Every automation that copied an order into a spreadsheet. These hold personal data in places that do not look like databases, and the question of what a vendor retains after you close a chat is not answerable from your side of the screen, which is why what AI vendors actually keep is worth establishing before a request arrives rather than after.

The fourth and fifth rows are the ones that changed. A business that has been using assistants for customer correspondence for two years has created a category of personal data holding that its own privacy notice probably does not describe, and that its own staff cannot search.

What is an assistant genuinely useful for here?

Three things, and none of them is deciding what to disclose. Finding the material, drafting the covering response, and spotting other people's data in what you are about to send.

Finding is the strongest use. Given a customer's email and name, a model can generate the search terms you should be running across each system, including the variants your records might contain: the maiden name, the second email, the misspelling on the shipping label, the company name they ordered under. People search for one string. Requests are answered by finding all of them.

Drafting the covering letter is second and saves real time. The response needs to say what you are enclosing, explain the purposes you use the data for, name the retention periods and set out the other rights the person has. That is a template with facts slotted in, and once you have written it once it applies to every future request.

Third party redaction is the third and the most valuable check. A support thread frequently contains somebody else's personal data, and you are not permitted to disclose that in response to this person's request. Asking a model to flag every other name, address and phone number in a bundle before you send it is a genuinely good use of pattern matching, because the model finds candidates and you make the decision. The distinction is the same one that governs what you may paste into an AI tool in the first place.

What you should not do is let a tool decide the scope of the disclosure or write the assessment of whether an exemption applies. Those are judgements with legal consequences, and a confident paragraph is not the same as an analysis.

Does deletion actually mean deletion?

Not always, and the exceptions are real rather than convenient. Erasure is a right with conditions on both sides, and a small business that promises total deletion often cannot deliver it and should not have promised.

Article 17 sets out the right to erasure and the grounds that trigger it, including that the data are no longer necessary for the purpose collected, that consent has been withdrawn where consent was the basis, that the person objects with no overriding legitimate grounds, or that the processing was unlawful. It then sets out where the right does not apply, and the exception list includes compliance with a legal obligation and the establishment, exercise or defence of legal claims.

That second exception is the one that applies most often in a shop. You have tax and accounting obligations that require you to keep transaction records for years, and a request to erase everything does not override them. The correct answer to a customer asking for deletion is frequently a partial one: the marketing profile goes, the support history goes, the invoice stays, and you explain which is which and why. A flat yes is wrong and a flat no is wrong.

What happens to data that went into a model?

This is the part with no clean answer, and it deserves stating plainly rather than being glossed. If personal data was used to train a model, deleting the source record does not remove its influence from the model, and there is currently no reliable way to prove that it has been removed.

The research field addressing this is machine unlearning, and it is an active problem rather than a solved one. A 2026 survey of unlearning in language models describes the goal as selective removal of knowledge from trained models without complete retraining, and lists the open challenges directly: formal guarantees, robustness against adversarial relearning, scalable efficiency, and unlearning across languages and modalities. Robustness against adversarial relearning is the phrase to sit with, because it means information believed removed can sometimes be recovered.

For a small seller the practical implication is narrow and clear. Do not put identifiable customer data into any tool where training on your inputs is enabled, because that is the one deletion you cannot later perform. Use the account settings that turn training off, use order numbers instead of names, and keep the free consumer tier away from anything containing a real address. This is the concrete reason the advice about what to paste is not merely cautious.

It also affects what you can honestly tell a customer. A response saying their data has been deleted from your systems is accurate. A response saying it has been removed from every system it ever touched is a claim you cannot support if any of those systems trained on it, and the gap between those two sentences is exactly the kind of overstatement that turns a closed request into an open complaint.

How do you answer one in an afternoon?

By having done the mapping earlier. The response itself is mechanical once you know where to look, and the sequence is the same every time.

Record the date you received it, in whatever form it arrived, because that date is the only fact you cannot reconstruct later. Confirm who the person is if you have genuine doubt, asking for the minimum needed rather than a passport scan. If the request is genuinely unclear about what they want, ask for clarification on day one or two and note that the clock is paused.

Then work your system list in order, pulling everything associated with the identifiers you generated. Review the bundle for other people's data and redact it. Assemble the response with the covering explanation of purposes and retention. Send it by a route you can evidence, and keep a copy of exactly what you sent with the date.

That final record matters more than it looks. The most common second round in this process is a person saying the response was incomplete, and the only way to answer that is to show what you provided and what you searched. A file per request, holding the original message, your searches, the bundle and the date, converts a dispute into a document.

Which requests should worry you?

The ones that arrive alongside a dispute. A subject access request from a happy customer is administration. One from a customer in the middle of a refund argument, a former contractor, or someone who has threatened a claim is a different instrument, and it is usually being used to obtain your internal correspondence about them.

The response is not to refuse, because the right applies regardless of motive. It is to be more careful about two things. First, the boundary of personal data: their name appearing in your internal message is not automatically their personal data in full context, and the surrounding business discussion may not be disclosable. Second, the presence of other people, since internal threads about a dispute usually involve several. Both of those are judgement calls where the cost of getting it wrong is real, and a business facing one should consider paid advice rather than a generated assessment.

The related scenario is a request that follows a breach at one of your vendors, which arrives with a different tone and a different urgency. That sequence has its own obligations and timings, set out in what you have to do when an AI vendor has a breach, and the two processes frequently run at the same time.

The work worth doing this week

Write the list of systems. That is the single highest value hour available here, and it produces something useful even if you never receive a request, because the same list is what you need for a privacy notice, for a vendor review and for deciding what to stop using.

Then fix the two things the list will reveal. There is almost certainly an export somewhere that should not exist, and there is almost certainly a tool holding customer text that nobody has thought about since the week it was adopted. Neither is dramatic. Both are the difference between a request you answer in an afternoon and one you answer badly over a fortnight.

Finally, decide the policy on identifiers before the next busy season rather than during it. A business that uses order numbers instead of names when it asks an assistant for help has removed most of this problem at the source, and the habit costs nothing once it is a habit. If you are choosing the systems that hold this data in the first place, the ability to export one customer's full record on demand is a feature worth checking for, which is part of why how a platform holds the data inside your project belongs in the evaluation next to the feature list.