A subject access request rarely arrives as a formal letter citing Article 15 of the GDPR. More often it is one line in an order conversation: "please send me a copy of everything you hold about me." If an agent treats it as a routine question and closes the thread, the deadline can pass before anyone responsible hears of it.
Roles, transparency and retention for chat data are covered in our article on live chat and the GDPR. This is not legal advice; the final reply comes from whoever handles data protection in your business. We describe the EU GDPR; outside the EU, for example in the UK, your own national law and the regulator's guidance apply.
How to spot a request in an ordinary conversation
A request needs no particular form or label. It is enough that the person wants to know what data you process about them, or asks for a copy. In chat it usually sounds like: "what do you have on me in your system," "please send me all my conversations," "I want to see what data you collected."
EDPB Guidelines 01/2022 on the right of access say the GDPR sets no formal requirements for the requester and the controller does not assess their intentions. They do not decide who in your business should answer. EDPB Guidelines 01/2022.
Separate a request from a question about a single detail: asking where a parcel went is a routine order matter. When in doubt, flag the conversation as a possible request and ask, rather than letting it slip. Per the EDPB, a general request in principle covers all of the person's data; where there is a lot, the business may ask them to narrow it.
First reply: confirm receipt, do not send data
A frontline agent should not paste chat history or profile data straight away. The job is to confirm receipt, explain the next step and leave a record the next shift will not lose. The EDPB calls it good practice to confirm receipt in writing, stating when the one-month period starts and ends.
"Thank you, we have received your request for the personal data we process about you and a copy of it. Date received: 7 October. The person responsible for data protection will reply by 7 November at the latest. If we need to confirm that we are speaking with the account holder, we will write to the email address linked to the account."
Log the request somewhere with an owner and a history. A ticket with a number, an assignee and an internal note recording the date received, the exact wording and the channel lets anyone check where the case stands. The note itself should not repeat the data the request is about.
Deadline: one month from receipt, not from handover
Article 12(3) GDPR requires information on action taken on a request without undue delay and at the latest within one month of receipt. The period can be extended by two further months where necessary, given the complexity and number of requests, but you must explain the extension and its reasons within the first month. The first copy of the data is free of charge.
Articles 12 and 15 GDPR in the official text published on EUR-Lex. The provision itself does not explain how to count days on a calendar; worked examples are given in the EDPB guidelines. Regulation (EU) 2016/679 on EUR-Lex.
The EDPB explains that the period starts when the request reaches the business through an official channel, even if nobody has read it yet. In its example, a request received on 5 March must be answered by 5 April. Your website's support chat is usually such a channel, so the customer's message starts the clock, not the handover.
Identity checks in proportion to the risk
Chat history sent to the wrong person is a breach, not a fulfilled access right. Article 12(6) GDPR lets you request additional information where you have reasonable doubts about identity. That does not mean demanding an ID scan by default: the EDPB calls this disproportionate where the person is already authenticated, for example signed in.
Confirm the person through a channel already linked to their data: a reply from the account or order email address, a sign-in, or a phone number known from earlier contact. We describe levels of verification in our guide to verifying customer identity before sharing order details. Note in the ticket how and when the person was confirmed. Per the EDPB, resolving identity doubts can pause the clock, so log the day you asked for confirmation too.
A map of support data sources
The request covers data across the business, but support knows best what its own channels produce. The reply reflects the situation when the request arrived; data already deleted under your retention rules cannot be provided. The table shows a sample breakdown for a fictitious bike accessories shop.
Scroll the table sideways to see all columns.
| Source | What it may contain | What to watch for |
|---|---|---|
| Conversation and ticket history | Messages, attachments, status changes | Other people's data in the same thread |
| Internal notes | Team findings about the customer | Do not exclude them upfront; the responsible person decides |
| Contact profile | Name, email, phone, company, attributes | The same customer across several channels |
| Session recordings and visit journey | Pages visited, events, recorded visits | Visits linked to the contact after identification |
| Callback requests | Name, phone number, topic, time slot | Retention may differ from conversations |
Session recordings are easy to forget. If linked to the contact, include them; collecting and masking them is covered in session recording and the GDPR. Article 15(4) GDPR states that the right to a copy must not adversely affect the rights and freedoms of others. Before releasing chat history, check it for third-party data, such as details about a colleague of the customer. If special category data came up in a conversation, see our guide to sensitive data in chat.
Handover and reply: the order of work
Support gathers the material, but the designated person decides on the reply, any extension and any limits on the copy. This sequence suits a small team without a legal department.
- Intake.The agent confirms receipt, quotes the request in a note and records the date and channel.
- Assignment.The ticket gets one responsible owner and an internal due date shorter than a month.
- Verification.The owner confirms identity through a known channel and records how it was confirmed.
- Data collection.The team checks every source on the map and also records the ones where nothing was found.
- Reply.The copy and the Article 15(1) information reach the customer through a secure channel, and the ticket closes with the date sent.
Besides the copy, the reply gives the Article 15(1) information: purposes, data categories, recipients, retention period, the person's rights and the data source if not collected from them. Your privacy notice can help, but the EDPB says it must be tailored to the individual.
How to organise this in Meetlead
In Meetlead you log the request as a ticket with a number, an assignee and internal notes, and the event timeline shows who changed what and when. The contact profile leads to the visit journey with links to recordings, conversations, callbacks and tickets, a map of places to check within one website. The CSV export of the customer list holds profile data, not full conversation and recording history. A person still assembles the complete copy source by source.
Retention for messages and recordings is configurable. While a request is open, check that its data will not be deleted before the reply goes out; the EDPB expects handling to account for short retention periods. The case workflow itself is explained in our guide to a ticketing system for customer support.
Questions about Article 15 requests in support
Do I have to respond if the customer never wrote "GDPR" or "Article 15"? Yes, if the message shows they want to know what data you process about them or want a copy. The EDPB stresses there are no formal requirements. If it is unclear, ask about the scope and log that question in the ticket.
Can I charge a fee or refuse? The first copy is free. The GDPR allows a reasonable fee for further copies and, for manifestly unfounded or excessive requests, especially repetitive ones, refusal. The business must prove that, and the EDPB stresses there is very little room to call a request manifestly unfounded.
