Audit log

Why it matters

Without one, answering 'who changed this and when' after an incident is guesswork. An audit log turns that into a checkable fact, which matters both for genuine security investigations and for demonstrating compliance to a regulator or an auditor who needs evidence, not an assurance. It also deters bad behaviour before it happens: people are measurably less likely to misuse access they know is logged and reviewable, which makes an audit log a preventative control, not just a forensic one after the fact. It also supports post-incident learning beyond just the immediate investigation: a clear log lets a team reconstruct exactly how an incident unfolded and fix the specific gap that allowed it.

What goes wrong when it's handled badly

A system that logs actions but allows those logs to be edited or deleted by the same accounts being audited defeats the purpose entirely, since a log that can be altered by the person it might implicate is not actually evidence of anything. Logs kept only in application memory or a database table with no separate, protected storage are a common, quiet version of this same failure. A concrete example is an incident investigation that stalls because the only record of who accessed a sensitive record was the application's own general-purpose error log, which rotates and deletes entries after a short retention window, long before anyone realised they needed to check it. Storing logs in a separate system the audited application itself has no write access to, rather than alongside the application's own data, is what keeps a log trustworthy even if the application is compromised. Testing that logs actually capture the events they are meant to, rather than assuming the logging code works correctly, is a check worth running deliberately rather than skipping.