Contents
An audit trail records who created, changed, deleted or exported what, when, and with which values before and after. France’s data protection authority recommends keeping these logs for six months to a year in most cases; I plan it from the scoping stage of a business app budgeted at $6,800 to $22,400 (€6,000–€20,000)excl. VAT.
A customer price changed the day before a big order, a record deleted by mistake, a full database export on a Friday evening: in many company tools, nobody can say who did what. An audit trail answers that question. It serves security, internal control and plain common sense when data changes without explanation. Here is what to log, how long to keep it, and how I build it into a business app.
What an audit trail should record
A useful log answers five questions for each event: who (the individual user, not a shared account), what (the record or object involved), which action (create, update, delete, sensitive view, export), when (exact date and time) and with what result (value before, value after).
France’s data protection authority, the CNIL, has published a recommendation on logging measures (decision no. 2021-122 of October 14, 2021, in French). It covers logging of access, creation, modification and deletion actions on systems that process personal data (source checked in October 2026). It is a practical reference for any company subject to the GDPR.
| Event | Log it? | Why |
|---|---|---|
| Login, failed login | Yes, always | Detect intrusion attempts |
| Creating, updating, deleting a record | Yes, with before and after values | Know who changed what, fix mistakes |
| Change of permissions or role | Yes, always | Spot privilege escalation |
| Data export, bulk download | Yes, always | Detect a leak |
| Viewing sensitive data (HR, health, bank details) | Yes, if the processing justifies it | Access control |
| Viewing an ordinary record | Rarely | High volume, little value |
How long to keep logs
Keeping logs forever is neither useful nor compliant: they contain personal data themselves. The same CNIL recommendation sets a period of six months to one year in the general case. A longer period, up to three years in the most common cases, can be justified for processing subject to internal control measures, provided you document why.
In practice, I plan two tiers: a log that can be viewed in the app over the useful period, then automatic archiving or deletion beyond that. The exact period is decided with you, ideally with your data protection officer. These points are factual and drawn from the CNIL text; they do not replace advice from a lawyer on your own situation.
How I build it
There are two main ways to log changes, and I often combine them.
- Database-level logging. With PostgreSQL (the engine behind Supabase, which I use), triggers record every change to a sensitive table, whatever the path: screen, import or API. Nothing slips past the log.
- Application-level logging. It records the business actions that mean something to you: “quote approved”, “discount granted”, “customer file exported”. This is the log a manager actually reads.
Three rules complete the setup:
- One account per person. A “sales” account shared by five people makes any audit trail useless.
- An append-only log. The app writes, but nobody edits or deletes, not even an ordinary administrator.
- Viewing screens: the history of a record (“who changed this price?”) and a filterable global view for the security lead or management.
What it costs
The audit trail is priced during scoping, as part of the tool’s security.
| Situation | Price reference | Timeline |
|---|---|---|
| New business app with roles and audit trail | $6,800 to $22,400 (€6,000–€20,000)excl. VAT for the whole project | 1 to 3 months |
| Viewing screens and monitoring dashboards | Dashboard module: $1,700 (€1,500)excl. VAT in the estimator | Within the schedule |
| Checking what an existing app logs | Express audit $660 (€589)excl. VAT, full audit $2,300 (€1,990)excl. VAT | A few days to 7 days |
| Adding an audit trail to an existing app | Quoted after an audit | Varies |
Log storage is usually a small part of hosting costs, except at very high volumes. For a range that fits your tool, use the estimator.
When you do not need it
Not everything deserves a detailed log. For an internal tool used by three people on non-sensitive data, a simple “changed on … by …” history on each record is often enough. And if you use off-the-shelf software that already offers an audit history, the right call is to switch it on and read it, not to rebuild it.
On the other hand, an audit trail becomes essential as soon as the tool handles money (prices, discounts, payments), sensitive personal data, or is used by people outside the company. It works together with role-based access control and two-factor authentication: knowing who did what only makes sense if each person has a secure account and limited rights.
Where to start
- List the data that matters: prices, commercial terms, bank details, HR data.
- Check what your current tools already log: often the history exists but nobody looks at it.
- Decide who reads the log, how often, and how long it is kept.
- For custom software, put the audit trail in the requirements from day one. That is what I do when scoping a business app: adding it later costs more and leaves gaps.
Frequently asked questions
Does an audit trail slow the app down?
Not noticeably if it is well designed. Writing one log line is negligible compared with the rest of an operation. What costs time is searching through millions of lines, so you plan indexes, archiving and filtered viewing screens.
Do employees need to be told their actions are logged?
Yes. Logging actions in a work tool is processing of personal data under the GDPR: employees must be informed, the purpose must be defined (security, evidence, internal control) and the retention period limited. Have this reviewed by your data protection officer or legal counsel.
Can data be restored from the audit trail?
If the log keeps the values before and after each change, yes, for a specific record or field. It is very handy for undoing data entry mistakes. It does not replace backups, which are used to restore the whole database after an incident.
Can an administrator erase their own tracks?
They should not be able to. I design the log as append-only: the app can write to it but cannot modify or delete a line, and viewing rights are kept separate from ordinary admin rights.