Are Customer GDPR Requests Going Unanswered?

When customer GDPR requests go unanswered

An unanswered customer GDPR request is the exercise of a right over personal data that has received no communicated outcome. The person asks to know what data exists about them, to correct it, to restrict it, to receive a copy or to have it deleted, and the case sits in an inbox, a spreadsheet or a conversation. It needs to be identified, assigned and closed with a reasoned response, even if all that is needed is to clarify identity or justify a refusal. What matters is knowing who holds the case, since when, and what is missing in order to respond.

In an SME the request arrives wherever everything else does: a general inbox, a website form, customer service, sometimes a letter. Whoever reads it forwards it or leaves it among the orders. The spreadsheet gets updated from memory. Data sits in the shop, the management system, email and documents. A case with no trace cannot be reconstructed. The same disorder behind the errors that undermine customer data quality also slows down responses on data rights.

What happens when a request sits idle for weeks

If the request sits idle, no one knows who should respond, which archives have been checked or whether the data subject has been told anything.

Weeks do not erase the case, they move it into a blind spot. Whoever read it is absent, the forwarded message has no reply, and everyone assumes someone else is handling it. When the customer writes again, only a partial conversation remains: the arrival date is missing, the list of systems is missing, the text that was sent is missing. What was actually done can no longer be distinguished from what is merely remembered.

An email along the lines of "we have received your message" does not close the case: it only confirms that the inbox works. The data subject is waiting for an outcome, that is, the data, the correction, the reasoned refusal or a clarification on identity. The harm arrives before any legal profile: data sent to the wrong person, a deletion applied to an order still open, two different responses. A professional will assess the delay. The company can at least stop losing cases.

Who finds the request buried among orders

Customer service staff see returns, invoices and data queries arriving together. The query sits in the body of the message, after the lines about the order. If the workflow exists only to process sales, that line never becomes a case. A visible rule is enough to get started: certain words and certain forms are not closed like a support request. They are copied into a single list, with the date and the name of whoever saw them. The commercial conversation can continue. The rights request cannot.

Who has data scattered across the shop and the management system

Those who sell online often keep data about the same person in several places: the shop's customer record, invoices in the management system, a returns spreadsheet, email threads with address changes. An access request cannot be closed on a single screen. Before writing a response, a round of those systems is needed, with a note of what was opened and what was not found. Without that round the response is vague, and a vague response generates another one. Connecting systems that do not communicate is a process problem, not a matter of good intentions at the end of the day.

Why data subject requests get lost

They get lost because they remain mixed in with ordinary mail and no one marks them with an owner, a date and a status.

The shared inbox is the most fragile point. Everyone can read it, no one is required to close the case. Forwarding looks like taking ownership, but without confirmation and without a deadline the original message stays open for everyone else. A spreadsheet opened by several people splits: one copy has the response, the other does not. An internal conversation preserves a decision that never makes it back into the file. After a few weeks no one knows which version is authoritative.

The same fragility appears when documents are searched for only in email. A deletion request may reference an invoice or a contract. If every attachment has to be tracked down by hand, the case stalls. Keeping them traceable, as in managing commercial documents without hunting through emails, shortens the process. It does not replace the judgment on what can be deleted and what must be retained: that stays with whoever knows the case and, where needed, with a professional.

• Shared inbox with no named person taking ownership of the case.
• Internal forwarding mistaken for a response to the data subject.
• Spreadsheet updated from memory, with copies that do not match.
• Identity not verified and case suspended with no follow-up date.
• Response written in an internal conversation and not stored alongside the request.
• Data in the shop, management system, email and documents, with no list of places to check.
• No distinction between a commercial complaint and the exercise of a right.

A request that has been read is not a request that has been handled: until it has an owner, an arrival date and a status, it is still open as far as the company is concerned.

How much time you have to respond, and what not to decide alone

The rule is to inform the data subject without undue delay: the standard deadline, any extension and any refusal are applied to the specific case with a professional, not from memory.

Response times for a data access request do not live in the good memory of an inbox. The European data protection regulation requires informing the data subject without undue delay and, as a general rule, within one month of receipt. If requests are complex or numerous, the deadline can be extended by a further two months, provided the data subject is notified within the first month and the reasons are explained. If no action is taken, this must be communicated, with the reasons and with information about the right to lodge a complaint with the supervisory authority and to seek judicial remedy. In Italy the authority is the Garante per la protezione dei dati personali. The dates and the text of your specific case are for a professional to review: this article is not legal advice.

An extension is not a formula to paste in. It must be justified by genuine complexity: many archives, many requests at once, an unresolved identity query. It must be sent within the first deadline, not when someone notices it has passed. If the arrival date is missing, the starting point for counting is also missing. That is why the register comes before the calendar.

When it is not clear who wrote

Doubt about identity is a reason to ask for clarification, not to ignore the message. Before sending an extract or carrying out a deletion, it must be established whether the person writing is the individual to whom the data relates, or someone acting on their behalf with a verifiable authority. Asking for a piece of information already in your possession, without creating an obstacle, is a precaution. Leaving the email without a follow-up date is not. If the doubt remains, note what was asked and when. Sending data to the wrong person is an incident, not a prompt response.

How to keep a register of data subject requests

A useful register gives every request an arrival date, an owner, a deadline and a status, and stores the text of the response that was sent.

A perfect archive is not needed on day one. What is needed is a single place, visible to whoever responds, where the case does not depend on the memory of an inbox. The register can start as a spreadsheet if the volume is low and one person alone updates it. It becomes fragile as soon as two people open it, or as soon as requests arrive from multiple channels. At that point the status must change in one place only and the deadline must run from the arrival date. The register does not decide on rights. It records the work done.

1. Date and channel of arrival, with the original text stored.
2. Declared identity and verification carried out, or clarification still awaited.
3. Right exercised: access, rectification, erasure, restriction, portability or objection.
4. Name of the person responding within the company, not just the name of the inbox.
5. Deadline, any extension and the date on which the data subject was notified.
6. Systems checked, even when the result is "not found".
7. Text of the response and date of sending.

Who has little time for the daily routine

Someone who ends the day with the inbox still full will not maintain a register if the process is lengthy. The daily minimum is one thing: open the customer channels, note new requests on the single list and do not respond from memory. Searching the systems and drafting a response belong in the block already set aside for administration, not squeezed between one order and the next. If that block does not exist, the case slips. The register makes the slippage visible. It does not prevent it on its own: someone needs to look at the open rows.

Three steps for requests that have already arrived

First: collect into a single list everything that looks like the exercise of a right, even if it is old and even if it is mixed in with a complaint. Second: for each row, note the arrival date that can be reconstructed, whether a response was sent and who can close it today. Third: respond first to the oldest ones and to those involving access or erasure, and write down what can no longer be reconstructed. Do not invent a date that is not there. Do not promise a deletion that a retention obligation may prevent: that boundary is confirmed by a professional.

The register does not replace the response to the data subject: it helps avoid missing the deadline and makes it possible to reconstruct, even afterwards, what was searched for and what was written.

How custom software removes the repetitive round

Leomat builds custom web applications and automations around the real process, with an agent that prepares the work and a person who confirms actions on data.

The round that repeats is always the same: read the inbox, determine whether it is a rights request or a complaint, open the shop, management system, email and documents, draft a response, have it reviewed by whoever responds, send it and store it. A software automation starts from this list, not from a purchased tool in the hope that it fits. Leomat, software engineering studio, designs the application and the environment it lives in: database, interface, infrastructure, security and monitoring. Agents act on data under human supervision. Autonomy grows only where it has been shown to be reliable. Sending an extract or carrying out a deletion still requires confirmation from a person.

The agent can prepare a summary: which channel the request came from, which systems should be checked, which fields in the register are empty. It does not close the case and does not decide whether data can be deleted. That choice remains with a person. Actions remain tracked and readable. A customer's data does not end up in another customer's context. It stays within the agreed perimeter and is processed in accordance with the regulation: what leaves that perimeter and what does not is stated openly. Security is designed from the outset on recognised frameworks, including OWASP, MITRE ATLAS, NIST AI RMF and the European regulation on artificial intelligence.

This is not a module that manages privacy on behalf of the company, and it is not a compliance assurance. It is a system built around the process, after seeing who does what, where it breaks down and what must remain with people. If a step is not worth automating, that is said upfront. Automating the reminder, the gathering of pieces and the storage of the response makes sense. Automating the judgment on the right does not. An automated assistant, also useful for SME customer service, can receive the message: it cannot be the only record of the response.

Frequently asked questions

What to do if a GDPR request has been sitting idle for weeks?

It is not erased and there is no waiting for the customer to write again. The arrival date is reconstructed from email, forms and messages, an owner is assigned and a response is sent with what can be documented. If pieces are missing, that is stated. If the standard deadline has already passed, an extension cannot be written after the fact. The text, especially for erasure or a broad copy of data, should be reviewed by the data protection officer or a lawyer. An updated list prevents the same case from sitting idle again.

What rights can a customer exercise over their data?

They can ask whether data about them exists and what it is, to have it corrected, to have it deleted, to restrict its processing, to receive it in a reusable format and to object to certain uses. In the cases provided for, they can ask not to be subject to a decision based solely on automated processing. Not every request must be granted in full: a retention obligation or the protection of another person can limit erasure and access. Those boundaries are verified on the specific case, with whoever handles privacy or with a professional. Even a partial refusal must be reasoned and stored.

Is a spreadsheet enough as a request register?

It is enough as long as one person alone updates it and the incoming channels are few. It stops being enough when the file circulates in copies or when several people write on the same row. At that point it is no longer clear which version is authoritative and deadlines diverge. A register in a single application, with one status only and the response linked to the case, reduces that risk. The spreadsheet can be the first list, not the definitive record if requests have already slipped through. It should be reviewed as soon as the handling of customer privacy requests changes hands.

Can an agent respond to an access request on its own?

No, not as the closure of a case. It can help recognise the message, recall the systems to check and prepare a draft summary. Sending data, carrying out a deletion and any action that is difficult to reverse require human confirmation. An assistant on the website can collect the text, but it is not the case file: if the conversation does not end up in the register, the request reverts to an isolated message. The agent removes the repetitive work. The person remains responsible for sensitive actions, and autonomy expands only where the behaviour has already been verified.

This post was produced with AI