Storage is cheap. Unnecessary data is not.
The old default was simple: do not delete anything
For years, enterprise data strategy was shaped by a powerful assumption:
Data might become useful later.
Storage costs continued to fall. Analytics became more sophisticated. Historical information became valuable for reporting, forecasting and machine learning.
The result was predictable.
Organisations kept data.
Then they kept more data.
Backups accumulated. Shared drives expanded. Old databases remained online. Customer records survived long after relationships ended. Exports sat inside personal folders. Legacy applications continued to store information because nobody wanted to take the risk of deleting it.
What once looked like optionality now creates a different kind of risk.
Retention without purpose becomes data debt.
The DPDP framework changes the default question
The Digital Personal Data Protection Act, 2023 requires a Data Fiduciary to erase personal data upon withdrawal of consent or when it is reasonable to assume that the specified purpose is no longer being served, unless retention is necessary for compliance with law.
The notified DPDP Rules, 2025 add more specific erasure mechanics for certain large classes of e-commerce entities, online gaming intermediaries and social media intermediaries, including defined periods and advance notification before erasure in those cases.
The larger operational principle is important:
Retention should be explainable.
The organisation should know why personal data continues to exist.
Retention is not one number
One of the most common mistakes in privacy programmes is to ask:
How long should we keep customer data?
That question is too broad.
A customer record can contain different categories of data created for different purposes.
An invoice may need to be retained for one period.
A marketing preference may have a different lifecycle.
Support conversations may have another.
Identity-verification material may have another.
Security logs may have another.
The right unit of retention is therefore not simply 'the customer'.
It is the relationship between data, purpose, processing activity and applicable obligation.
A retention schedule should be executable
Many organisations already have retention policies.
The problem is that the policy and the systems are disconnected.
The policy may say:
Retain inactive customer data for X years.
But the system may not know:
- when the relevant period started;
- which records fall within the rule;
- whether a legal hold applies;
- whether another active purpose still exists;
- which downstream copies need to be removed; and
- whether deletion actually occurred.
A retention schedule becomes operational only when its rules can be translated into system actions.
Deletion is a distributed systems problem
Deleting one database row does not necessarily erase the personal data.
Copies may exist in:
- primary databases;
- analytics environments;
- search indexes;
- document repositories;
- data lakes;
- exports;
- archival systems;
- third-party processors; and
- backup environments.
Not every copy can or should be handled in exactly the same way. Backups, for example, may require controlled expiry rather than immediate surgical deletion.
This means retention design needs architecture.
The organisation must distinguish live processing environments, archives, immutable records, legal holds, processors and backups.
'Delete it' is a business instruction.
Engineering needs a deletion model.
Over-retention creates four kinds of debt
First, security debt.
Data that no longer needs to exist can still be exposed in a breach.
Second, privacy debt.
The organisation has to govern, respond to rights requests for and account for information it may no longer need.
Third, technology debt.
Old datasets, databases and integrations increase infrastructure complexity.
Fourth, AI debt.
Historical datasets can quietly become inputs into new analytics or AI use cases even when their original collection context has been forgotten.
Retention therefore affects far more than storage cost.
The better question is: what is the retention trigger?
Good retention governance is built around triggers.
Examples include:
- completion of a transaction;
- closure of an account;
- termination of employment;
- expiry of a contract;
- last interaction;
- withdrawal of consent;
- resolution of a dispute; or
- completion of a statutory period.
A trigger gives the organisation a starting point from which a retention rule can be calculated.
Without a trigger, 'retain for five years' is incomplete.
Five years from when?
From retention policy to retention intelligence
A mature privacy architecture should be able to connect:
This transforms retention from an annual policy exercise into an operational capability.
It also allows the organisation to make better decisions.
Instead of keeping everything because deletion feels risky, it can identify what must remain, what may remain and what should no longer remain.
That distinction matters.
The future of responsible data management is not simply collecting less.
It is knowing when the organisation has finished with the data it already collected.
'Keep everything' once felt safe.
In a privacy-led enterprise, knowing when to delete is the more mature strategy.
