Most organisations are far better at collecting data than at getting rid of it. The DPDP Act challenges that habit directly: it requires personal data to be kept no longer than necessary and erased when its purpose is done. Retention discipline is therefore not optional housekeeping but a genuine legal obligation.
This duty — sometimes called storage limitation — works hand in hand with purpose limitation. If you may only use data for the purpose you collected it, it follows that once that purpose is served, you should no longer be holding it.
Retention also has a powerful security dimension. Every record you no longer keep is a record that cannot be breached, mishandled or exposed, so disciplined deletion shrinks both your compliance risk and your attack surface at the same time.
This guide explains the retention and erasure duties under the Act, how the right to erasure interacts with them, the role of legal retention requirements, and how to build a retention schedule you can actually enforce.
The principle: keep data only as long as necessary
The Act requires that personal data not be retained beyond the period for which it is necessary for the specified purpose. Once the purpose for which data was collected is fulfilled, the default expectation is that the data should be erased.
This reverses the common corporate instinct to keep everything indefinitely 'just in case'. Under the Act, holding data without a current, justifiable purpose is itself a compliance problem, not a neutral default.
The principle pushes organisations to ask, for every dataset, a simple question: why are we still keeping this, and is that reason still valid? Where there is no good answer, the data should go.
A useful habit is to attach an expiry question to every new dataset at the point it is created: when will we no longer need this, and what happens then? Designing deletion in from the start is far easier than retrofitting it onto data that has accumulated for years.
Erasure when purpose is served or consent withdrawn
The duty to erase is triggered in two main ways: when the purpose for which the data was collected is no longer being served, and when the data principal withdraws the consent on which the processing relied.
In both cases the fiduciary must generally delete the personal data, and ensure its processors do the same, unless retention is required for compliance with a law. Erasure is not a favour granted on request; it is a standing obligation tied to purpose and consent.
This makes erasure an operational capability, not just a policy. Honouring withdrawal and purpose-end deletion across systems is a core part of dpdp compliance, and it must actually work in practice.
Because withdrawal and purpose-end can occur at any time, erasure cannot be a manual, occasional task. It needs to be an engineered capability that triggers reliably, propagating across systems rather than depending on someone remembering to run a deletion.
The right to erasure
Alongside the fiduciary's own duty to delete, data principals have a right to request erasure of their personal data. The two reinforce each other: even where the fiduciary has not yet acted, the individual can prompt deletion.
Honouring an erasure request means removing the data across all the places it lives — primary databases, backups, downstream tools and processor systems — not just the most visible copy. A deletion that leaves stale copies elsewhere does not truly satisfy the right.
Organisations therefore need the technical ability to locate and delete an individual's data comprehensively, which is far easier when underpinned by a good data map.
Handling erasure requests well is also a trust opportunity. A person who asks for their data to be deleted and receives prompt, complete confirmation experiences an organisation that respects their wishes — the opposite of one that clings to data it no longer needs.
When retention is legally required
The duty to erase is not absolute. Where another law requires personal data to be retained — tax records, certain financial or regulatory records, statutory limitation periods — the fiduciary may, and indeed must, keep it for that period.
The key is that legal retention is purpose-bound. You may keep the data for the legally required reason, but you cannot use that obligation as cover to repurpose the same data for unrelated commercial uses.
Documenting the specific legal basis for each retention period is what makes it defensible: 'we keep this for seven years because tax law requires it' is far stronger than a vague instinct to hold on.
Keep legal-retention categories clearly separated from general data, so that when a deletion runs, the legally required records are preserved and everything else is removed. Blurring the two leads either to unlawful retention or to accidental loss of required records.
Possible prescribed retention periods
The framework contemplates that specific retention periods may be prescribed for certain classes of fiduciaries or types of processing. Discussion around the Rules has, for example, considered defined retention limits for large consumer platforms after a user's last interaction.
Organisations in data-intensive consumer sectors should watch for such prescribed periods and be ready to implement automated deletion when a defined retention window expires.
Even absent a prescribed period, the safe default is to set your own reasoned retention limits per data category rather than defaulting to indefinite storage.
Where prescribed periods do emerge for your sector, automating deletion at the end of the window is the only scalable approach. Manual deletion at scale is error-prone, and missed deletions are exactly the kind of lapse a regulator can point to.
Building a retention schedule
The practical tool for all of this is a retention schedule: a documented list of your data categories, the purpose each serves, how long you keep it, the basis for that period, and what happens at the end. It turns an abstract principle into enforceable rules.
A good schedule is built from your data map and reviewed periodically. It assigns each category a defined retention period — tied either to purpose or to a legal requirement — and a deletion or anonymisation action when that period expires.
Crucially, the schedule must be operationalised, with systems configured to actually delete or flag data on time, rather than a document that describes deletions which never happen.
Free resource
The Ultimate Guide to the DPDP Act
A practical, plain-English handbook to the DPDP Act & 2025 Rules — scope, roles, consent, safeguards and a readiness path.
The technical challenge of deletion
Reliable deletion is harder than it sounds. Personal data scatters into backups, logs, caches, analytics pipelines and third-party systems, and a deletion that misses these leaves residual copies that quietly contradict your obligations.
Addressing this requires designing for deletion: knowing where each category of data flows, building the ability to remove it across that estate, and handling edge cases like backups that cannot be selectively edited.
Anonymisation is sometimes an alternative to deletion — but only if it is genuine and irreversible. Weak anonymisation that can be undone does not take data out of scope and does not satisfy the erasure duty.
Retention as risk reduction
Beyond compliance, retention discipline is one of the most effective forms of risk reduction available. A smaller data footprint is cheaper to store, easier to secure, and less damaging if breached — you cannot lose what you no longer hold.
It also simplifies every other obligation: less data to map, secure, and produce in response to rights requests. Organisations that embrace deletion find their whole compliance posture becomes lighter and more manageable.
Treating retention as a routine, scheduled, automated activity — rather than an afterthought — turns it from a neglected obligation into a quiet, ongoing source of resilience.
Free consultation
Need help getting DPDP-ready?
Talk to our compliance team — we’ll map your gaps against the Act and the 2025 Rules.