ASVS 5.0 V14.2.7 is a Level 3 requirement. Sensitive information must have a retention classification, and outdated or unnecessary data must be deleted automatically, on a defined schedule, or when circumstances require.
Why it matters
Old data keeps its risk and loses its value. Every extra year of stored records is an extra year of breach exposure. Retention also matters for privacy obligations, where keeping data longer than needed can itself be a problem.
How to implement it
Record the retention period next to the data classification, then enforce it with a job.
-- Retention: password reset tokens 24 hours, sessions 30 days, support attachments 1 year
DELETE FROM password_reset_tokens WHERE created_at < now() - interval '24 hours';
DELETE FROM sessions WHERE last_seen < now() - interval '30 days';
# Run daily and alert when it fails
0 3 * * * /usr/local/bin/retention-job --report /var/log/retention.json
Cover copies as well: search indexes, caches, analytics exports and backups. Backups can follow a shorter expiry policy instead of selective deletion. Log how many records each run removed.
How to test it
Insert test records with timestamps older than the limit, run the job, and confirm they are gone from the database, search index and exports. Also check that the job has run recently by reading its report.
Common mistakes
- A policy with no job behind it.
- Deleting from the main table but not replicas, caches or file storage.
- A silent failing job nobody monitors.
Quick check
Do backups need deletion on the same schedule?
They need a defined expiry that fits the policy. Selective deletion inside backups is rarely practical, so short backup lifetimes are the usual approach.
