Reconstruction is the standard
The question is rarely “what is the current state?” It is “how did this record get into this state, and who decided?” That requires history recorded at the time.
History cannot be reconstructed after the fact. Either it was recorded when the change happened or the answer does not exist.
What to record
- Who — the authenticated user, or the system process
- When — with a time zone
- What changed — field, old value, new value
- Why, where a reason is required by the process
- From where — the web interface, an import, an API
Not everything needs it
| Audit | Do not bother |
|---|---|
| Financial records | Session data |
| Anything customer-facing | Cache entries |
| Permission changes | Search logs |
| Status transitions | Draft working data |
| Anything disputed | Ephemeral records |
Auditing everything produces volume that makes finding the important entries harder. Audit what matters.
Make it immutable and queryable
- Write-once — audit records that can be edited are not audit records
- Queryable per record, so a specific history is retrievable quickly
- Retained per your records policy
- Visible to the people who need it, restricted from those who do not
Balance against data minimisation
Full audit history contains personal data, and retaining everything indefinitely conflicts with minimisation obligations.
Set a retention period aligned to your records policy and apply it automatically. Both requirements can be met; neither is met by accident.