Audit logging shows up in enterprise procurement checklists and gets implemented as an afterthought - a table that records some events, populated wherever someone remembered. Then a customer asks who changed a permission six months ago and the honest answer is that nobody knows, which is a bad conversation to have during a renewal.
01Audit logs are a different thing from application logs
Application logs exist for engineers debugging problems. They are verbose, unstructured, retained for weeks and routinely dropped when volume gets expensive. Audit logs exist for customers and regulators answering accountability questions, and every one of those properties is wrong for that purpose.
An audit log needs to be complete for the events it claims to cover, immutable, retained for years, and queryable by the customer rather than only by you. Trying to serve both purposes from one system produces something that is unsatisfactory for both.
| Application logs | Audit logs | |
|---|---|---|
| Audience | Your engineers | Customer, auditor, regulator |
| Completeness | Best effort | Guaranteed for covered events |
| Mutability | Whatever | Append-only, tamper-evident |
| Retention | Weeks | Years, contractually specified |
| Access | Internal | Customer-facing, exportable |
02What every entry must contain
Who, what, when, where and to what. The actor including whether it was a user, an API key or an internal process; the action; a precise timestamp; the source IP and user agent; the target object; and for changes, the before and after values.
Before-and-after is the field most often omitted and most often needed. 'User X updated settings' answers almost nothing. 'User X changed the data retention period from 90 days to 7 days' answers the question the customer is actually asking.
03Write it where it cannot be missed
Audit events written by application code at each call site will be incomplete, because someone will add a new mutation path and forget. Write them at a chokepoint instead - the data access layer, a database trigger, or an event stream derived from the change log.
The other reliability requirement is that the audit write and the business change succeed or fail together. An audit log missing entries because the write failed silently is worse than no audit log, because it invites confident conclusions from incomplete data.
| Category | Examples |
|---|---|
| Authentication | Login, failure, MFA change, session revoked |
| Authorisation | Role granted or removed, permission changed |
| User lifecycle | Invited, activated, deactivated, deleted |
| Data access | Export, bulk download, report generation |
| Configuration | Security settings, retention, integrations |
| Support access | Your staff accessing their tenant |
04Log your own access to their data
Support staff impersonating a user or querying a tenant's data is exactly what enterprise security teams worry about, and it is the category most vendors omit from their audit log entirely.
Recording it - who accessed which tenant, when, why, and under what ticket - is a strong trust signal and increasingly a contractual expectation. Customers who ask for it are usually surprised when a vendor can actually produce it.
05Make it theirs, not yours
An audit log that requires a support request to query is not serving its purpose. Customers need to search it themselves by actor, action, object and date range, and export it for their own retention.
Streaming to their SIEM is the mature version of this, and it is a common enterprise requirement. Offering a webhook or an S3 export means their security team sees your events alongside everything else, which is where they want them.
Topics
Priya Iyer
Staff Engineer · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer