Sooner or later someone asks who changed this record, and when, and what it said before. If the answer has to be reconstructed from application logs, it usually cannot be - logs have rotated, were never structured for the question, and record what the code did rather than what a person decided. An audit trail is a different artefact with different requirements, and it needs to be designed rather than inferred.
The distinction that matters is purpose. Logs exist for engineers debugging behaviour, are verbose, and are discarded after weeks. An audit trail exists to answer questions from auditors, regulators, customers and lawyers, is selective, and is retained for years. Trying to serve both from one system means either logs you cannot afford to keep or an audit trail buried in noise.
Record the actor, the action, the target, the time and the outcome - and where a value changed, both the before and the after. The actor is the piece most often missed: an entry saying a record was updated is nearly useless, while one naming the user, and the administrator who was impersonating them at the time, answers the actual question. Include a request identifier so an audit entry can be tied back to technical logs when someone needs the detail.
Make it append-only and mean it. An audit trail that the application can update or delete is not evidence of anything, because the first question anyone asks is whether it could have been altered. Write-only permissions for the application, no update or delete grants, ideally a separate store. Some regulated contexts want more - hash chaining, or export to storage with an immutability policy - but permissions alone put you far ahead of most implementations.
Be deliberate about what goes in, in both directions. Not every read of every record needs auditing, or the volume becomes unmanageable and the signal disappears; but access to particularly sensitive data usually does, and that is often the specific thing a regulator asks about. Meanwhile the values you record can themselves be personal data, so an audit trail of medical or financial fields inherits the sensitivity of what it describes and needs the same protection.
Two practical points. Retention has to be a deliberate figure, driven by the obligation rather than by what the disk allows - and note that audit records may need to survive the deletion of the data they describe, which is a genuine tension with erasure rights and worth taking advice on. And build a way to read it: an audit trail nobody can query is a compliance checkbox rather than a capability, and the moment you need it is never the moment to start writing the query.
