Log Retention Policy for Small Teams

Nobody writes a retention policy until an audit, a customer security questionnaire, or an incident investigation asks “how long do you keep logs?” — and “it depends” is the answer that fails. The fix is small: tiered durations per log type, logs that land somewhere an attacker can't wipe, a short never-log list, and lifecycle rules that delete on schedule so nobody has to remember.

1. The one question the policy has to answer

A retention policy is not a document — it's five numbers you can recite: how long you keep auth logs, access logs, cloud audit logs, application logs, and security events. When the auditor asks, you answer with the numbers. When an incident needs last month's SSH sessions, you check the numbers and the logs are actually there. Everything else in the policy exists to make those two sentences true.

The tier that matters most is the one you'll regret losing: investigations almost always want the window before the alert. If you keep 7 days, a brute-force that started quietly 3 weeks ago is invisible. That's why the security tiers below are measured in months, not days.

2. The tier table: what to keep and how long

Log type	Keep (hot)	Keep (cold/archive)	Why
Auth & SSH & sudo	90 days	12 months	Investigations reach back months; the “who logged in” trail is the first thing an auditor asks for
Web/access logs	30–90 days	Optional	Traffic debugging and abuse investigation; old access logs rarely pay for their storage
Cloud audit trails (admin actions)	90 days hot	12 months	“Who changed this setting?” has a 6-month half-life and a long tail
Application audit trail (who did what)	12 months	Per contract	Support disputes and customer questions age slowly
Security events (failed logins, firewall denies)	12 months	12 months	Pattern evidence for incidents; the tier you set first if you only fix one

Two rules make the table stick. One: the tier table is the policy — write it on one page with the tooling next to each row. Two: cold storage is a bucket, not a project — an export to cheap object storage once a day beats a “we should centralise logging” plan you never finish.

3. Where logs must land to count

Retention duration is meaningless if the logs can be destroyed by the thing you're investigating. Three properties matter more than any number in the table:

Off-box: logs ship to storage that isn't the server that produced them. If the only copy of your auth log is on the compromised host, your retention policy is decoration.
Append-only: the destination accepts writes but not edits or deletes — an object-storage bucket with versioning and delete permissions revoked for the log shipper is the two-minute version.
Clock-synced: every host runs NTP. A timeline built from logs with drifting clocks wastes the hours you don't have during an incident.

And the check that keeps the pipeline honest: a daily job that verifies new log objects actually landed in the last 24h, and pages you when they didn't. The most common retention failure isn't a bad policy — it's a shipper that died three months ago and nobody noticed. This is the same pattern as the cron heartbeat check: test that the thing that watches is itself alive.

4. The never-log list (shorter than you think)

Retention turns logs into a liability surface: everything you keep for a year is a year's worth of data for whoever gets the bucket. So the policy also says what must never be written:

Passwords, API keys, tokens, session cookies. Run secret-scanning over your log buckets once — the first sweep almost always finds a key someone printed in an error message. (See the secrets rotation checklist for what to do about the ones you find.)
Full payment numbers. The payment processor's references and amounts, never card data. If you can't answer “why do we store this field?”, the field shouldn't be in the log.
Personal data beyond what the question needs. Email + user ID is usually enough; keep the log useful and the privacy exposure boring. Deleting on schedule (Section 5) is also your privacy answer — data you no longer hold can't leak.

5. Enforce it with lifecycle rules, not memory

“We delete old logs manually” means you don't. Every object store and log service has a lifecycle/expiry setting; the policy is one page of those settings plus one command that verifies them:

Set expiry per bucket/service: hot tier buckets expire at the table's hot duration; the archive bucket expires at 12 months.
Verify with one command: for each log bucket, list the oldest object. If the oldest object is older than the tier allows, the lifecycle rule is off — fix the rule, not the object. Ten lines of script, run it weekly from the same cron as the heartbeat.
Re-check after every migration: the logging vendor change is where old retention settings get silently lost. Make the one-command check part of the quarterly restore-test ritual — different failure mode, same discipline.

Deletion is not the enemy of an investigation — it's the enemy of a breach. A log bucket with no expiry grows forever, costs more every quarter, and multiplies the blast radius of every leak. The lifecycle rule is the security control.

Takeaways

The policy is five numbers. Auth 90d/12mo, access 30–90d, cloud audit 90d/12mo, app audit 12mo, security events 12mo. Write them on one page with the tooling next to each.
Off-box and append-only beat “longer retention.” Logs an attacker can wipe were never retained; logs with a drifted clock waste the incident window.
Lifecycle rules + a weekly oldest-object check are the policy. If deletion depends on someone remembering, the bucket grows and the blast radius grows with it.

---

The Ops Starter Kit ($14) turns log retention from a document nobody reads into a fillable one-pager your team can recite, and Vol. 2 ($27) adds the DR plan and evidence log that retention feeds during an incident. Launch week: 30% off any paid kit with code HIVE-LAUNCH30 at checkout (ends Sep 11, 23:30 ACST).