AuditRails vs. building audit logging yourself
“Just log to Postgres and add a timestamp” is where most in-house audit logging projects start, and where most of the actual cost is hidden. Here's a realistic breakdown of what it takes to build tamper-evident, auditor-accepted logging in-house, and where the DIY path usually breaks down.
The real cost of building it yourself
This is what a from-scratch build typically costs a small platform or security team, based on the pieces an auditor will actually test.
| Line item | Building it yourself |
|---|---|
| Engineering time (initial build) | 4-8 weeks for a mid-level engineer to design a hash-chaining or append-only schema, wire up ingestion, and build a query and export path. Longer if WORM storage and per-tenant isolation are also new to the team. |
| WORM storage configuration | S3 Object Lock (or equivalent) needs to be configured in compliance mode with the retention period set correctly before any data lands, since it can't be relaxed retroactively for objects already under lock. Getting the bucket policy, lifecycle rules, and IAM boundaries right the first time is its own project. |
| Retention policy per framework | SOC 2, HIPAA, PCI DSS, and SOX all specify different minimum retention windows. A generic “keep logs for a year” policy doesn't hold up if you're subject to more than one framework, and retroactively fixing retention on already-written data is not straightforward with WORM storage. |
| Verification tooling | An auditor, or your own security team, needs a way to prove the log wasn't altered after the fact, not just that it's stored somewhere durable. That means building and maintaining a hash-chain verifier, independent of the system that wrote the logs, that can recompute and check every entry. |
| Ongoing maintenance | Schema changes, new event types, scaling the query path past a few million rows, and re-explaining the whole system to a new auditor each cycle. This is a standing cost, not a one-time build. |
Where DIY audit logging usually breaks down
The database part is the easy part. The parts that actually cause auditor pushback are the ones teams skip under deadline pressure: no independent verification tool, so “trust us, it's a hash chain” isn't provable, retention that wasn't locked in before the framework's requirement was known, and no clear separation between the system writing logs and the system storing them, which an auditor will ask about directly.
When building it yourself is the right call
If you have exactly one compliance framework, low event volume, and a security engineer with time to own this as a real ongoing responsibility, not a side project, DIY can work. It's a reasonable call for a well-resourced platform team that wants full control over the schema and query layer. It's a harder call once you're serving auditors across multiple frameworks or need to hand a verification tool to a customer's security team.
Frequently asked questions
How long does it actually take to build audit logging in-house?
For a minimal version, an append-only table with timestamps, a few days. For something that survives a SOC 2 or HIPAA audit, meaning tamper-evidence, correct WORM retention, and independent verification, plan on 4-8 weeks of focused engineering time plus ongoing maintenance.
Is a hash chain overkill for audit logs?
Not if an auditor will ask how you know a log wasn't edited after the fact. A plain append-only table proves nothing about tampering on its own; a hash chain, where each entry's hash depends on the previous one, makes any alteration mathematically detectable. AuditRails builds this in by default so it's not a separate project.
Can I just use S3 Object Lock and skip the hash chain?
Object Lock (WORM) is necessary but not sufficient by itself. It stops an object from being deleted or overwritten within its retention window, but it doesn't prove that what you wrote in the first place was complete and untampered before it landed in the bucket. AuditRails combines WORM storage with a per-tenant hash chain so both properties hold.
What happens if we build it ourselves and then need to add a second compliance framework later?
This is usually where the “we'll build it ourselves” decision gets revisited: a schema and retention policy built for one framework often needs rework for a second one with different retention or field requirements. AuditRails' framework toggles, on the Framework Trails and Compliance Trails plans, exist for exactly this case, since the underlying log format doesn't change per framework.