The security questionnaire arrived at 4:14pm on a Friday. Question seven, under "Compliance": What is your log retention policy?
Somebody on the team suggested we write "it depends." Here is why that answer costs deals — and the one-page policy that fits a four-person team, keeps auditors happy, and survives the incident you'll actually have.
"It depends" is the answer that fails
An auditor, a enterprise buyer's security review, and a post-incident investigation all ask the same question: how long do you keep logs? Not "do you have a GRC platform." Not "is your logging centralized." Five numbers, recited from memory:
| Log type | Keep (hot) | Keep (cold/archive) |
|---|---|---|
| Auth / SSH / sudo | 90 days | 12 months |
| Web access logs | 30–90 days | Optional |
| Cloud audit trails | 90 days | 12 months |
| Application audit trail | 12 months | Per contract |
| Security events (failed logins, denies) | 12 months | 12 months |
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, the brute-force that started quietly three weeks ago is invisible. That's why the security tiers are measured in months.
Retention duration is meaningless if the logs can be wiped
Three properties beat 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, not edits. Object storage 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.
And the check that keeps the pipeline honest: a daily job verifying new log objects actually landed in the last 24h. The most common retention failure isn't a bad policy — it's a shipper that died three months ago and nobody noticed.
The never-log list (shorter than you think)
Everything you keep for a year is a year's worth of data for whoever gets the bucket:
- Passwords, API keys, tokens, session cookies. Run secret-scanning over your log buckets once — the first sweep almost always finds a key somebody printed in an error message.
- Full payment numbers. The processor's references and amounts, never card data.
- Personal data beyond what the question needs. Email + user ID is usually enough. Data you no longer hold can't leak — scheduled deletion is a privacy control too.
Enforce it with lifecycle rules, not memory
"We delete old logs manually" means you don't. Set expiry per bucket at the table's durations, then verify with one command: list the oldest object in each log bucket. If it's older than the tier allows, the lifecycle rule is off — fix the rule, not the object. Ten lines of script, weekly, from the same cron as your other heartbeats.
Deletion is not the enemy of an investigation — it's the enemy of a breach. A bucket with no expiry grows forever and multiplies the blast radius of every leak. The lifecycle rule is the security control.
Takeaways
- The policy is five numbers. Recite them; write the tooling next to each.
- Off-box and append-only beat "longer retention." Logs an attacker can wipe were never retained.
- Lifecycle rules + a weekly oldest-object check are the policy. If deletion depends on memory, the bucket and the blast radius both grow.
The full fillable version ships in the Ops Starter Kit ($14), and Vol. 2 ($27) adds the DR plan and evidence log that retention feeds during an incident. The complete note lives at HIVE80lab ops notes — and during launch week, 30% off any paid kit with code HIVE-LAUNCH30 at checkout (ends Sep 11, 23:30 ACST). The First 30 Minutes incident checklist is free.
Top comments (0)