A chat conversation contains personal data, even if nobody provides their name. An IP address, a visitor identifier, and the content of a message in which the customer describes their issue are enough. Pre-chat fields, visit history, and attachments add more. Before launching the widget, you should know exactly what is created, where it goes, and how long it remains there.
This article describes implementation practices and common organizational decisions. It is not legal advice or an analysis of your particular website—confirm the legal bases for processing and the wording of your notices with a lawyer or data protection officer.
What data does chat actually create?
The most common mistake is to think of chat as a single collection of ‘messages.’ In reality, it creates several categories of data with different levels of sensitivity and different justifications. Separating them simplifies every subsequent decision: retention, access, how they are described in your policy, and how you respond to a customer's request.
Scroll the table sideways to see all columns.
| Category | Examples | What to watch for |
|---|---|---|
| Data provided directly | Name, email address, or phone number from pre-chat or an offline form | Every required field must be justified by its purpose, not convenience |
| Conversation content | Messages, attachments, and internal notes | Customers enter data you did not intend to collect |
| Technical data | IP address, device, browser, and visitor identifier | Created automatically, even without a form |
| Visit context | Visited URLs, traffic source, and time on the website | Linking this data to a person is a separate decision, not a side effect |
| Service rating | Post-chat survey and customer comments | A comment may be more descriptive than the form anticipates |
A customer will enter more in the chat than you intended to collect. An order number may be harmless, but a description of a medical condition or a photo of an identity document is not. The team needs to know what to do in that situation before it occurs.
If you enable session recording alongside chat, treat it as a separate category of data and a separate decision. We cover the configuration questions for this feature in our article on session recording and the GDPR.
A separate case arises when a customer pastes a card number or a scan of a document into the conversation window. We explain what to do immediately and afterward in our article on sensitive data in chat.
Who is the controller, and who is the processor?
In a typical arrangement, you, as the website owner, are the data controller: you determine the purposes and means of processing. The chat tool provider processes data on your behalf, acting as a data processor. This division gives rise to specific obligations on both sides.
- Data processing agreementYour relationship with the provider requires a written basis defining the scope, purpose, and duration of processing, as well as the obligations that apply when the relationship ends.
- List of subprocessorsThe provider usually relies on hosting, email, or additional services. You should know who else handles the data.
- Place of processingCheck where the data is physically stored and whether it is transferred outside the European Economic Area.
- Record of processing activitiesChat is another processing activity. If you maintain a record, add it rather than hiding it under a general website entry.
Ask the provider three questions before implementation: where conversations are stored, for how long, and exactly what remains after the relationship ends. The answers should be specific and documented, not merely verbal. In Meetlead, conversation data is isolated by website, message retention is configurable, and disconnecting an integration clearly shows what will be deleted and what will be retained. If conversation content will also be sent to an AI model, ask the same questions about the model provider; our AI customer service and GDPR checklist lists them.
The duty to inform—when and where
Information about processing must be provided when the data is collected, not afterward. For chat, that means a specific place: the conversation window or the pre-chat form. Referring people to a privacy policy in the footer is insufficient if they never look there before sending their first message.
- Who the data controller is and how to contact them.
- Why you process conversation data and the legal basis for doing so.
- How long you retain conversation content and contact details.
- Who may receive the data, including the tool provider.
- What rights the person has and how to exercise them.
- Whether the conversation is used for purposes other than handling the issue.
In practice, a short notice beside the field used to start a conversation, with a link to the full section of the privacy policy, works well. The short notice should be understandable rather than exhaustive—the linked document provides the full details.
Consent is not a universal legal basis for everything. Handling an inquiry usually relies on a different basis from sending marketing offers. Combining both in a single checkbox creates a problem instead of solving one.
Retention and access: two decisions that make a difference
Chat data tends to remain forever because nobody decides when it should be deleted. Retention is the simplest way to reduce risk: the fewer old conversations you keep, the less you need to secure, locate, and disclose upon request.
- Set a retention period for conversation content.It will usually differ from the period for support tickets or sales records. Document the rationale beside the duration.
- Separate contact details from the transcript.A CRM contact may remain useful longer than the record of a conversation from two years ago.
- Limit access within the team.Not every operator needs access to every historical conversation from every website.
- Plan how to handle requests.Check whether you can locate, export, and delete one person's conversations within a reasonable time.
- Describe what happens upon disconnection.The end of your relationship with the provider is the point at which you need to know what disappears and what remains.
- Review it once a year.The scope of the data changes with the product. A setting from two years ago is rarely still appropriate.
Exports deserve separate consideration. A CSV file of conversations sent to a personal inbox escapes every retention setting in the tool. If exports are necessary, they should be controlled and logged rather than created ad hoc.
Data isolated by website, configurable message retention, and a transparent account of what disappears after disconnection. Read Meetlead's privacy policy.
Checklist before launching chat
- List the categories of data created in a conversation, separating pre-chat, conversation content, and technical data.
- Establish a legal basis for handling the inquiry and a separate basis for any marketing.
- Sign a data processing agreement with the tool provider and obtain the list of subprocessors.
- Confirm where the data is stored and whether it is transferred outside the EEA.
- Place a short notice beside the chat window with a link to the privacy policy.
- Add a section about chat to the privacy policy instead of hiding it under a general paragraph.
- Set retention periods for conversations and contact details.
- Limit operator access according to actual need.
- Make sure the team knows what to do when a customer pastes sensitive data into the chat.
- Define a process for handling requests to access and delete data.
If you are still choosing a tool, these points also make a good list of questions for the provider—the answers can be more instructive than the feature list. We cover practical selection and implementation criteria in our guide to live chat on your website, and the technical side of installing it on the most popular platform in our guide to adding chat to a WordPress website.
