Guide · Choosing

Messaging app with an audit trail.

Plenty of messaging products describe themselves as secure. Rather fewer can hand you a record of who said what, when, and what happened to it afterwards. Those are different properties, and organisations that need the second often buy the first by mistake. This is a plain summary of what an audit trail means in messaging, why some apps cannot offer one however good their security, and the questions worth asking before you sign.

What an audit trail actually is

Secure messaging and auditable messaging are not the same purchase, and the words are used interchangeably by people selling both. An audit trail is not a copy of the messages. It is the evidence that the copy is complete and has not been altered. In a messaging context that means five things, and a product that offers the first without the rest is offering a chat log.

Attribution. Each message tied to a verified identity, not a display name someone chose
Timing. A timestamp applied by the service rather than by the sender's device, because a device clock is whatever its owner sets it to
Completeness. Every message captured, including those later deleted by the sender, and captured at the point of sending rather than collected from handsets afterwards
Immutability. An append-only record, so an entry cannot be quietly edited. Where a message is amended or withdrawn, the trail shows that it happened and what it said before
Custody. Audit logs of who has looked at it, exported it or deleted it, and under whose authority. Role-based access is what makes that answerable: if everyone is an administrator, the log tells you nothing

The fifth is the one most often missing and the one a lawyer asks about first. A record nobody can show the handling of is a record whose integrity rests on assertion.

It is worth being precise about the difference between an audit trail and an export. An export is a file produced on request by a participant. An audit trail is maintained continuously by the service, independently of the participants, and is the reason anyone believes the export.

Why an organisation needs one

Three quite different pressures bring organisations to this question, and they want different things from the answer.

Regulatory. Regulated sectors have to be able to produce a record of decisions and of what people were told. In care that is Regulation 17 and the duty of candour; in education it is safeguarding and the statutory guidance; in financial services it is far more prescriptive. The common feature is that the obligation attaches to the conversation, not to the system it happened in.

Legal and disclosure. Employment tribunals, subject access requests and litigation all reach messages. In each case the other side generally has their own copy, which is the asymmetry worth understanding: the organisation without a record is not neutral in that exchange, it is silent.

Operational. Handovers, escalations and approvals happen in chat. If the only record of an approval is in a group nobody controls, then the organisation cannot answer basic questions about its own decisions once the people involved have moved on.

Notice that none of these is about reading people's messages. The requirement is retrospective and specific: produce this conversation, from this date, when asked. Products designed around continuous oversight solve a different problem and generally cost more trust than they are worth.

Why consumer messaging apps cannot provide one

Most organisations arrive here because staff are already using WhatsApp for work and someone has asked whether the messages could be produced if needed. The honest answer is no, and the reason is architectural rather than a missing feature.

Consumer messengers are built around end-to-end encryption, which means the provider cannot read the contents. That is excellent for privacy and it is precisely why the provider cannot produce a record for you: there is nothing on their side to produce. The keys live on the handsets, so the messages live on the handsets.

What follows from that is not fixable with policy. Export is user-initiated, which means it depends on the goodwill of the person who may be the subject of the complaint. It is partial, capturing a chat rather than a chat's whole history in a usable form. It carries no independent timestamps or custody information. Messages deleted before the export simply are not in it. And an employer has no admin visibility over a group created by an employee on a personal account, including no way to remove someone who has left.

This is worth saying carefully because it is not a criticism of the app. A consumer messenger is doing exactly what it was designed to do. The mistake is expecting an evidential property from a product built to prevent one.

Encryption and auditability, and the trade-off nobody states

The two properties pull against each other, and any supplier who tells you otherwise is worth a second question.

End-to-end means only the endpoints can read the message. Encryption in transit and at rest, which is what most business systems use, means the message is protected on the wire and on disk but the service can process it. Only the second is compatible with a server-side record, because a service that cannot read a message cannot file it.

The right question is therefore not is it encrypted but who can read this, under what control, and how would I know. A defensible answer names the parties, explains what the service does with the content, and describes the controls on access. An answer that just says end-to-end encrypted, from a product that also promises compliance archiving, has not been thought through.

There is a related question about transparency to the people using it. If messages are being kept, everyone in the conversation should be told plainly and at the outset. That is both the decent position and the one that survives contact with a works council, a union or a data protection officer. Compliance built on people not realising is not compliance, it is a delay.

Questions to ask a supplier

Ask these in a demo rather than reading a feature grid, and ask for the answer to be shown rather than described. A secure messaging app that cannot answer them is not necessarily a bad product; it is a product solving a different problem.

Is the message captured on the server at the point of sending, or collected from devices afterwards? Device collection fails the moment a phone is lost, wiped or withheld
If a user deletes a message, what does the record show? Nothing is the wrong answer; a deletion, by that person, at that time is the right one
Can an administrator alter the record, and would that be visible? Ask who has that permission and how it is logged
Who is the message attributed to, and how was that identity verified?
Where does the record physically live, in whose tenant, and under whose retention rules? See below
What does an export look like? Ask to see one from a real conversation, with attachments and edits included, and ask whether the same is reachable through an API for a bulk disclosure
What happens when someone leaves the organisation, to their access and to their messages?
How is messaging history retained, and can we configure it ourselves? A fixed window chosen by the supplier is not a retention policy
What happens in a breach? If the record lives in the supplier's systems, their breach becomes your notifiable one. Ask what alerting exists, who is told and how quickly
Is there a login for every participant, or can someone take part with a verified phone number? This decides whether people outside your organisation can be included at all
How does the product tell participants that the conversation is on the record?
Does it integrate with what you already run, or does it become a second place to look?

Two of those deserve expanding. Ask to see the retention policies the platform can actually enforce, rather than the retention period it advertises: a messaging platform that keeps everything for ever has no retention policy, it has a storage bill and a data protection problem. And ask which security features are on by default rather than available, because the gap between the two is where most implementations sit.

The integration question is not a nicety either. A compliant channel that nobody uses because the work happens elsewhere produces a complete record of nothing.

Where the record should live

The question most buyers skip is custody: not whether there is a record, but whose it is.

This is where business messaging differs most from consumer messaging, and where best practices in records management have something to say that product marketing does not. The common pattern is that the supplier keeps it. That is simple, and it is fine until you need the record for something the supplier is not part of: a subject access request with a one month clock, a legal hold, a regulator asking for something at short notice, or the end of the contract. At each of those points you are asking a third party for your own evidence.

The alternative is that the record files into a system you already own and already control, so that retention, legal hold, search and disclosure use the tools your organisation has, and the messaging supplier is not in the path of your own obligations. For most UK organisations that means their own Microsoft 365 tenant, where the retention and eDiscovery machinery already exists and is already covered by their information governance.

The practical test is a question to ask yourself rather than the supplier: if we stopped paying this company tomorrow, what happens to three years of our own records? If the answer involves a support ticket, that is worth knowing before you sign rather than afterwards.