Setting Retention Periods for Chat Logs

The question about retention periods for chat logs is usually put the wrong way round. It is not: how long may we keep the conversations? It is: what do we still need them for? The Regulation names no figure for chat transcripts, and that is not an oversight but the system behind it. Anyone who picks a period by feel has merely postponed the work, because in a dispute the controller has to justify the figure, not the supervisory authority to disprove it. This article shows how a defensible period comes about: from the purpose, from the point where necessity ends, and from a justification that fits into the record of processing activities. Added to that are the difference between erasure and anonymisation, the special role of quality assurance, and the question of when a chat really does fall under commercial retention duties.

Enlarge graphic

Labels in the illustration

• Reason for keeping the data
• Duration from the trigger event
• Live conversation
• session and resumption
• days
• Open case
• until closed, plus follow-up
• weeks
• Quality sample
• separate purpose, own period
• months
• Defence of legal claims
• limitation period, Section 195 BGB
• 3 years
• Commercial letter in chat
• Section 257(4) HGB
• 6 years
• Anonymous metrics
• no personal reference left
• no period
• End of chat
• 30 days
• 90 days
• 6 months
• 3 years
• 6 years

Retention periods for chat logs

Why the law contains no fixed number

The principle of storage limitation requires that personal data be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed (Art. 5(1)(e) GDPR). The period is therefore not a property of the data but a consequence of the purpose. If the purpose changes, the period changes. If the purpose falls away, the permission falls away. The controller is responsible for compliance with this principle and must be able to demonstrate it (Art. 5(2) GDPR). Demonstrating here means writing down why exactly this duration is necessary.

Two further provisions turn the principle into a documented duty. At the time the data are obtained, the data subject must be told the period for which the personal data will be stored or, if that is not possible, the criteria used to determine that period (Art. 13(2)(a) GDPR). And the record of processing activities contains, where possible, the envisaged time limits for erasure of the different categories of data (Art. 30(1)(f) GDPR). Both places allow a criterion instead of a figure where the duration cannot be determined in advance. A criterion is, for example: until the case is closed plus a defined follow-up window. What is not a criterion: as required.

What a chat log actually contains

Before a period can be determined, it must be clear what is being discussed. A chat log is rarely a single file of messages. In practice several stores hang off one conversation, technically separate and therefore requiring separate erasure. Anyone who only looks at the message table leaves half of it behind. The following list helps you write down the full inventory once.

• The message transcript itself, with timestamps and the attribution to visitor and assistant
• The session identifier and whatever the window stores on the end device
• Technical connection data such as IP address, browser details and the page path the message was sent from
• Contact details handed over during the conversation, often held additionally as a record in the enquiry or ticket system
• Tool calls made by the assistant and their results, for instance an order number looked up or an account balance
• Attachments and uploaded images, which frequently live in a separate storage system
• Ratings, thumbs and free-text feedback on individual answers
• Analysis stores into which the transcript was copied for metrics and troubleshooting

More is personal data than one might assume at first glance. Covered is any information relating to an identified or identifiable natural person (Art. 4(1) GDPR). A conversation without a name can be linked to a person via the order number, the customer number or simply via the situation described. On top of that comes the free-text problem: visitors write things into a chat window that nobody asked for, including details about health or membership. Such details belong to the special categories whose processing is in principle prohibited under Art. 9(1) GDPR. For deletion planning this means: free text is the field with the highest risk and deserves the shortest period. How to handle uploaded content properly is described in the article on image uploads in chat.

Separate the purposes, then build stages

Personal data must be collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes (Art. 5(1)(b) GDPR). The staging follows from this purpose limitation. Running the conversation is a different purpose from handling a case, and both are different again from reviewing answer quality. Each of these purposes has its own end, and that end is usually an event rather than a date. The practical effect of this staging is considerable: the vast majority of conversations end at the first or second stage, with a question about delivery times or a product comparison, and nobody needs them after a few weeks. Only the small remainder that contains a case, a quote or a complaint moves up a stage at all. Anyone who implements this separation in the technology, rather than merely asserting it in a document, has solved the larger part of the deletion question. The table below shows the stages that have proven themselves in projects.

Anonymising is not the same as erasing

Many operators do not want to lose their conversations, because they contain what customers actually ask. There is a clean route for that, and it is not called keeping but anonymising. Recital 26 of the Regulation makes clear that the principles of data protection do not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person, or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable. Anyone who genuinely removes the personal reference leaves the scope of the Regulation and may keep the result.

The catch is in the word genuinely. Pseudonymisation is processing in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information (Art. 4(5) GDPR). But that additional information still exists, otherwise it would not be pseudonymisation. A transcript in which the name has been replaced by a number while the mapping table sits next to it remains personal data and continues under the original period. The same goes for free text from which only the email address was removed while the history described in it remains in place.

• Free text is not merely masked but discarded or reduced to a category
• No key and no mapping table are left behind that could restore the link
• The remaining attributes are not so rare that in combination they point back to a person
• Connection data such as IP address and device identifier go with it, not in a second step later
• The procedure is documented, repeatable and runs as a program rather than by hand
• The result is spot-checked before the raw store is deleted

Logs kept for quality assurance

An assistant does not improve because it runs, but because someone reads its answers. That reading is a purpose of its own and needs a basis of its own. Legitimate interests may apply, provided that the interests or fundamental rights of the data subject do not override them (Art. 6(1)(f) GDPR); where the transcript is further processed for a purpose other than the one it was collected for, the link between the purposes, the context of collection, the nature of the data and the existence of appropriate safeguards must be taken into account, among other factors (Art. 6(4) GDPR). In practice the volume then decides: a sample, drawn under a fixed rule and deleted once evaluated, is something entirely different from a permanent second copy of every transcript. It also makes sense to separate the review result from the material reviewed. What follows from the read-through is a note about a missing answer in the knowledge base, not the transcript itself, as the article on evaluating chats shows in detail.

• A fixed sampling rule instead of reviewing the entire store
• A separate, short period for the review store, independent of the operational period
• A named group of people with access, logged and reviewed at regular intervals
• Separation of operational and analysis stores, so that an erasure reaches both
• The derived output as the result: a gap in the knowledge base, not a copy of the conversation
• A short written balancing test, produced before the first read-through rather than after it

What commercial law requires and what it does not

At this point the objection regularly comes up that chat transcripts are business letters and must therefore be kept for six years. It is worth looking at the provision itself. Every merchant is obliged, among other things, to keep in an orderly manner the commercial letters received and copies of the commercial letters sent (Section 257(1) nos. 2 and 3 HGB). What matters is the following subsection, which defines the term narrowly.

That settles the question, though differently from what the worry suggests. Information about opening hours does not concern a commercial transaction. A product comparison without an enquiry does not either. A conversation in which a concrete quote is given, an order is taken or a complaint is settled, however, certainly does. Such documents must be kept for six years (Section 257(4) HGB), starting at the end of the calendar year in which the commercial letter was received or sent (Section 257(5) HGB). Tax law imposes a parallel duty for commercial and business letters received and sent (Section 147(1) nos. 2 and 3 AO) with the same duration of six years (Section 147(3) AO).

• The assistant issues a concrete quote with quantity, specification and delivery time
• An order is taken during the conversation or confirmed there
• A complaint or a reversal is negotiated and settled in the chat
• A credit note, discount or goodwill gesture is promised in the conversation and later posted to the books
• The transcript is the only place where an agreement reached is documented

Even in those cases the duty attaches to the transaction, not to the window. What must be kept is the part concerning the commercial transaction: the quote, the confirmation, the settlement. The practical route is therefore extraction: the relevant part moves as a document into the specialist or document system that is responsible for business records anyway, and the chat store then returns to its short period. Anyone who instead leaves the whole transcript in place for six years so that one case is covered is processing all the rest without a basis. A retention duty is not a right to retain everything sitting next to it: Art. 17(3)(b) GDPR only carries as far as a legal obligation actually exists.

Alongside retention stands limitation, and it is the second reason why a transcript may stay longer. The standard limitation period is three years (Section 195 BGB) and begins at the end of the year in which the claim arose and the creditor gained knowledge of the circumstances giving rise to it (Section 199(1) BGB). The right to erasure does not apply where processing is necessary for the establishment, exercise or defence of legal claims (Art. 17(3)(e) GDPR). Why this becomes practical precisely with an assistant is shown by the article on liability for statements made by the assistant: if a promise is in dispute, the transcript is the only record of what was actually said.

The deletion plan: classes, events, evidence

A deletion plan is not an essay but a table with a few columns. It lists every data type, names its purpose, the trigger event, the standard period and the place where deletion happens. The value lies not in its length but in the fact that every row can be answered. If a row has no purpose, the data type does not belong in the store. If a row has no trigger event, it will never be deleted. If a row has no implementation point, the period is a statement of intent.

• Name every store belonging to a conversation, from the window to the analysis copy
• Enter purpose and legal basis per store, in one sentence and without umbrella terms
• Define the trigger event as something a program can detect
• Derive the standard period and justify it in two sentences, so the justification exists in advance
• Name the exceptions and settle who sets them, where they are recorded and when they end
• Automate the deletion run and keep its log, without the deleted content
• Include backups and processors, together with the question of how a restore catches up with the deletion state
• Read the whole thing once a year against reality to see whether the periods still fit the actual workflow

Two places are almost always forgotten. The first is the backup. A backup can usually not be altered selectively without losing its verifiability; the customary route is therefore that backups expire under their own short period and that a restore catches up with the deletions made in the meantime. That procedure needs to be written down, otherwise deleted conversations come back after an incident. The second place is the processor: at the controller's choice, it deletes or returns all personal data after the end of the provision of services and deletes existing copies (Art. 28(3)(g) GDPR). Anyone who reads their contracts with this in mind often finds a period there that nobody has reconciled with their own. Where the data sits in the first place is described under privacy and hosting.

Erasure requests in day-to-day operation

Beside routine deletion stands the individual case. The data subject has the right to obtain erasure without undue delay, among other reasons where the data are no longer necessary for the purposes for which they were collected (Art. 17(1)(a) GDPR). A response to such a request must be provided without undue delay and in any event within one month of receipt; that period may be extended by two further months where necessary, taking into account the complexity and number of requests (Art. 12(3) GDPR). Where the data have been disclosed, every recipient must be informed of the erasure unless this proves impossible or involves disproportionate effort (Art. 19 GDPR).

In practice the difficulty is rarely the deleting and frequently the finding. A conversation without a login carries no name, and the person who held it knows neither the session identifier nor a case number. The Regulation takes account of this: where the controller is not in a position to identify the data subject, it is not obliged to maintain, acquire or process additional information in order to identify the data subject for the sole purpose of complying with the Regulation (Art. 11(1) GDPR). That is not an invitation to take it easy but a pointer to the right order of things: store little and you have little to search. For conversations behind a login the opposite applies, as the article on the internal assistant describes.

• A search path that finds a conversation via the address or case number mentioned in the transcript
• An identity check that does not demand more data than the attribution requires
• Restriction of processing as an interim step while the check is running (Art. 18 GDPR)
• A deletion path that reaches every store, including attachments and the analysis copy
• A reply to the data subject stating what was deleted and what remains for which reason
• A note about the request itself that works without the deleted content

The path to a defensible period

The order decides the effort. Start with the figure and you will spend the rest of the time arguing about feelings. Start with the inventory and the figure is in your hand at the end without having been searched for. The following steps can be worked through in a few days and produce a document that survives an audit.

• Take inventory: which stores exist and which fields sit in them
• Determine the purpose per store and check whether it still genuinely exists
• Name, for each purpose, the event at which necessity ends
• Derive the standard period from it and write the justification next to it in two sentences
• Check which fields can already be removed before the period ends
• Decide what lives on in anonymised form and describe the anonymisation procedure
• Settle the exceptions: limitation, commercial letter, open complaint, each with an end date
• Carry the periods into the notices under Art. 13 GDPR and into the record under Art. 30 GDPR
• Set up the deletion run, exercise it once in full and record the result

What stands at the end is not a longer document but a smaller store. Most conversations disappear after weeks because after weeks nobody needs them. What remains, remains for a reason that has been written down, and it remains for as long as that reason holds. This eases not only the compliance burden but also day-to-day operation: a small store is faster to search, cheaper to back up and worth less to an attacker in the event of a breach. Which building blocks an assistant should bring along for this is described under features; how the interplay with existing systems can be organised is set out under integration. Where the periods for conversations, enquiries and logs are set separately in the account is described in the documentation.

Frequent questions