Audit log / activity log
Also known as: audit log, activity log, audit trail, event log, logging
An audit log (or activity log) is a record of events across your systems (logins, file access, changes, administrative actions) capturing who did what and when.
These logs are essential for investigating security incidents, detecting misuse, troubleshooting, and demonstrating compliance. Without them, you're left guessing what happened.
Audit log / activity log, explained at three levels
At home
An audit log is like the visitor sign-in book at a front desk, except the computer fills it in automatically and nobody can skip it. Each entry records who did something, what they did, which file or setting it touched, and exactly when. If something goes wrong, you can flip back through the book to see what happened, instead of guessing.
At work
An audit log is a time-stamped record of actions in a system: sign-ins, file access, permission changes, admin actions, and deletions. Microsoft 365, Google Workspace, firewalls, and most business apps keep one. A business relies on it to investigate incidents, detect misuse, answer 'who changed this', and prove to auditors, insurers, or regulators that access to sensitive data is tracked.
At home
Each log entry is a structured line with a timestamp, the user or device, the action, the object it touched, and the result, such as success or failure. Systems keep these locally for a limited time, then delete the oldest. In Microsoft 365, for example, the standard audit log keeps entries for 180 days. Because different systems keep their own clocks, devices sync with a time server so entries from different systems can be lined up.
At work
Useful business logging covers identity events (sign-ins, MFA failures, new admins), data access (opening or sharing sensitive files), configuration changes, and security alerts. Logs from Microsoft 365, the firewall, servers, and endpoints are most useful when collected in one place, a log management system or SIEM, where they can be searched together. Retention should match compliance needs: PCI DSS requires a year of history, with three months immediately available. Logs should also be stored where an intruder can't erase them.
At home
A log is only evidence if it can be trusted. An attacker with admin rights on a server can usually clear its local log, which is why logs are forwarded off the device as they're written, to separate, append-only storage. Clocks must be synchronized, or events from two systems appear in the wrong order. While collecting everything sounds safest, in my view a smaller set of well-chosen events that someone actually reviews is worth far more.
At work
Mature logging feeds a SIEM, such as Microsoft Sentinel, Splunk, or Wazuh, that parses logs into a common format, correlates events across sources, and raises alerts on patterns like impossible travel or mass downloads. Integrity relies on off-host forwarding, immutable storage, and synchronized time via NTP. Retention balances compliance needs against storage cost. Common failures are logging never switched on, retention too short to cover a breach discovered months later, and alerts nobody triages.
Real-world examples
At home
When Thomas suspected an ex-employee had accessed files after leaving, the audit logs gave him the answer: they showed exactly which accounts accessed what and when, confirming no unauthorized access had occurred and putting his mind at ease with actual evidence.
At work
After a suspected account compromise, Nadia's MSP used centralized audit logs to trace exactly what the attacker accessed and when, scoping the incident precisely for breach assessment. The same logs satisfied the firm's compliance requirement to demonstrate monitoring of access to sensitive data.
Common confusions
- Logs only matter after something goes wrong — Logs must be enabled, retained, and ideally monitored before an incident: you can't recover data that was never recorded. Proactive logging and alerting also help detect problems early.
- Systems log everything I need by default — Default logging is often minimal or short-lived. Capturing the right events, retaining them long enough, and protecting them usually requires deliberate configuration.
- Logs are automatically trustworthy evidence — If logs can be altered by whoever caused an incident, their value drops. Tamper-resistance, off-host storage, and time synchronization are needed for logs to serve as reliable evidence.
For analysts
Audit logs are how you answer 'who did what, and when' after an incident, and how you prove compliance. Ensure security-relevant events are captured, centralized, protected from tampering, and retained long enough, since problems are often discovered weeks after they occur.
History & origin
Logging has been part of computing since its early days, but the security and compliance value of comprehensive audit trails grew as breaches and regulations demanded accountability. Standards and laws increasingly required organizations to record and retain logs of access to sensitive systems and data. Centralized log management and SIEM tools emerged to collect, retain, and analyze logs across many systems for detection and investigation.