What a CRM Audit Log Must Capture to Survive Board Review
An audit log that can't answer "who changed this, from what, to what, and when" is a liability dressed as a feature. Here's the bar for board review and due diligence.
The thesis: an audit log is evidence, not a feature
A business-app audit log earns its keep in one moment: when a board member, auditor, or acquirer asks who changed a record, what it was before, what it became, and exactly when. If your log can't reconstruct that without ambiguity, it isn't an audit trail, it's a comfort blanket.
Treat every audited mutation as evidence you may have to defend years later. That framing decides what you capture and how you store it, long before anyone asks for it.
Who-what-when: the non-negotiable fields
Each entry must answer four questions on its own, with no joins to context that may have since changed. We log this on every lead update in our sales-pipeline CRM, and the same shape applies to any business app.
- Who: the acting user's stable identifier, plus their role at the time, not as it reads today.
- What: the entity and the specific fields touched, captured as a before/after pair (value A to value B).
- When: a server-side UTC timestamp, never a client clock you don't control.
- Why/how: the action type (create, update, delete, restore, rollback) and the request path or channel.
Immutability is a recommended design, not an afterthought
A log a user can quietly edit proves nothing. We recommend designing the audit store as append-only: writes only, no updates or deletes through application code, with that constraint enforced at the database layer rather than trusted to convention.
Corrections are themselves new events. If an entry was wrong, you append a correcting record that references the original; you never overwrite history. For higher-assurance contexts, chaining each entry to a hash of the previous one lets a reviewer detect tampering, though that is a design choice to weigh against complexity.
Snapshots vs diffs: capture both, on purpose
A diff (this field went from value A to value B) is compact and readable, ideal for a notification or a timeline. A full snapshot of the record at the moment of change is what lets you reconstruct exact state and support rollback. They serve different jobs and the cheap mistake is choosing only one.
Our CRM writes both per change: a JSON-encoded snapshot for reconstruction and rollback, plus the field-level diff for human-readable history. Storage is cheap; an un-reconstructable record under due diligence is not.
The common gaps that fail review
Most audit logs fail not because they're absent but because they're partial. Reviewers probe the edges, and the edges are where teams cut corners.
- Reads aren't logged, so you can't prove who saw sensitive data, only who changed it.
- Deletes vanish: hard deletes erase the very records an auditor wants. Prefer soft deletes with the actor and timestamp retained.
- Bulk jobs, integrations, and migrations write under a system account, hiding the human who triggered them.
- Identity drift: storing only a user ID means a renamed or offboarded actor reads as unknown years later.
If your audit log can't tell a reviewer who changed a record, from what value to what value, and exactly when, without trusting that no one edited the log, it won't survive board review. Capture who-what-when on every mutation, design the store append-only, and keep both snapshots and diffs.
Frequently asked
Should I store snapshots or diffs in an audit log?
Store both, deliberately. Diffs (value A to value B) are compact and human-readable for timelines and alerts. Full snapshots let you reconstruct exact record state and support rollback. Each answers a different question under review, and storage is cheap relative to the cost of an un-reconstructable record.
Does an audit log have to be technically immutable to pass due diligence?
Reviewers want defensible evidence, not just a table of events. We recommend an append-only design enforced at the database layer, where corrections are new events that reference the original rather than overwrites. Hash-chaining entries adds tamper-evidence for higher-assurance contexts, but weigh it against the added complexity.
What's the most common audit-log gap reviewers find?
Partial coverage. Typical misses are unlogged reads of sensitive data, hard deletes that erase the records an auditor wants, bulk or integration actions hidden behind a system account, and identity drift where a bare user ID becomes meaningless after someone is renamed or offboarded.