Our new audit log: every action, every actor, every byte

Audit logs are one of those features that every security product claims to have and almost nobody actually thinks hard about. A timestamp, a username, an event type — and call it done. We shipped that version of an audit log years ago. We’re not proud of it.

Earlier this month we replaced it entirely. This post covers what we built, why we built it, and what it means for the teams who have to hand evidence to auditors.

Why we rebuilt from scratch

The old log had three problems that compounded each other.

First, it was mutable. Events were rows in a relational table with no integrity protection. A misconfigured write-back, a runaway migration, an insider with direct database access — any of these could silently alter the historical record. We had no way to prove that hadn’t happened, which is exactly what SOC 2 TSC CC7.2 and ISO 27001 Annex A.12.4 ask you to demonstrate.

Second, exporting evidence was painful. Auditors typically want a filtered range of events in a specific format, with field-level attestation that the export hasn’t been tampered with. Our old export was a CSV dump with no attestation. Every audit cycle, our customers were spending four to six hours manually cross-referencing exports against screenshots.

Third, per-event attribution was lossy. We logged that a file was downloaded but not which specific version, which access policy granted permission, or which IP subnet the request originated from. Auditors — and more importantly, incident responders — need the full picture.

We ran a retrospective with six enterprise customers in Q4 2023 and asked them to walk us through their last SOC 2 evidence collection cycle. The average time spent on audit-log evidence prep was 9.2 hours per audit. That number stuck with us.

What’s new

Hash-chained event records. Every event now includes a cryptographic pointer to the previous event: prev_hash = SHA-256(previous_event_canonical_json). The chain anchors to a genesis block we sign at tenant initialization. Any gap or modification in the chain is immediately detectable. This follows the same tamper-evidence pattern used in certificate transparency logs.

Per-event signatures. In addition to the chain, each event carries an HMAC-SHA256 signature generated with a key derived from your tenant’s key hierarchy. You can verify any individual event in isolation without reconstructing the full chain. This matters when an auditor asks about a specific event rather than a full export.

Structured, exportable event bundles. Exports now produce a signed JSON bundle with a manifest, the event range, and a detached signature file. You hand the auditor three files. They run our open-source verifier (or their own implementation — the spec is public) and get a pass/fail on integrity. The export time has dropped from hours to minutes.

Richer event fields. Every file-transfer event now captures: file hash (SHA-256), transfer protocol, access-policy name and version, originating IP, resolved hostname where available, authenticated identity including federation source, and the specific permission grants that authorized the action. We modeled this on the evidence requirements we’ve seen across SOC 2, HIPAA Security Rule §164.312(b), and NIST 800-53 AU-9/AU-10.

Real-time streaming. The log is available over a webhook or SIEM connector with sub-second latency. If you need logs in Splunk, Sumo Logic, or a custom pipeline, events are there before the transfer is fully ACK’d.

Who’s using it and what they’re doing with it

Forthbridge Civic, a municipal government platform customer, used the previous audit log under a FISMA-adjacent framework that required evidence of access reviews every 90 days. Their compliance team was spending a full business day per quarter on log extraction and attestation.

After migrating to the new log in March, their first audit evidence package took 47 minutes to prepare — start to finish. Their compliance lead described it as “the first time the audit didn’t feel like a fire drill.”

The use cases we’ve seen so far break into three categories:

• SOC 2 Type II evidence packs. The hash-chain and per-event signatures map directly to what auditors ask for under CC7.2 (audit log integrity) and CC9.2 (change management evidence).
• Incident response timelines. When something goes wrong, the richer event fields let responders reconstruct exactly what moved, when, over which path, and who authorized it.
• Compliance spot-checks. Several HIPAA-covered customers are using the real-time stream to trigger automated alerts when a file matching a PHI classification tag is accessed outside business hours or from an unrecognized IP range.

What’s next

Two items are on the roadmap for H2.

We’re adding a long-term archive tier that stores sealed event bundles in customer-specified object storage (S3, GCS, or Azure Blob) with a rolling signature attestation every 24 hours. For customers who need 7-year retention under FINRA Rule 17a-4 or similar, this removes the need to trust us for long-term custody.

We’re also working on a query interface that lets compliance teams filter events by framework — you describe the control, we return the evidence window. That’s still early, but the audit feedback loop we’ve built with customers is shaping the query grammar.

We cut our average customer evidence-prep time from 9.2 hours to roughly 3.5 hours in our initial rollout cohort. That’s the 60% reduction we cited up top. The goal is to get it under an hour.