By Ashok Kumar, Founder & MD, RAH Infotech
India’s Digital Personal Data Protection (DPDP) Act, 2023, has moved from statute-book theory to operational reality. With the DPDP Rules, 2025, notified by the Ministry of Electronics and Information Technology in November 2025, the country now has a firm, phased implementation timeline: foundational provisions and the formal establishment of the Data Protection Board of India took effect immediately; provisions relating to the Consent Manager framework come into force one year after publication; and most substantive obligations covering notice, consent, data principal rights, security safeguards, breach reporting, retention and cross-border transfers come into force 18 months after publication, by May 13, 2027. For enterprises, that phased timeline should not be mistaken for spare time. The technology and data remediation needed for compliance can take months.
For most large Indian enterprises like banks, insurers, telecom operators, PSUs, hospitals and government departments, the biggest obstacle to meeting this deadline won’t be legal interpretation. It will be technology. Specifically, it will be the legacy IT systems that quietly run the core of their business.
The legacy problem, in plain terms
Legacy systems are the mainframes, decades-old ERP installations, siloed departmental databases, and custom-built applications that many organisations still depend on for core operations. They were designed for a pre-privacy-regulation era, when the priorities were transaction processing and uptime, not data minimisation, consent tracking, or the ability to locate and erase a single individual’s data on demand.
The DPDP Act, however, is built around exactly those capabilities. It requires organisations to:
- Obtain and be able to demonstrate valid, purpose-specific consent where consent is the applicable basis for processing.
- Honour a data principal’s right to access, correction, and erasure of their personal data.
- Maintain appropriate logs, monitoring and records to provide visibility into access to personal data and support security and breach investigation.
- Report data breaches to the Board and affected individuals within prescribed timelines.
- Erase personal data when consent is withdrawn or the specified purpose is no longer being served, subject to applicable legal retention requirements.
- Support “Consent Manager” interoperability once that framework goes live.
Most legacy systems simply were not built to do any of this natively.
Why the gap is so hard to close
- Data is scattered, undocumented, and duplicated. Personal data collected over 15–20 years often lives across multiple legacy databases, flat files, and departmental silos with no unified data map. Before an organisation can honour an erasure or correction request, it first has to know every place a person’s data lives, a discovery exercise that can take months on old systems with poor documentation.
- No concept of purpose-linked consent. Legacy applications typically store data without tagging it to the specific purpose or consent under which it was collected. The DPDP Act, by contrast, treats consent as purpose-specific and revocable. Retrofitting that logic into an application built in the 1990s is rarely a simple configuration change; it may require changes across consent-management layers, integrations and, in some cases, core data models.
- Weak or absent audit trails. Rule 6 of the DPDP Rules requires appropriate logs, monitoring and review to provide visibility into access to personal data and enable the detection, investigation and remediation of unauthorised access. Many legacy systems log transactions for financial reconciliation but were never designed to provide this level of access visibility across personal-data processing environments.
- Hard-coded retention (or none at all). Legacy systems frequently retain data indefinitely because deleting it was never a design requirement and, in some cases, deletion is technically difficult because other downstream systems depend on that data remaining intact. The Act’s erasure and retention requirements, subject to other applicable legal obligations, run directly against this default-to-keep-everything architecture.
- Vendor and skills risk. A meaningful share of legacy estates run on platforms whose original vendors have been acquired, discontinued support, or simply moved on. Finding engineers who can safely modify a 20-year-old COBOL-based core banking module or integrate privacy and consent controls around it is a real operational constraint, not a hypothetical one.
- Data Processor contracts. Compliance responsibility rests with the data fiduciary even when a data processor handles the actual processing, and the rules now expect appropriate security clauses in fiduciary-processor agreements. Many legacy outsourcing and AMC contracts predate this expectation entirely and will need renegotiation.
- Cross-border and Significant Data Fiduciary Obligations. The Act allows the Central Government to restrict transfers of personal data to specified countries or territories, while the Rules also allow additional requirements to be imposed on certain cross-border data availability. Significant Data Fiduciaries may face further restrictions for personal data specified by the Government. Organisations with legacy infrastructure, backups or processing dependencies spread across jurisdictions will therefore need clear visibility into where their data resides and moves.
Why 2026 is the year this becomes urgent
For large enterprises, DPDP readiness is a multi-quarter programme rather than a last-mile compliance exercise. The Consent Manager framework becomes applicable one year after publication, while most substantive obligations and enforcement provisions take effect 18 months after publication, by May 13, 2027. Organisations that only begin legacy-system discovery in late 2026 will therefore be leaving themselves a narrow remediation window. Legacy remediation, unlike a policy update, cannot be compressed into a few weeks; it involves data discovery, schema changes, testing, and often parallel-running of systems to avoid business disruption.
The penalties raise the stakes further. Failure to implement reasonable security safeguards alone may attract a penalty of up to ₹250 crore, a figure that makes “we’ll fix the old system later” a very expensive strategy.
What organisations should be doing now
- Run a data discovery and mapping exercise across legacy systems to build an enterprise-level inventory of personal data, processing purposes and data flows before deciding on tooling.
- Layer data-centric controls, including tokenisation, encryption, access governance, and logging, around legacy systems where re-architecting the core is not feasible in the available time.
- Review legacy personal data collected before commencement, identify the purpose and basis on which it is being processed, meet applicable notice requirements, and determine whether continued retention remains necessary or justified.
- Renegotiate data processor and AMC contracts to include DPDP-aligned security and breach-notification clauses.
- Prioritise by risk, not by system age: the systems holding the most sensitive or highest-volume personal data should be remediated first, regardless of how old or how modern they are.
Legacy IT systems were built for a different regulatory era. The DPDP Act doesn’t require organisations to rip them out, but it does require them to make these systems behave in ways they were never designed for: discoverable, consent-aware, auditable, and capable of forgetting.
For large enterprises, DPDP compliance is therefore not only a policy or legal exercise. It is also a data architecture, cybersecurity and operational challenge. Closing that gap is a multi-quarter engineering effort, not a documentation exercise, which is exactly why it deserves attention well before the compliance clock runs out.