Tamper-Proof Audit Logs: What to Build In-House vs. What to Buy

Emitting a structured audit event on every privileged action (who did what, to which resource, when, from where) is application code, not infrastructure. No platform can know your domain model well enough to log "user X changed the billing owner on account Y" correctly. Write a small audit-log helper, call it from every mutation that touches sensitive data or admin actions, and ship the events to append-only storage.

The mistake to avoid is trying to backfill this later by parsing web server logs or database change streams. Those capture what happened at the HTTP or SQL layer, not the business action, and reconstructing intent from them after an incident is close to impossible.

Tamper evidence, meaning a cryptographic chain that proves a log entry hasn't been edited or deleted after the fact, is a genuinely hard problem to build correctly. A hash chain sounds simple until you have to handle key rotation, clock skew across regions, and an auditor asking you to prove the chain wasn't broken and rebuilt. This is the piece where a compliance automation platform's audit trail feature, or a managed append-only log service, is worth the license cost.

Building your own hash-chained log is reasonable only if you have a security engineer who can own key management for it long-term. If that's not a role you have staffed, buy this part.

Once events are captured and tamper-evident, retention is a storage tier and a deletion schedule. Cheap cold storage handles years of audit events at a cost that rarely justifies a platform on its own. The real work is deciding the retention period per event type against whatever framework applies to you (SOC 2, HIPAA, PCI), and writing that decision down so an auditor doesn't have to ask why some logs are two years old and others are seven.

Don't let a vendor's default retention setting stand in for that decision. Set it explicitly per log category.

Emit structured events from your own application code, forward them to a managed log store with immutability guarantees turned on, and layer a compliance platform on top for the specific evidence bundles auditors ask for (access reviews, change approvals, incident timelines). This keeps the cheap, domain-specific part in-house and pays for the hard cryptographic and audit-workflow part.

Revisit the split once a year against your actual audit findings. If an auditor keeps asking for evidence your current stack can't produce cleanly, that's the signal to buy more of the workflow, not to build a custom report generator.

A workable split for a small engineering team looks like this:

1. Emit a structured event from your own application code on every privileged action, recording who did what, to which resource, when, and from where.
2. Forward those events to a managed log store with immutability guarantees turned on, so nobody can edit or delete entries after the fact.
3. Layer a compliance platform on top only for the evidence bundles auditors ask for, such as access reviews, change approvals, and incident timelines.
4. Set retention explicitly for each log category and write down the reasoning, so an auditor never has to ask why some logs are kept longer.
5. Revisit the split once a year against your actual audit findings and buy more of the workflow only where gaps keep appearing.

Teams that put off audit logging until an auditor asks for it end up trying to reconstruct history that was never captured, which isn't possible. It's cheaper by a wide margin to log a privileged action from the day it ships, even before you have a compliance framework in scope, than to retrofit logging onto a year of existing admin actions once a deal requires it.

A useful test: if a customer asked "who changed this setting on our account, and when," could you answer today without guessing. If the honest answer is no, that's the gap to close first, independent of whichever framework eventually asks for it.

For example, imagine a team that ships an admin console without any audit events, then signs a customer whose contract requires a record of every permission change. The team can start logging today, but the first several months of admin activity are gone for good. A better sequence is to add one small audit helper the same week the first privileged action ships, even if it only writes structured events to append-only storage. Tamper evidence and a retention policy can be layered on later, because captured events are the one input that cannot be recreated after the fact. If you can only do one thing this quarter, do the capture step first.