An Audit Trail for Every Public Claim You Make

Every public claim a product makes is a small promise: this is true, and we can show it. Most teams make dozens of such promises on a single page, such as a number of customers, a speed, an award, a security feature, and then forget where each one came from. Six months later, nobody remembers whether "trusted by over four hundred teams" was the count in March or in January.

An audit trail solves this. It is a modest habit of writing down, beside each claim, the evidence for it and the date. It costs little to keep and saves a great deal of trouble when someone asks a question, when a figure moves or when an error has to be corrected. This guide explains how to build one for a launch.

What an audit trail is

An audit trail is a record that lets a sequence of events or decisions be traced and reconstructed. In accounting and software, it records who did what, when and why. Applied to claims, it answers four questions for each statement on your pages: what do we say, what supports it, when was that true and who is responsible for keeping it right?

Provenance, the record of the origin of something and the chain of custody that follows, is the related idea. A claim with good provenance can be traced back to its source. A claim without it is an assertion.

Why bother

Four reasons stand out.

Honesty at speed. Teams write marketing copy quickly and from memory. A register makes it easy to check before publishing.

Faster answers. When a buyer, an editor or a verification check asks, "How do you know?", you can reply in minutes with a source.

Fewer silent errors. Numbers drift. A register with review dates surfaces claims that have gone stale.

Fair treatment of a mistake. If something is wrong, a trail shows how it arose and lets you correct it fully, not just the one place you noticed.

There is also a legal and ethical side. Statements to the public about a product are subject to rules against misleading claims in many places. Evidence is the best defence for the honest, and a clear signal to everyone else that you take your statements seriously.

Step one: list the claims

Start with an inventory. Go through your home page, your listing, your pricing page, your about page and your documentation, and copy out every factual statement that a reader could check. Do not include opinions or slogans. Include:

• Numbers: customers, users, countries, uptime, speed, ratings.
• Comparisons: "faster than", "the only", "the first".
• Features: "works with", "supports", "encrypts".
• Credentials: awards, certifications, memberships, press mentions.
• Facts about the company: founding date, location, team size, registered name.
• Statements about results: "saves an hour a week", "reduces errors".

You may be surprised by the length of the list. That is the point.

Step two: attach evidence to each

For every claim, record the evidence. Good evidence is something a third party could inspect.

• Exports and reports from your own systems, with the date and the filters used.
• Public records, such as a company register entry or a published certificate.
• Links to published sources, such as an award page or an article, with the date you saw it.
• Dated screenshots, where the source cannot be linked.
• Written permission, for any use of a customer's name, logo or quotation.
• Test results, with the method described, for claims about speed or accuracy.

Evidence should be stored where the team can find it and where it cannot be quietly altered. A shared folder with sensible naming and version history is enough for most teams. Data integrity, the maintenance of accuracy and consistency of data over its life, is what you are protecting.

If you find a claim with no evidence, you have two choices: find some or remove the claim. Do not leave it hoping nobody asks.

Step three: record the date and the owner

A claim is true at a time. Record three dates: when the evidence was captured, when the claim was last reviewed and when it must next be reviewed.

Also record an owner, one named person who is responsible. A claim owned by everyone is owned by no one. The owner does not need to find all the evidence, but they must make sure it is checked.

A simple register can be a spreadsheet with these columns: claim, where it appears, evidence, evidence date, owner, next review. A table in a shared document does just as well. Choose the tool the team will actually keep up.

Step four: set review rhythms

Different claims age at different rates.

• Fast-moving figures, such as customer counts or monthly users: review monthly, or tie them to a live source.
• Performance claims: review when the product changes materially.
• Credentials and awards: review when they expire, and note the expiry.
• Company facts: review when something changes, and at least annually.
• Comparisons: review whenever a competitor changes, which is often.

For figures that change constantly, consider replacing a hard number with a phrase that stays true, such as "used by hundreds of teams", only if the statement is still accurate. Or display the date beside the number: "As of the first of March."

Step five: control changes

Treat edits to public claims as controlled changes.

• Log who changed what and why. A line in the register or a note in the change history is enough.
• Review before publishing any new claim: check that the evidence exists.
• Keep old versions, so that you can show what a page said at a given time.
• Do not backdate. If a figure was wrong, record that it was wrong, rather than altering the history.
• Link claims to pages, so that when evidence changes you know which pages to update.

This discipline is what turns a list into an audit trail.

Handling corrections

Mistakes will happen. How you handle them matters more than the fact of them.

1. Confirm the error. Check the evidence and establish what is true.
2. Correct it everywhere, using the register to find every place the claim appears.
3. Say so where it matters. If readers could have been misled in a way that affected a decision, add a short, dated note.
4. Record what happened: the original claim, the correct fact, the date and the cause.
5. Improve the process, whether that is a review step, a clearer owner or a live data source.

A visible, prompt correction tends to build trust rather than damage it. A buried one, found later by someone else, does the opposite.

Sharing evidence

You need not publish everything. Decide what to show.

• Publish what is safe and helpful: a methodology note, a dated figure, a link to a third-party source.
• Share on request what is sensitive: customer names, detailed exports, security reports. Agree terms first.
• Never publish private data, secrets or anything covered by confidentiality.
• Explain the method for numbers that need context, such as how "active users" are defined.

A short methodology note, linked from the claim, often answers most questions without giving anything away.

Pitfalls

• Evidence that is only in someone's head. Write it down.
• Screenshots without dates. They cannot show when something was true.
• Counting differently from week to week. Define a measure once and keep to it.
• Cherry-picked periods. A figure for the best month, presented as typical, misleads.
• Customer logos without permission. Ask, and keep the reply.
• Orphan claims. A page that has not been touched in two years but still states a figure.
• Over-engineering. A simple, maintained register beats an elaborate unused system.

A worked example

A two-person company lists twenty-six claims across its home page and listing. For each they record the source. Eleven are easy: a company register entry, an award page, a feature list that matches the product. Five rely on internal exports, which they save with the date and the filter. Four have no evidence at all: "the fastest in its class", "loved by designers", "bank-grade security" and "ten thousand downloads".

They remove the first three, replace "bank-grade security" with a plain description of the encryption they actually use and find that the download figure was from a previous version of the product and is now outdated. They update it with the current export. They add an owner and a next-review date to each row and set a calendar reminder for the first working day of each month.

Three months later, a journalist writes to ask where the customer count came from. The founder opens the register, finds the export and replies within the hour. The count has since grown, so she updates the page and the register on the same day. The register took an afternoon to build and has already saved a worse afternoon.

Questions teams ask

Is this overkill for a small team? The smaller the team, the more a simple register helps, because fewer people remember the details.

Who should own the register? One person, with a deputy. Each claim has its own named owner.

What if a source disappears? Archive a dated copy at the time, and note that the original is no longer online.

Should I keep evidence indefinitely? Keep it for as long as the claim is public and for a reasonable period afterwards, within data protection rules.

Summary

An audit trail is a habit of attaching evidence, a date and an owner to every public claim. List the claims, find or remove the evidence, set review rhythms, log changes and correct mistakes openly. Share what is safe and keep the rest ready for when someone asks. The aim is simple: whatever a reader sees on your page, you can show, at any time, why it is true.