Logs, Law, and the Art of Letting Go: Retention Rules for UK Linux Estates

The default is not a policy

Plenty of UK small businesses have the same log-retention strategy: keep everything, because storage is cheap and deleting things feels risky. Then a client security questionnaire lands, or someone makes a subject access request, and the estate turns out to contain years of authentication logs, web access logs and application debug output that nobody has looked at since the server was built.

Logs are not automatically anonymous. An IP address, a username, an email address in a query string or a session token can all be personal data. UK GDPR expects you to have a purpose for processing it, to minimise what you keep and to delete it when you no longer need it. The ICO does not publish a magic number of days. It asks whether you can explain and evidence your choices. This is sysadmin guidance, not legal advice, but it is the sort of reasoning that survives an audit conversation.

Start with three questions

For every log source, ask what it is for, who needs it and what the minimum useful record looks like. Security logs need enough detail to investigate an incident. Debug logs need enough context to fix a bug. Web access logs might only need aggregate traffic counts, in which case raw IP addresses and full query strings are unnecessary.

Data minimisation is not about deleting everything on day one. It is about not collecting fields you never use. Turn off verbose debug logging in production. Stop logging request bodies, authorisation headers and password reset tokens. If you need to correlate events, a truncated IP address or a pseudonymous user ID may be enough.

A retention ladder that works

| Log type | Hot retention | Archive | Notes | | Authentication and sudo | 90 days | 12 months encrypted | Useful for incident review and access disputes | | Web access | 30 days raw | 90 days if security need | Aggregate stats can live longer | | Application debug | 7 to 14 days | Usually none | No tokens, bodies or personal data | | Financial transaction records | 6 years plus current year | Separate archive | Tax rules, not general logging |

Seven years is an accounting habit, not a sensible default for SSH logs. Seven days is often too short to catch a slow-burn compromise. For many small UK organisations, 90 days of authentication logs and 30 to 90 days of web logs is a defensible middle ground, provided you document why and actually delete the rest.

journald: cap it and rotate it

On systemd hosts, put limits in /etc/systemd/journald.conf rather than hoping nobody notices the disk filling up.

[Journal]
Storage=persistent
Compress=yes
SystemMaxUse=2G
SystemMaxFileSize=200M
MaxRetentionSec=90day

That keeps the journal bounded and expires old entries, but it is not a central archive. If an incident matters, ship logs off the box before local retention expires. systemd-journal-upload or rsyslog can forward to a small central log server, where you can apply a longer, more controlled retention period. Use journalctl --vacuum-time=90d if you need to reclaim space immediately, and remember that sealing the journal helps prove it has not been altered.

rsyslog: keep the useful, drop the noise

A central rsyslog server is still one of the best small-business tools for authentication logs. Keep the rules simple and avoid logging the same event three times.

auth,authpriv.*    /var/log/auth.log
*.*;auth,authpriv.none    -/var/log/syslog
& stop

Use a template that includes the hostname and date in the filename, then let logrotate or a retention script delete old files. If you forward web logs as well, strip query strings at the source where you can. The fewer personal data fields that reach the archive, the less you have to explain later.

logrotate patterns that do what you think

A common mistake is setting rotate 30 and assuming that means 30 days of logs. It means 30 rotated files, which is roughly a month if you rotate daily, but only if rotation actually happens. Add maxage to enforce a hard limit and test the configuration before it matters.

/var/log/nginx/*.log {
    daily
    rotate 30
    maxage 90
    missingok
    notifempty
    compress
    delaycompress
    sharedscripts
    postrotate
        [ -f /run/nginx.pid ] && kill -USR1 $(cat /run/nginx.pid)
    endscript
}

Run logrotate -d to see what it would do. Put the configuration in version control. If you use a central log server, apply retention there as well; otherwise you have only moved the hoarding problem.

Document it so it survives scrutiny

A retention schedule should fit on a page. List the log type, purpose, lawful basis, retention period, location, deletion method and owner. Review it annually and after any incident. Record that deletion actually happens, whether through a cron job, logrotate configuration or a scheduled archive purge.

When a client sends a security questionnaire, give them the policy summary and the date it was approved. Do not send raw logs. When a subject access request arrives, a shorter retention period reduces the search burden, but you still need to know where logs live. When the ICO asks, the question is likely to be about accountability: did you think about purpose, minimisation, retention and deletion? A documented, consistently applied policy is far stronger than a vague promise to keep everything forever.

The safest rule is not seven years or seven days. It is the shortest period that still lets you run the business, investigate incidents and meet your legal obligations, with the evidence to show you meant it.