NIST AU-11 (Audit Record Retention) requires that audit records be retained for a period consistent with the organization's data classification and applicable regulations. PCI-DSS Req 10.7.1 mandates a minimum one-year audit log retention. GDPR Art. 5(1)(e) requires that personal data not be kept longer than necessary for its purpose — meaning log retention also has a ceiling, not just a floor. Without a defined policy, teams either store logs indefinitely (accruing cost and compliance risk from retaining stale PII) or lose logs before an investigation needs them. A retention decision made during an incident is almost always wrong in one direction or the other.
Low because undefined retention causes cost overruns and compliance gaps, but the immediate security impact is indirect unless an investigation actively needs logs that were deleted.
Define log retention periods explicitly and configure them in your log service dashboard or as a scheduled cleanup job.
For log services, set retention in their settings UI: Better Stack dataset settings, Axiom dataset settings, or AWS CloudWatch log group retention.
Document the decision in docs/operations.md or your README:
## Log Retention
- Application logs: 90 days (Better Stack)
- Audit events table: indefinite until >10M rows, then archive to cold storage
- Retention rationale: PCI-DSS minimum 1 year for audit logs; 90 days sufficient for application logs
For audit log database tables, create a scheduled cleanup or archival job for records outside your retention window. If you're subject to PCI-DSS, the minimum for audit logs is 12 months with 3 months immediately available.
ID: saas-logging.audit-trail.log-retention-policy
Severity: low
What to look for: Enumerate all relevant files and Look for evidence that a log retention period is defined somewhere. Check: README or docs/ directory for operations documentation mentioning retention, database migrations or scripts that purge old log records after N days, environment variable like LOG_RETENTION_DAYS, log service configuration (Better Stack 30-day retention setting, CloudWatch retention rule, Axiom dataset retention), or a scheduled job/cron that archives or deletes old logs.
Pass criteria: At least 1 implementation must be present. A retention period for application logs (and audit logs if applicable) is defined in documentation, configuration, or code. The period is explicit, not implied.
Fail criteria: No evidence of a defined retention period anywhere. Logs are being written with no plan for how long to keep them.
Skip (N/A) when: No logging infrastructure exists (if both structured-logging and audit-log-sensitive-ops are failed/skipped).
Detail on fail: "No log retention policy found — no documentation, no log service retention setting, no scheduled cleanup job for application or audit logs"
Remediation: Without a defined retention policy, logs accumulate indefinitely (incurring cost) or are deleted too soon (losing evidence when you need it). Common standards: application logs 30-90 days, audit logs 1-7 years depending on compliance requirements.
For log services, set retention in the service dashboard (Better Stack: dataset settings, Axiom: dataset settings, CloudWatch: log group retention setting).
Document your decision in docs/operations.md or your README:
## Log Retention
- Application logs: 90 days (Better Stack)
- Audit events table: indefinite (purge strategy TBD when row count > 10M)