What counts as an audit trail for business communications?

An auditor, a regulator, and a claimant’s solicitor will all ask a version of the same question: show me that the control was operating on the day this message was written. Each of them means something slightly different by “audit trail”, and the differences decide whether what you hand over is sufficient.

This is a practical definition, built from what those three parties actually accept.

The short answer

An audit trail for business communications is a timestamped record of what a control did when a message was being written or sent, who it applied to, and what happened next. Three elements, all required:

• The event. When the control ran and what it found.
• The scope. Which rule applied, and to which communication.
• The outcome. What the person did after being told.

A record with the first two and not the third shows a control that detects. A record with all three shows a control that changes behaviour, which is the harder thing to prove and the thing most frameworks are actually asking about.

What an audit trail is not

Three things get filed as audit trails and answer a different question.

An archive. Message archiving preserves what was sent. It satisfies recordkeeping obligations and it is where an investigation starts. It carries no record of any control acting, because archiving happens after the decision that mattered.

A policy with a version history. This evidences that a rule existed and when it changed. It says nothing about any specific message.

Training completion records. These carry a name and a date, which makes them feel operational. What they attest is attendance. They belong under awareness and training controls, where they are genuine evidence.

What each audience is asking for

Who is asking	What they are testing	What satisfies it
Certification auditor	Was the control implemented, followed, and effective	Sampled events showing the rule firing on real messages, with outcomes
Financial regulator	Were the systems and controls adequate and were they applied	Coverage across the population, plus what happened when the control flagged something
Opposing counsel	What did you know and when did you know it	An unbroken chronology, including the interventions

The common requirement across all three is the outcome column. Detection alone reads as a control that produces alerts. Detection with outcomes reads as a control that operates.

The awkward part: proving it without surveillance

An audit trail detailed enough to satisfy an auditor points at individuals by construction. Every event has a writer. That creates a direct conflict with employment and data protection expectations in most European jurisdictions, and it is the reason many organisations quietly avoid building one.

The conflict is resolvable, and the resolution is a design decision made before the first record is written.

Records can carry the department rather than the person. They can carry which rule fired without carrying the sentence that fired it. Reporting can be withheld below a participant threshold, so a team of three cannot be read as one named individual. Each of those reduces the evidential weight slightly and reduces the privacy exposure substantially, which is usually the right trade in an employment context.

What an auditor needs is the population, the rate, and the outcomes. Establishing that a control ran nine hundred times last quarter and that eight in ten flags were corrected does not require knowing who wrote any of them.

The minimum viable record

If you are building this from nothing, a defensible record for a single event contains six fields.

1. Timestamp. When the control evaluated the message.
2. Rule. Which policy or category fired, named the same way it is named in your control framework.
3. Severity. How the rule graded it, so a reviewer can sort by exposure.
4. Surface. Where it happened, since obligations differ by channel.
5. Group. The department or team, rather than the individual.
6. Outcome. Corrected, removed, or sent unchanged.

Six fields, and the sixth is the one that turns a log into evidence. It is also the one most commonly missing, because most systems record what they detected and stop there.

Written out, a single record looks unremarkable, which is the point. Something close to: 14 August, 09:42 · confidentiality · high · Outlook · Client Services · corrected before sending. No message content, no name, and enough to sample from.

How long to keep it

Retention on this record is a genuine tension, and it is worth deciding deliberately rather than defaulting.

Evidential value pushes retention out. An auditor arriving in March wants to sample the previous twelve months. A regulator examining a period two years ago wants the same period. A record that only covers the last ninety days cannot answer either.

Data minimisation pushes the other way. This is employment-context processing, and holding it longer than the purpose requires is difficult to justify.

The workable resolution follows from what the record is for. Event-level records with department attribution serve sampling, and a period matching your audit cycle covers that purpose. Aggregate counts, which carry no attribution at all, can be kept much longer at almost no privacy cost, and they are what supports the trend question a board asks. Keeping the detailed layer short and the aggregate layer long gives you both without holding personal-adjacent data indefinitely.

Write the decision down with its reasoning, whatever you choose. Retention that cannot be explained is a finding in its own right.

How to test what you already have

Open whatever you currently call your communications audit trail and try to answer three questions from it, without asking anyone.

How many times did a control act on a message last month. What proportion of those were corrected before sending. Which team accounts for the largest share, and is that share moving.

If the first question is answerable and the second is not, you have a detection record. If the third is answerable only by naming individuals, you have a record that will create a data protection problem the first time you try to use it.

A fourth question is worth adding once the first three pass. Can you produce the answer without asking a vendor to run a query for you. Evidence you cannot generate on demand tends to arrive late in an audit, and arriving late invites the auditor to widen the sample.

Where a pre-send check fits

A check that runs while a message is being written produces all six fields as a by-product of doing its job. The event, the rule, the severity, the surface, the group, and what the writer did with the suggestion.

It sits alongside archiving rather than replacing it. Archiving holds what was sent, which you are required to keep. A pre-send record holds what happened before sending, which is the part an auditor is asking about and the part an archive structurally cannot contain. Our audit trail is built to produce the second record at department level, with content withheld and individual attribution never stored.

The takeaway

Judge any communications audit trail by whether it answers the outcome question. If it tells you what was detected and stops, it is a detection log, and the finding it was meant to close will stay open. Add the outcome field before you add anything else. For the control-by-control view of what an auditor accepts, see our piece on A.5.14 information transfer evidence.