Two conversations that should be one
In most organisations, data retention comes up twice a year in two entirely separate rooms.
In the first, legal and compliance discuss obligations, policies and what the regulator expects. The output is a document. In the second, IT and finance discuss storage, licensing and why the estate keeps growing. The output is a budget line.
The two rooms are talking about the same records, and neither conversation reaches the system where those records actually live.
What DPDP changes
India's Digital Personal Data Protection Act moves retention from good practice toward obligation. The principle underneath it is straightforward: personal data should be kept for as long as it is needed for the purpose it was collected for, and not indefinitely by default.
Enforcement is being phased in rather than switched on, which has given organisations time and, in many cases, has also given them a reason to defer. The deadlines are not distant any more, and the penalties are significant enough that the calculation has changed.
For an SAP estate this matters more than for most systems, because SAP is usually where the personal data with the longest tail lives: employee records, customer master data, vendor contacts, and transactional history attached to all three.
Why "keep everything" stopped being safe
The traditional default in enterprise IT was to keep everything, on the reasoning that storage is cheap and deleting something you later need is worse than holding something you do not.
Two things have undermined that. The first is that storage is not cheap when it sits in memory, and an SAP estate keeps a great deal of it in the most expensive tier available. The second is that under a regime like DPDP, holding personal data past its purpose is itself an exposure. The default position changed from neutral to slightly negative, and most estates have not noticed.
The gap between policy and system
Almost every organisation we look at has a retention policy. Very few have retention rules implemented in SAP.
The distinction matters because a policy that is not enforced by the system is a statement of intent. Under scrutiny, the question is not what your policy says but what your system does, and the answer is usually that it keeps everything indefinitely because nobody configured it to do otherwise.
Closing that gap is what information lifecycle management is for. Retention periods attached to object types, legal holds that suspend destruction for records under dispute, and a defensible, logged process at the end of the period. It is not glamorous work and it converts a document into a system behaviour.
The part that makes it easy to fund
Compliance projects are hard to fund because the return is the absence of a bad outcome. This one is unusual, because the same work produces a measurable cost reduction.
Records that should be destroyed under a retention rule are, by definition, records that are occupying licensed memory for no business reason. Implementing retention reduces the estate. Reducing the estate reduces the licence position, the infrastructure and, if it happens before a migration, the migration itself.
That makes it one of the few compliance conversations that can be presented to a CFO as a cost case with a compliance benefit attached, rather than the other way around.
Where to start
Three questions, in order. Which objects in your SAP estate hold personal data. What retention period applies to each under your own policy and under DPDP. Which of those rules are actually implemented in the system today.
The third answer is usually close to none, and finding that out is quick. It is also the answer you would rather discover yourself than have someone else discover for you.
This article describes how retention and lifecycle management work inside an SAP estate. It is not legal advice, and the specific obligations that apply to your organisation should be confirmed with your legal advisors.