Why Most "Audit Logs" Wouldn't Survive an Actual Audit

Tamper-evident doesn't mean encrypted, and it doesn't require a blockchain. It means write-once storage that the systems generating the events can't later modify, plus a way to detect if a record was altered or deleted, typically a hash chain where each entry references the previous one's checksum.

The part teams skip is separation of duties: the credentials that write audit events shouldn't be the same credentials an engineer uses for normal database access, and the people who can delete or truncate the audit store shouldn't overlap with the people whose actions it records. Get that separation right before worrying about cryptographic signing.

A log that holds up to scrutiny has these properties:

• Write-once storage that the systems generating the events cannot later modify.
• A way to detect alteration or deletion, typically a hash chain where each entry references the previous entry's checksum.
• Separate credentials for writing audit events and for everyday database access by engineers.
• No overlap between the people who can delete or truncate the audit store and the people whose actions it records.

How long to keep audit logs isn't a technical question, it's a contractual and regulatory one, and the right answer depends on your specific customer agreements and whichever frameworks apply to your industry. Guessing a duration and hard-coding it into a lifecycle policy is how teams end up either paying to store logs nobody needed, or deleting evidence an auditor asks for six months later.

Confirm the actual retention requirement with your compliance lead or counsel before you build the deletion policy, not after. Tiered storage, hot for recent activity, cold and cheaper for the long tail, is the easy part once you know the real number you're building for.

A minimal, correct audit logging pipeline is a smaller build than most teams expect: an append-only event stream, a write-once storage target, and a small set of query tools for support and security to use during an investigation. Say a two-engineer team owns this: the first version, covering the handful of event types an auditor actually asks about, is usually a few weeks of focused work, not a quarter-long project.

What grows the scope is trying to log everything from day one instead of the specific actions that matter for compliance and incident response. Start with access changes, permission grants, and data exports, and expand from there once you know what an actual audit or investigation asks for.

For example, imagine a customer's security questionnaire asks who changed an administrator's permissions last quarter, and when. With a minimal pipeline covering access changes, permission grants and data exports, support can answer from the write-once store in minutes and show that the record was not edited. Without it, someone searches application logs that an engineer could have altered and hopes the relevant lines were not rotated away. Start by writing down the three or four questions an auditor is most likely to ask, then build only the event types that answer them.

Vanta and Drata don't build your audit logging pipeline for you, and they don't replace the engineering work above. A compliance automation platform in this category typically connects to the systems you already run and collects evidence for a SOC 2 or ISO 27001 audit, instead of your team assembling screenshots by hand every quarter.

That's a real time saver once the underlying logs exist and are trustworthy, but it's not a substitute for them. Bring in a platform like this after you've built tamper-evident logging, not as a way to avoid building it.

When an auditor or a regulator asks how fast you remediate a known exploited vulnerability, CISA's own federal directive draws the line at two weeks for newly cataloged CVEs and six months for older ones¹. Without audit logs that show when a vulnerability was found and when it was actually closed, you're making a claim you can't back up.

This is the concrete reason audit logging and vulnerability management end up in the same conversation: one system finds the problem, and the other proves, later, that someone acted on it in time.