Data Retention and Deletion Checklist
- Work top-down: ownership first, then systems, then evidence.
- Check “claimed deletion” against backups, analytics, and vendor exports.
- Do not file the checklist without a named review date.
- Link failures to tickets; avoid checkbox theater.
See also: Compliance portal · Official resources · Guides index
Retention problems usually come from neglect, not intent. Businesses keep data too long because nobody owns cleanup, nobody trusts deletion, or nobody can even list all the systems involved.
Checklist
- Inventory systems of record. List every store of personal data: production DBs, warehouses, CRM, ticketing, email archives, file shares, device backups, and vendor dashboards.
- Define retention rationale by category. For each material category, document business, legal, tax, or fraud drivers—or admit “unset” explicitly.
- Align policy text with clocks. Privacy notices and DPAs promise timelines your automation or runbooks can meet.
- Deletion vs deactivation. Clarify whether accounts are soft-deleted, anonymised, or hard-deleted—and what remains in logs.
- Backups and snapshots. Document whether restored backups resurrect deleted principals; define expiry or re-deletion passes.
- Analytics and downstream copies. Check BI tools, event streams, CSV exports, and partner feeds for stale personal data.
- Support and CRM trails. Tickets, voice logs, attachments, and macros often retain identifiers—review retention there explicitly.
- Marketing automation. Suppression lists, reactivation rules, and consent withdrawal must not re-add deleted users.
- Vendor SLAs. Confirm subprocessors delete or return data on termination within contractually defined windows.
- Authorisation model. Identify which roles may approve extended retention, legal hold, or emergency overrides—document audit trail expectations.
- Rights request linkage. Deletion requests traverse the same inventory this checklist builds; rehearse one quarterly (deletion guide).
- Manual clean-up debt. Flag systems needing human intervention so “partially automated” is not mistaken for “done.”
The two retention rules that actually have numbers
Most retention periods in DPDP are left to business judgment within “no longer than the specified purpose requires” (Section 8(7)), but two schedules set hard figures — and both are narrower than people assume:
- Third Schedule (Rule 8(1)): a 3-year retention clock applies only to e-commerce entities with 2+ crore registered users in India, online gaming intermediaries with 50+ lakh users, and social media intermediaries with 2+ crore users — not to every business, and only after the user stops engaging with the account.
- Rule 6(1)(e) and Rule 8(3) (for the purposes listed in the Seventh Schedule): a general 1-year minimum retention for security logs and traffic data tied to breach detection and investigation, which applies more broadly than the Third Schedule figure above.
Rule 8(2) also requires a 48-hour advance notice to the Data Principal before scheduled erasure runs, so she has a last chance to re-engage if she wants to keep the data.
Where teams get surprised
- Support systems and ticket archives
- CRM and lifecycle tools
- Analytics platforms and data warehouses
- Exports, spreadsheets, and downloaded reports
- Third-party tools retaining copies longer than expected
Operational follow-up
Once the business knows where deletion actually breaks, it can create a more realistic retention schedule, rights workflow, and vendor review process instead of relying on vague policy language.