Build vs. Buy: Tamper-Evident Audit Logging for APIs

A complete log records every meaningful action: who did it, what changed, when, and from where. A tamper-evident log adds a guarantee that nobody, including someone with database access, can quietly edit or delete an entry without it being detectable. That usually means append-only storage, cryptographic hash chaining between entries so any edit breaks the chain, and write access that's separated from the systems and people whose actions are being logged. If your audit table lives in the same database an admin can already write to directly, it isn't tamper-evident no matter how detailed it is.

Writing rows to an audit table is easy. The hard parts are the ones that get skipped under deadline pressure: hash chaining or a Merkle structure so tampering is detectable, a retention policy that survives database migrations and doesn't get quietly reset, access controls that keep even your own senior engineers from writing to the log table directly, and a way to export and verify the chain for an external auditor without giving them database access. Budget for all four before deciding building in-house is the cheaper option.

Dedicated compliance and audit-evidence platforms exist specifically because this problem is deceptively deep. Tools like Vanta and Drata are built around continuously collecting evidence, including tamper-evident logging and control mapping, in a form auditors already recognize, which shortens both the initial setup and each renewal audit. The tradeoff is less control over exactly how the underlying data is structured and stored, and an ongoing subscription cost that a homegrown system wouldn't carry directly, even though the homegrown system carries its own hidden maintenance cost.

For example, imagine a small software company preparing for its first enterprise security review. Its audit table sits in the main application database, and two senior engineers can write to it directly. Before buying anything, the team lists which of the four build tasks (hash chaining, durable retention, restricted write access, and verifiable export) it can finish before the review date. If it can cover only one or two, adopting a platform that already provides them is the safer route. If the gap is narrow, building the missing piece on an append-only store can be reasonable.

How long you need to keep audit logs depends on what compliance framework you're targeting and what your customer contracts actually promise, not on a default your database vendor happened to ship with. Security-relevant events like access changes and privilege escalations typically need longer retention than routine application activity. Decide your retention windows per event category, write them down, and make sure whatever storage you use can enforce them automatically rather than relying on someone remembering to run a cleanup job on schedule.

Ask three questions about your current logging: can a person with production database access edit or delete a log entry without leaving a trace, could you produce a verifiable export for the last twelve months on short notice, and does your retention policy actually match what you've told customers or auditors it is. If the honest answer to any of those is no or you're not sure, that's the gap to close first, whether you close it by building the missing piece or by adopting a platform that already has it.

Signs your audit logging has a gap:

• A person with production database access can edit or delete a log entry without leaving a trace.
• You could not produce a verifiable export covering the last twelve months on short notice.
• Your retention policy differs from what you have told customers or auditors.
• Retention windows are not set per event category, or the storage does not enforce them automatically.
• Read access to the audit trail is broad, so engineers can see sensitive account notes without a narrower view.

Tamper-evidence protects against silent edits, but it doesn't limit who can read sensitive history, and audit logs often contain more than a security reviewer expects: internal notes on customer accounts, support actions, and sometimes fragments of the data a change touched. Restrict read access to the audit trail itself, not just write access, and decide explicitly whether engineers debugging an incident get direct access or go through a narrower, purpose-built view. This is a common gap: teams lock down who can write to the log and forget that broad read access has its own privacy and security cost.