You can only investigate an attack if you have logs. But logs kept longer than needed are a risk in themselves: they hold personal data, they create a second incident if they leak, and they cost money to store. "Keep everything forever" is not the right answer.
Short answer: how long should logs be kept?
Retention is not a single figure; it sits at the intersection of three inputs: statutory record-keeping duties, the time needed for incident investigation, and personal data retention principles. The workable approach separates log types and defines a period for each: security and access records longer, debug records far shorter. The critical point: the period must be decided once, written down and applied automatically; manually managed retention ends up either too short or infinite.
Which log type, for how long?
| Log type | What it is for | Typical approach | Risk |
|---|---|---|---|
| Authentication records | Who logged in and when | Kept longer | Contains usernames and IPs |
| Web access logs | Which address requested from which IP | Medium term | IPs can count as personal data |
| Security event logs | Blocked requests, suspicious behaviour | Kept longer | Low |
| Application error logs | Debugging | Short term | May accidentally record sensitive data |
| Database query logs | Performance analysis | Very short | Query content may hold personal data |
| Backup and job logs | Proving an operation ran | Medium term | Low |
The riskiest row is the fourth and it is rarely considered. Debug logs get enabled temporarily to solve a problem and nobody remembers to switch them off; they sometimes record form contents, session details or request bodies verbatim. Short retention and regular clearing manage that risk automatically.
Where legal duty meets security need
- Record-keeping obligations set minimum retention for certain activities. Those periods vary by legislation and activity type; clarify which apply to you with your legal adviser.
- Personal data principles require data to be kept only as long as necessary for its purpose. Keeping logs longer than needed is therefore also a compliance issue.
- Security need sits between the two: incidents are routinely noticed weeks later, so very short retention removes the possibility of investigation.
The balance works like this: the statutory minimum forms a floor and personal data principles form a ceiling; the security need is positioned within that range. Any practice outside it — however well intentioned — falls short on one side.
Protecting the logs themselves
- Keep records elsewhere. When a server is compromised, the logs on it lose their reliability. A central or external copy preserves evidential value.
- Make them write-once where possible. Records that cannot be overwritten or deleted for a period are far more useful in an investigation.
- Restrict access. Reading logs is a permission distinct from system access; it should not be open to everyone.
- Mask personal data. Not logging unnecessary fields reduces both risk and storage cost.
- Synchronise clocks. If systems disagree on time, an incident timeline cannot be built — investigation becomes practically impossible.
- Automate deletion. Records removing themselves at the end of their period is necessary for both compliance and disk management.
The fifth item looks minor but is decisive: correlating web server, application and firewall logs during an investigation is only possible when their clocks agree.
Netişlem expert view: the two extremes we meet most
We see two extremes in the field. First, businesses keeping no logs or deleting them within days; when an incident occurs there is nothing to examine and "how did they get in" stays unanswered. Second, businesses keeping everything forever; the logs become a years-deep pile of personal data and turn into a risk item themselves. The right answer sits between them and is set by a written policy.
Our second observation is that full disks are usually caused by logs. On a server without rotation, log files grow quietly and one day fill the disk — producing a sudden outage. It is among the most common scenarios covered in our hidden resource drains article.
Third, logs are kept on the server they describe. The critical question in a post-incident investigation is: can we trust these records? If the server was compromised, the answer is no. An external copy is what gives you a single trustworthy source when it matters.
Policy checklist
- Log types listed with a retention period written for each.
- Statutory minimums verified with an adviser.
- Fields containing personal data identified and unnecessary ones masked.
- Debug logging short-lived and off by default.
- Automatic rotation and deletion configured.
- An external copy of records maintained.
- Log access defined as a separate permission.
- Clock synchronisation active across servers.
- Disk usage alerting configured — see our monitoring article.
- Retention periods recorded in the data inventory — see the registry guide.
- Policy reviewed annually.
Frequently asked questions
Is an IP address personal data?
It can be treated as personal data where it can be linked to an identifiable person. Retention periods and access permissions for access logs should therefore be handled like other personal data. Make the assessment with your legal adviser.
Should I encrypt logs?
Yes if they contain personal data, particularly when stored externally. Encryption prevents a second incident should the records reach the wrong hands. Keep the key separate from the records.
Can I manage logs on shared hosting?
To a limited extent. Panels usually provide access and error logs, but you cannot set the retention period. The practical solution is downloading records regularly and keeping them in your own archive.
How far back does investigation need to reach?
A significant share of incidents is noticed weeks after the fact. A few days of security log retention is therefore insufficient in practice. Asking "how late might we notice an incident" is the most practical way to find the right period.
What if I find sensitive data in a log?
Fix the source first: stop the application logging that field. Then clear or mask the existing records and document what happened. That is the only way to prevent recurrence and to explain the process in a later audit.
Conclusion
Log management is a balance between keeping and deleting. The right arrangement separates log types, sets a written period for each, and applies it automatically. With that structure in place you can investigate an incident without accumulating data you do not need.
If you would like help building your log policy, get in touch. You can review our server management and secure hosting solutions.