At a glanceThis is a free, ready-to-fill internal policy that answers the question the DPDP Act keeps asking: why do you still have this data? Its core is a per-data-type schedule (each row naming the data, its purpose, how long you keep it, the legal basis if you keep it longer, and how it actually gets deleted), wrapped in the rules that make the schedule real: deletion mechanics, backup handling, ownership and review. Fill the brackets and add one row per data type.
Educational resource only. This provides a template for a data retention and deletion policy in line with India’s Digital Personal Data Protection Act, 2023 (DPDP Act) and its Rules; it is not formal legal advice, and you should have it reviewed against your own data and sector before you rely on it.
The situation
Every business keeps data “just in case,” and the DPDP Act ends that habit: personal data must go once its purpose is served, unless a law says otherwise. But “delete when done” only becomes operational when someone writes down what you hold, why, until when, and how it dies. That’s a retention policy, and starting from a blank page is why most businesses don’t have one.
What this template is (and when you need it)
A retention policy is the written answer to “why do you still have this?”: per data type, with dates. The DPDP Act requires erasure once consent is withdrawn or the purpose is served, whichever is earlier, unless retention is necessary for compliance with a law (Section 8). A written schedule is how that duty becomes something your team can actually run, and it’s what you’d show the Data Protection Board if retention were ever questioned. Every business handling personal data needs one; if you’re in a Third Schedule class (very large e-commerce, social media or online gaming platforms), specific time-bound erasure rules apply on top, and your schedule is where they get recorded. Separately, DPDP’s own Rules set a floor of their own: processing logs and traffic data must be retained for at least one year from the date of processing, for law-and-order, state-function and regulatory-assessment purposes, regardless of your own schedule or an erasure request.
The template: copy and fill in
Copy everything below, replace the bracketed fields, and add one schedule row per data type you hold.
Data Retention & Deletion Policy
[Your Business Name], version [number], effective [date]. Owner: [role].
1. Purpose. This policy states how long we retain each category of personal data, why, and how it is deleted. Personal data is erased once its purpose is served or consent is withdrawn (whichever is earlier) unless a law requires us to retain it.
2. Retention schedule.
| Data type | Purpose | Retention period / trigger | Legal basis if held longer | Deletion method |
|---|---|---|---|---|
| [Data type] | [Purpose] | [Retention period / trigger] | [Legal basis if held longer] | [Deletion method] |
3. Deletion mechanics. Deletion means removal from production systems within [timeframe] of the trigger, and from our Data Processors’ systems per our agreements with them. Backups are excluded from active use and expire on our backup cycle of [cycle length]; restored data older than its retention trigger is re-deleted on restoration.
4. Withdrawal and erasure requests. A consent withdrawal or valid erasure request triggers deletion per this schedule, except rows held under a legal basis, in which case we inform the person what is retained and under which law.
5. Exceptions. Any retention beyond this schedule requires [role]'s written approval, a named legal basis, and an entry in the exceptions log.
6. Review. This policy and schedule are reviewed every [interval] and on any change to what we collect, our processors, or applicable law.
How to fill it in
The schedule rows carry the policy: get each row honest, and the rest is housekeeping.
[Your Business Name]
- What it means: Your business’s name, as it should appear at the top of your official policy document.
- Examples: “Acme Consulting Pvt Ltd.”
[number]
- What it means: This version’s number, so anyone reading it knows whether they have the current copy.
- Examples: “1.0”; “2.1.”
[date]
- What it means: The date this version of the policy takes effect.
- Examples: “12 Aug 2026.”
[role]
- What it means: Whoever owns this policy and approves any exception to it, named by role so it survives staff changes.
- Examples: “Data Protection Officer”; “Head of Operations.”
[Data type], [Purpose]
- What it means: One row per category you actually hold, tied to the purpose it was collected for. Walk your systems; don’t write from memory.
- Examples: Customer contacts, KYC documents, transaction records, support tickets, CCTV footage, employee records.
[Retention period / trigger]
- What it means: A duration or an event, not “as long as necessary.” Triggers beat dates where the purpose is open-ended.
- Examples: “Account closure + 30 days”; “loan decision + 90 days”; “end of financial year + 8 years (statutory).”
[Legal basis if held longer]
- What it means: The specific law requiring the longer hold: tax, KYC/anti-money-laundering, sectoral record rules. Blank means the purpose alone decides; a filled cell must name the law, not “compliance.”
- Examples: “Income-tax record retention”; “RBI KYC record requirements”; “our sector’s log-retention rule”; “DPDP’s own one-year log-retention floor (Rule 8(3)).”
[Deletion method]
- What it means: What deletion physically is, per row: the cell that turns policy into practice.
- Examples: “Hard delete from database”; “document store purge + processor deletion per DPA”; “anonymisation (irreversible).”
[timeframe]
- What it means: How long deletion can take from the trigger before it counts as done, so “deleted” has an actual deadline behind it.
- Examples: “30 days”; “7 working days.”
[cycle length] - backups
- What it means: Deleted data lingers in backups until the cycle turns over; stating the cycle makes that honest and bounded, and the re-deletion-on-restore line closes the loop.
- Examples: “35 days”; “90 days for cold backups.”
[interval]
- What it means: How often you formally review the whole schedule, not just when something forces the question.
- Examples: “Annually”; “every 12 months.”
What this template doesn’t cover
It’s the retention layer, not your whole data governance, and it isn’t legal advice. It doesn’t decide your lawful basis for collection (consent or legitimate use), doesn’t cover the notice and consent capture that happen before retention starts, and doesn’t replace sector rules: a bank, hospital or broker has retention mandates this template can only point at, not contain. If you’re in a Third Schedule class, the specific erasure timelines and the 48-hour pre-deletion notice apply as law, not policy choice. Have the finished schedule reviewed against your sector before you rely on it.
FAQ
Is “as long as necessary” an acceptable retention period?
No. It’s the phrase this policy exists to replace. Every row needs a duration or a concrete trigger; “necessary” undefined is how data gets kept forever.
What about data in backups?
State your backup cycle and let deleted data expire with it (that’s the honest, workable pattern), and re-delete anything past its trigger if a backup is restored. A policy that pretends backups delete instantly won’t survive contact with your own infrastructure.
Can we keep data the customer asked us to delete?
Only what a law requires you to keep, and you should tell them what that is and under which law. Everything else goes; an erasure request doesn’t negotiate with “just in case.”
How often should the schedule be reviewed?
On a fixed interval (annually at minimum) and on every change to what you collect or who processes it. A schedule that doesn’t match your current systems is documentation of a policy you don’t actually have.