How to write a data retention & deletion policy (with a schedule)

At a glance

A retention policy fails as a writing exercise and works as an inventory exercise: before any template helps, you need to know what personal data you hold, where, for what purpose, and which laws force you to keep any of it. From there the policy nearly writes itself — one schedule row per data type, a duration or trigger for each, a named law for anything held longer, and a deletion method that includes your processors and your backups. The thinking is the audit; the writing is an afternoon.

Educational resource only. This explains how to work out a data retention and deletion policy under India’s Digital Personal Data Protection Act, 2023 (DPDP Act) and its Rules; it is not formal legal advice.

The situation

The DPDP Act’s retention rule is easy to state — erase personal data once its purpose is served or consent is withdrawn, unless a law requires you to keep it — and nearly impossible to follow without writing things down. Which purposes? Whose law? Which systems? The policy is where those answers live; this is how to get them.

Why this is an inventory problem, not a writing problem

You can’t schedule the deletion of data you haven’t listed. The Act ties retention to purpose (Section 8): data lives as long as its purpose does, plus whatever a specific law adds. That means the real inputs to your policy are an inventory — every category of personal data you hold and where it sits — and a purpose map connecting each category to why you have it. Businesses that skip this write aspirational policies (“data is deleted when no longer required”) that name no data, no trigger and no owner: compliant-sounding, operationally empty. If you already maintain a record of your processing activities, the inventory is done — the retention schedule is one more column on it.

What goes wrong without a written schedule

Keep-everything is now a liability with a penalty attached, and it fails in both directions. Data kept past its purpose is exposure: a breach of ten years of ex-customer records is ten years of liability where two would have done, and “we never delete anything” reads as a security-obligations failure, not thoroughness. But undocumented deletion fails too: purge tax records a statute required you to hold and the data protection problem becomes a tax problem. The schedule is what holds both edges — every row keeps data exactly as long as something (purpose or law) justifies, and its “legal basis” column is your answer if the Data Protection Board of India ever asks why you still held what leaked.

Step by step: from data audit to a living policy

Audit, map, schedule, mechanise, assign, review.

1. Inventory every category of personal data you hold, system by system. Production databases, document stores, spreadsheets, email, chat exports, CCTV, your processors — walk the systems, not your memory of them.
2. Tie each category to its purpose. Data with no nameable purpose is your first deletion list, not a schedule row.
3. Overlay the legal holds. For each category, ask whether a specific law requires retention — tax records, KYC and anti-money-laundering rules, sectoral record mandates, the DPDP Rules’ own log-retention requirement. Name the law per row; “compliance” isn’t a law.
4. Set a period or trigger per row. Prefer triggers (account closure + 30 days, decision + 90 days) over dates; prefer honesty over ambition — a 30-day promise your systems can’t keep is worse than a 90-day one they can.

Use the template

Data retention & deletion policy template — the full policy structure with the per-type schedule, backup handling, exceptions log and review cadence. Your audit’s output drops straight into its rows.

5. Define what deletion physically means, per row — hard delete, purge from the document store, irreversible anonymisation — and extend it to your processors: their copies are your responsibility, and your agreements need to make deletion enforceable.
6. Handle backups honestly. Deleted data lingers in backups until the cycle expires — state the cycle, exclude backups from active use, and re-delete on any restore. A policy that ignores backups is fiction; one that promises instant backup erasure is fiction with confidence.
7. Assign an owner and a review cadence. Someone’s role owns the schedule; it’s reviewed on a fixed interval and on every change to what you collect. And wire the schedule into your erasure-request handling — a deletion request is just an early trigger for rows consent was holding open.

Mistakes that quietly break a retention policy

These are the gaps that surface in a breach or an audit, not in the drafting:

• The policy with no schedule — principles stated, no data named, no dates: unenforceable and unprovable.
• “As long as necessary” — undefined necessity is indefinite retention with better wording.
• Forgetting the informal stores — the spreadsheet exports, the shared-drive folders, the inbox attachments; breaches love the copies the schedule never covered.
• Processors left out — deletion that stops at your own database while your vendors keep their copies.
• Deleting what the law required you to keep — the overcorrection; the legal-basis column exists to prevent it.
• A schedule nobody owns — retention is a running process, not a document; without an owner and a review date, the policy describes the past.

FAQ