When organizations prepare for the Digital Personal Data Protection Act, most attention goes to consent, notices, and security safeguards. These are important, but one of the most overlooked obligations sits quietly in the background.
Data retention under the DPDP Act
It does not create urgency like a breach or a regulatory notice. It does not feel immediate. Yet when something goes wrong, retention failures are often at the center of the problem. The reality is simple. The more data you keep, the more risk you carry.
Why Data Retention Is Not Just a Storage Problem?
Many teams treat retention as a storage or housekeeping activity. Old data gets archived. Backups keep growing. Systems continue to store information long after it is needed. However, under the DPDP Act, retention is not about where data is stored. It is about why it is still being stored.
Section 4 of the law makes this clear. Organizations should retain personal data only for as long as necessary for the purpose it was collected. Once that purpose is complete, the expectation is simple. The data should no longer exist, and this is where most organizations struggle.
Organizations continue to store data in backup systems and archives. It stays in tools that are no longer actively used. Over time, organizations lose visibility into how much personal data they actually hold.
The Hidden Risk of Keeping Data for Too Long
Retention failures rarely create immediate problems. Instead, they quietly expand risk over time. Every additional dataset increases the potential impact of a breach. When an incident occurs, regulators do not just ask how the breach happened. They ask a more uncomfortable question.
Why was this data still being stored? This is where retention shifts from being a technical issue to a compliance issue.
Our article DPDP Act and Security Safeguards: Why Section 8 Will Be the Most Enforced Part of the Law explains how regulators assess whether organizations took reasonable steps to protect data. Holding unnecessary data makes that justification much harder.
A Real Enforcement Case That Highlights the Risk
A strong example comes from the Information Commissioner’s Office enforcement action against Marriott International.
Marriott was fined £18.4 million following a data breach linked to the Starwood reservation system. One of the key issues regulators highlighted was that personal data had been retained in legacy systems for years without proper oversight. Even though the breach itself was serious, the retention aspect made the situation worse. Data that should have been reviewed or deleted remained in the system, increasing the scale and impact of the incident.
You can read the full enforcement summary here: Marriott Was Fined £18.4 Million For Failing To Keep Customers Personal Data Secure
The lesson is clear. Retention failures do not just increase risk. They amplify consequences.
Backups and Archives Are Part of the Problem
One of the most misunderstood areas of retention is backups. Organizations often assume that if data is stored in a backup system, it is outside normal compliance scope. In reality, backups still contain personal data and remain the organization’s responsibility.
If deletion policies do not extend to backups and archives, personal data can continue to exist indefinitely. This creates a gap between policy and reality. Organizations delete data on paper, but in practice, they still store it.
Why Retention Connects Directly to Data Minimization?
Data retention and data minimization are deeply connected. You cannot reduce data if you never delete it.
Our article Why DPDP Act Will Fail Without Purpose Limitation: The One Control Most Companies Ignore explains how unclear purposes already create compliance risk. Retention failures amplify that risk by allowing unnecessary data to remain.
Even when purpose is clearly defined, failing to enforce deletion breaks the entire control.
Operationalizing the Fix: Retention Schedules, Deletion Policies, and Backup Hygiene
So how do you stop this overlooked obligation from turning into a compliance risk? The answer lies in making retention practical and consistent.
Start by creating a clear retention schedule. For every type of personal data, define why it is collected, who owns it, and how long it should be stored. This should not be a static document. It should be reviewed regularly as systems and business needs evolve.
Next, move from policy to action by automating deletion wherever possible. Instead of relying on manual clean ups, systems should be designed to delete data once it reaches its defined retention period. This reduces human error and ensures consistency.
Backups and archives also need attention. Many organizations focus on deleting data from active systems but forget that the same data continues to exist in backup environments. Retention policies should apply equally to backups, with clear timelines for removal.
Finally, maintain proper records of deletion. Being able to show when and how data was deleted helps demonstrate accountability during audits or investigations. Documentation is often what separates a compliant organization from a non-compliant one.
These steps directly support Section 4 of the DPDP Act. When data is deleted on time, organizations hold less unnecessary information, reduce risk exposure, and strengthen their ability to demonstrate data minimization in practice.
A Simple Question That Often Gets Ignored
Retention failures do not happen because organizations do not care. They happen because no one is actively asking the right question.
Why are we still storing this data? If there is no clear answer, the data likely should not exist.
Final Thought
As organizations continue to grow their digital systems and adopt new technologies, the volume of personal data will only increase, and the real challenge is not collecting data. It is knowing when to let it go because under the DPDP Act, what you keep can matter just as much as what you collect.