Audit Log
An immutable record of who did what and when — required by enterprise buyers and compliance frameworks, and usually built as an afterthought.
An audit log records security- and data-relevant actions: who performed them, what changed, when, and from where. It is distinct from application logging, which exists for debugging. Audit entries must be immutable, retained for a defined period, and readable by a compliance officer rather than an engineer — which is exactly where most implementations fall short, because they were built by reusing the debug logger.
It is also a sales requirement. SOC 2, ISO 27001 and most enterprise security reviews expect one, and “we have logs” does not satisfy a question about tamper-evidence and retention. As an interface it is a data table problem with hard filtering requirements — by actor, by object, by action, by date range — and an export, because the buyer's auditor will want the evidence outside your product.
In practice
A vendor stored audit events in the same store as debug logs with a 14-day retention. An enterprise security review asked for 12 months of admin actions with tamper-evidence. Building it properly took six weeks and delayed the contract by a quarter — the log had existed for years and satisfied none of the requirement.
Where teams get it wrong
- Reusing the application logger, which is mutable and retained for days.
- Recording the action without the before and after values, so “updated settings” says nothing.
- No export, so a customer's auditor cannot review evidence outside your product.
- Retention shorter than what compliance frameworks expect.
- No filtering by actor, object or date, which makes the log unusable at volume.
( Learn more )
Related terms
All terms- SOC 2An audit report on how a service organisation handles customer data — the document that unblocks most enterprise software deals.
- Customer PortalAn authenticated area where customers handle their own account — the cheapest support channel a business has, when it covers the right things.
- Multi-TenancyOne application instance serving many customers with their data isolated from each other — the architecture nearly every SaaS product runs on.
- Data TableA grid of rows and columns for scanning, comparing and acting on records — the screen most B2B users spend their day inside.