Organisations treat message history as an unambiguous asset. It is searchable, it settles arguments about what was agreed, it preserves context for people who join later, and in some industries keeping it is a legal requirement.
All of that is true. What is also true, and much less often stated, is that the same archive is an accumulating liability, and that the two properties grow together. Every message that makes the archive more useful also makes it more damaging to lose.
This is an argument for treating retention as a security decision rather than a storage one. It is an opinion piece in the sense that the conclusion involves a judgement call — but the mechanics underneath it are not in dispute.
Summary
A chat archive's value is concentrated in recent messages and its risk is spread across all of them. Credentials, personal data and commercially sensitive discussion accumulate in it, while the population who can read it grows through joiners, contractors, integrations and exports. Data you no longer hold cannot be breached, subpoenaed, or exported by someone who should not have it — which makes deletion a control, not a loss.
Two curves that diverge
The usefulness of a message decays quickly. A discussion from this morning is doing active work. One from last quarter is occasionally consulted. One from four years ago is, for almost all practical purposes, never read again — the people involved have moved on, the system being discussed has been replaced, and the decision it records has long since been superseded.
The risk does not decay at the same rate. A credential pasted four years ago is still a working credential if nobody rotated it. A customer's personal data from four years ago is still that customer's personal data. A frank assessment of a partner, written when the relationship was different, still reads exactly as it was written.
So the two curves separate. Value falls steeply; risk stays roughly flat, or rises as the volume grows. Everything to the right of where they cross is pure carrying cost.
Most organisations never pick a point on that line. Retention defaults to "forever" because forever is the default setting, and nobody has framed the decision as one worth making.
What is actually in there
Ask what a complete export of your workspace would contain if it were handled carelessly. The answer is usually worse than expected, and it is worth being specific.
Credentials. Despite everyone knowing better. API keys, database passwords, service-account details, WiFi passwords, the shared login for the analytics tool that three people still use. Each one pasted with an apology and a promise to delete it later. Most were never rotated, because rotation is the step people skip — the mechanics of that are in why you should never send passwords over chat.
Personal data. Home addresses for sending equipment, medical details from a conversation about leave, bank details for an expense reimbursement, a photograph of a passport sent to sort out a visa. Almost none of this belongs in a chat system, and almost all of it is in one.
Candidate and employee information. Salary discussions, interview feedback written bluntly, performance conversations between managers. This is a category with regulatory weight attached.
Customer and commercial material. Support conversations containing customer data, contract terms, pricing decisions, and candid assessments of partners and competitors written by people who assumed a small audience.
Security context. Architecture discussions, known weaknesses, which systems are old and unpatched, who holds which access. Individually mundane; collectively, a briefing document for anyone attacking you.
None of this is hypothetical. It is the standard contents of a workspace that has been running for a few years without a retention policy.
The audience grows, and nothing re-evaluates
The second half of the problem is that the set of people who can read the archive is not fixed.
New members see history. Someone joining a channel today can typically read everything in it from before they arrived, including the credential pasted in 2023. Channel membership is granted casually, because it is usually a low-stakes decision — and it is a low-stakes decision only because nobody is thinking about what is in the backlog.
Contractors and temporary access. Granted for a project, rarely revoked cleanly afterwards.
Departed employees. Deprovisioning is inconsistent, and offboarding is the process most likely to be done in a hurry. Access that was not removed is access that persists.
Integrations. Third-party applications installed with broad OAuth scopes, sometimes years ago, by someone who has left. Each one is a channel through which the archive can leave, governed by that vendor's security rather than yours.
Administrators. A workspace administrator can generally read everything, including direct messages, on most enterprise plans. That is a legitimate capability with legitimate uses. It is also a concentration of access that most members do not realise exists.
Exports. This is the sharpest one. A compliance or legal export produces a file containing the entire archive in readable form, and that file is then handled by a person, stored somewhere, and often emailed. Every control the chat platform provides — access levels, channel permissions, audit logging — stops at the boundary of that file.
The reframe: deletion as a control
Security work is mostly about protecting what you hold. There is a cheaper move available, and it is systematically underused: hold less.
Data you no longer have cannot be exfiltrated in a breach. It cannot be produced under a legal demand. It cannot be read by a contractor who joined a channel. It cannot appear in an export. It does not need to be encrypted, access-controlled, monitored or reasoned about at all.
This is the principle behind data minimisation in the GDPR, which requires personal data to be adequate, relevant and limited to what is necessary, and kept in identifiable form no longer than needed. Article 5 states it as a legal obligation for personal data. It is good security practice regardless of whether the regulation applies to you.
The practical version: a ninety-day retention policy on general channels is a security control, and it is one of the few that reduces risk without adding operational burden. It requires no software, no vendor, and no ongoing attention once configured.
The objections, taken seriously
"We need it for compliance." Some of it, yes — and the correct response is to work out precisely which of it, and keep that under a defined policy in a system built for records retention. Financial services firms have genuine obligations to retain communications. Those obligations attach to specific categories, not to every channel in the workspace. "We might need something one day" is not a compliance requirement.
"Institutional memory lives in there." Some does. But a decision preserved only as a scrollback fragment from a conversation nobody can find is not institutional memory in any useful sense — it is a lottery. If a decision matters, it belongs in a document, a ticket, or an architecture record where it can be found deliberately. Relying on chat search for this is a documentation failure that deletion exposes rather than causes.
"People will object." Some will, initially. In practice, the objection is usually about a specific workflow — a channel where the history genuinely is the working record — and the answer is a per-channel exception rather than abandoning the policy. Two weeks after the change, almost nobody notices.
"It looks like we have something to hide." Retention policies are ordinary, documented, applied uniformly and in advance. What looks bad is deleting selectively once a dispute has started, which is a different act with a different name. Set the policy while nothing is happening.
What to actually do
Set a default retention period on general channels. Ninety days is a reasonable starting point for most organisations; some go to thirty. Announce it, explain the reasoning, and give people a fortnight before it takes effect.
Make exceptions explicit and few. Channels with a genuine long-term record requirement get a documented exception with a named owner and a review date.
Audit what is there before you start. Search for password, api_key, token, secret, -----BEGIN and the obvious variants. Rotate everything you find. This should happen before the retention policy takes effect, because otherwise the policy silently deletes the evidence of exposures you have not yet responded to.
Review integrations and membership. Remove applications nobody recognises. Check who is in channels containing sensitive material, and remove people who no longer need to be.
Give people somewhere else to put secrets. A retention policy does not stop credentials being pasted; it only limits how long they sit there. The behaviour changes when the alternative is quicker than the thing it replaces — a password manager vault for anything ongoing, and a one-time encrypted link for a single handover. Encrypted notes vs password managers vs secrets managers sets out which is which.
Treat the export path as the real boundary. Decide who may generate a workspace export, where it may be stored, and when it must be destroyed. This is the control most organisations have never written down, and it is the one that matters most.
What this does not solve
It does not reach copies already made. Someone who took a screenshot, forwarded a message, or holds an old export still has it. Retention reduces future accumulation; it does not retrieve the past.
It does not stop the behaviour. People will still paste credentials. The policy limits the window, and only a better alternative changes the habit.
It is not a substitute for rotation. Deleting a message containing a credential does not invalidate the credential. If anything, an organisation that deletes without rotating has made it harder to know what was exposed.
It does not apply uniformly. Regulated industries have real obligations, and a policy written without checking them is a different kind of risk. Check your own obligations before setting a number, and take advice where they are unclear — nothing here is legal advice, as our disclaimer sets out.
FAQ: chat retention and security
Q1. What is a reasonable default retention period?
Ninety days suits most organisations without regulatory retention duties, and some go to thirty. The number matters less than having chosen one deliberately and applied it uniformly. Channels with a genuine record requirement get documented exceptions rather than an exemption for everything.
Q2. Does deleting messages look suspicious?
Not when it is a documented policy, applied uniformly, and set in advance. What creates a problem is selective deletion after a dispute or investigation has begun, which is a different act entirely. The time to set a retention policy is when nothing is happening.
Q3. Does encryption solve this instead?
No. End-to-end encryption protects messages from the provider and from network attackers. It does nothing about the people who are supposed to be able to read the channel — which is the population that grows over time, and the one this article is about.
Q4. We are required to keep communications. What then?
The obligation almost certainly attaches to specific categories, such as communications with clients about regulated activity, rather than to every channel. Identify those, keep them in a system built for records retention with proper access control, and apply ordinary retention to the rest.
Q5. What should I do before enabling a retention policy?
Search the archive for credentials and rotate everything you find. If you enable retention first, the policy quietly deletes evidence of exposures you have not yet responded to, and you lose the ability to work out what was affected.
Q6. Do direct messages need a separate policy?
They need the same policy, and they are where sensitive material concentrates, because people treat a DM as more private than it is. On most enterprise plans, administrators can read DMs and exports include them.
Where to go next
- Why you should never send passwords over chat — the specific case, and the thirty-second alternative.
- Self-destructing notes vs encrypted email — the same argument applied to mail, where the copies are worse.
- Encrypted notes vs password managers vs secrets managers — where things belong instead.
- What Inkrypt retains, and for how long — our own answer to the question this article asks of everyone else.