Security Audit Logging: What to Log, How Long to Keep It, and Why
An audit log answers one question during an incident: who did what, when, and from where. Log logins, permission changes, and sensitive data access, protect the log itself from tampering, and keep it long enough to investigate.
A security audit log is the record that answers one indispensable question during any incident: who did what, when, and from where. Without it you discover a breach but cannot tell how the attacker got in, what they touched, or when it started, so the incident turns from a contained problem into an open-ended disaster. The practical rule is to log events that change state or expose sensitive data, not every click. The core events you must log are successful and failed login attempts, permission and role changes, access to or export of sensitive data, changes to security settings, and any deletion or edit of the logs themselves. Every useful line answers four elements: who (a real identity, not just a number), when (a precise timestamp with a clear timezone), what (the event and the affected resource), and where (the IP address and device). More important than logging itself is protecting the log from tampering, because the first thing a skilled attacker does is erase their trail, and if the log sits on the same server under the same user permissions its value is gone. That is why logs are shipped to a separate, read-only location. Retention is set by the longest period you might need proof: 90 days as a practical minimum for investigations, and a year or more for regulated organizations. This guide covers exactly what to log, what a useful line looks like, how to protect the log itself, and how it ties into Saudi compliance.
Which Events Actually Deserve Logging
The first mistake that kills the value of any audit system is logging everything indiscriminately, which produces enormous noise that hides the important event like a needle in a haystack and burns disk for nothing. The criterion is simple: log what changes state or reveals a secret. In practice these are the non-negotiable categories.
- Authentication: every successful login, every failed attempt, every logout, and every account lockout after repeated tries. Consecutive failures from one address are the clearest sign of a brute-force attack.
- Permissions: creating a user, changing a role, granting admin rights, resetting a password. Elevating a normal user to administrator is the most dangerous event in any system.
- Sensitive data: reading, exporting, or deleting records that hold personal or financial data. A full customer table exported at midnight deserves an immediate alert.
- Security settings: disabling encryption, changing the firewall, turning off two-factor authentication, editing access rules.
- The log itself: any attempt to delete or edit logs or stop the logging service.
What does not belong in a security audit log is ordinary browsing and routine non-sensitive queries, which belong in a performance log, not a security one.
What a Useful Line Looks Like: Who, When, What, Where
A log line that fails to answer the four elements is useless during an investigation. Compare a line that says "login failed" with one that says "login failed for user admin from 203.0.113.44 on 2026-09-23 at 02:14:07 Saudi time from an unusual browser." The first is noise, the second is evidence. Make each line structured, JSON for example, so it is easy to search and filter later.
| Element | Answers | Example |
|---|---|---|
| Who | The actor's identity | User ID and name, not an anonymous number |
| When | The precise time | Timestamp with an explicit timezone |
| What | The event and resource | "Deleted invoice number 1187" |
| Where | The source | IP address, device, session |
An important note: never log the sensitive values themselves. Log "password changed," not the password, and "card number accessed," not the number, because a log full of secrets becomes a target instead of a guard.
Protecting the Log Itself from Tampering
The weakest point in any audit system is a log within reach of the person being audited. An attacker who reaches the server with high privileges will erase their trail first, and if the log is a local file they can write to, the evidence is gone. The fix has three layers. First, ship the log to a separate server dedicated to logs the moment it is created, so it arrives there before anyone can touch it. Second, make the storage append-only, so no line is edited after it is written. Third, sign the logs or link them in a hash chain so any later change is detectable. On an independent cloud server where you hold root, you can build a separate log server easily, which is hard on shared hosting where you lack that level of control.
How Long to Keep Logs and Why
Retention is not an arbitrary number, it is calculated from the longest period you might need to look back. Many breaches are discovered months after they happen, so a log wiped after a week is useless for an investigation that starts three months later. The practical minimum is 90 days for operational events, while critical security events like permission changes and sensitive data access are kept a year or more. Regulated organizations in finance, healthcare, and government are often required to keep specific longer periods by law. The balance here is between the value of the evidence and the cost of storage, and the smart approach is tiering: keep recent logs close and fast to reach, and move older ones to cheaper compressed storage with an organized backup add-on. Remember that a compressed archived log is far cheaper than your inability to prove what happened to a regulator.
The Log as Evidence in Disputes and Incidents
A log's value shows not on the day it is written, but on the day of the crisis. In a dispute with a customer claiming they never ordered a service, the log settles it with who signed, when, and from which address. In a leak incident, the log draws the timeline: when the attacker entered, which accounts were used, and which data was touched, so you know the real damage instead of assuming the worst. In a regulatory audit, the log is what proves you actually control access to citizen data rather than merely claiming it. That is why the log must be accurate, reliable, and tamper-proof, because a log that can be manipulated is no evidence to anyone. Organizations handling sensitive data inside the Kingdom find a foundation for this in Saudi hosting, since logs and data stay on Saudi ground. See cloud hosting for details.
A Practical Summary
Start by defining the five core event types: logins, permissions, sensitive data, security settings, and tampering with the log itself. Make each line answer who, when, what, and where, without storing secrets inside it. Ship the log immediately to a separate append-only location, and keep the critical parts for at least a year. Most important: test that you can search your logs and reach a specific event quickly, because a log you cannot pull an answer from during an incident is as good as absent. Review your logging setup today, and start from the question: if a leak happened right now, could I tell who got in, when, and what they took?
