Data retention policy
A written rule for how long each kind of data lives before deletion, plus the job that actually deletes it.
See it
What it is
A retention policy answers one question per data type: how long do we keep it, and what happens at the end. Logs 30 days, then purge. Deleted accounts 30 days in soft delete, then hard delete. Invoices for as long as your tax authority demands. Treat all three as illustrations rather than rules: the real numbers come from the tax, accounting, limitation-of-claims, and sector regulations that apply where you operate, and they differ by country (invoice retention runs six years in some places and ten in others). The principle behind it (GDPR calls it storage limitation) is that you may keep personal data only as long as the purpose you collected it for still needs it.
Write it as a table, not prose: data type, where it lives, retention period, legal or business reason, deletion method, owner. That table is what you paste into your privacy policy, what an enterprise security questionnaire is fishing for, and what tells you which cron jobs to build. Backups get their own row with an honest answer like 'purged with the backup rotation, up to 35 days later'.
Gotcha: a policy nobody automated is a liability, not a defence. Writing '90 days' and keeping five years of rows means you have documented, in your own words, that you are out of compliance. Also watch the places deletion does not reach: analytics warehouses, third-party tools, CSV exports in someone's Drive, and old snapshots.
Ask AI for it
Write a data retention policy for this product as a table with columns: data category, systems it lives in, retention period, justification (legal requirement or business need), deletion method, and owner. Cover account records, user-generated content, support tickets, application and access logs, analytics events, marketing contacts, payment and invoice records, and backups. Split the periods into two kinds and keep them visually separate: mandatory retention, derived only from the jurisdictions and legal obligations I supply, and proposed operational defaults, which are our choice and clearly labelled as such. Where a legal period is required but I have not told you the jurisdiction or the obligation, write a bracketed TODO instead of a number. Do not invent statutory periods. Then list the scheduled jobs and database changes needed to actually enforce every row, including soft delete followed by hard delete.