Updated: July 14, 2026
DPDP compliance is mostly proven in infrastructure, not in policy documents.
Its security and rights duties require you to find, secure, recover and delete personal data across the whole estate.
Residency, access control, encryption, breach detection and tested recovery are all DPDP infrastructure requirements.
Substantive obligations take effect May 13, 2027. Treat 2026 as the build year, not the reading year.
The DPDP summary lands in your inbox from Legal. It is tidy, thorough, and, the subject line implies, mostly handled now.
That is the first mistake.
A policy document can describe how you will comply. It cannot make you compliant. Most of what the Digital Personal Data Protection Act actually demands is not written; it is built into the way your data is stored, secured, located, recovered and deleted. Which means the real owner of DPDP compliance is not only the legal team. It is whoever runs the infrastructure. And the clock, substantive obligations from 13 May 2027, is running on them.
The law sets the obligations. The infrastructure meets them, or fails to.
Consider what happens when a data principal exercises their right to have their data corrected or erased. Legal can write that you will honour the request. But honouring it means actually finding every copy of that person's data, across databases, backups, logs and applications, and changing or deleting it. That is not a clause. That is a capability, and most estates do not have it yet.
The same is true almost everywhere DPDP touches. The obligation is legal; the proof is technical. When the Data Protection Board asks how you secured the data, or how quickly you detected a breach, or where the data resides, the answer lives in your infrastructure, not your policy folder.
Here is the translation most summaries skip: what each obligation actually requires you to build.
| DPDP Obligation | Infrastructure You Need |
|---|---|
| Reasonable security safeguards | Access control, segmentation, encryption |
| Breach notification | Monitoring, detection and complete logging |
| Rights to access, correct, erase | Data discovery, cataloguing, the ability to find and act on an individual's data |
| Storage limitation | Retention and automated deletion |
| Cross-border and residency rules | Residency architecture; in-India infrastructure for restricted data |
| Significant Data Fiduciary duties | Data-protection impact assessments, audit, possible localisation |
Read the right-hand column, and the point is unmistakable. This is a build programme, not a memo. Every row is a capability someone has to stand up and operate.
Start here, because it is the requirement that most often exposes how much work remains.
DPDP gives individuals the right to access, correct and erase their personal data. To honour those rights, you have to know where every copy of a given person's data lives, and be able to act on it. In a typical enterprise, that data is scattered, spread across production databases, analytics stores, backups, log files and third-party applications, often with no single map.
If you cannot answer "where is all of this person's data?" today, you cannot honour the right tomorrow. Data discovery and cataloguing, unglamorous, foundational, is where a serious DPDP programme usually begins.
Residency is the requirement everyone has heard of, and the one most often misunderstood.
DPDP does not impose blanket localisation. It uses a negative-list approach: personal data may be transferred abroad except to countries the government restricts. But that permissive default is qualified. Sector rules, such as the RBI's already localise payment data. Significant Data Fiduciaries can face localisation of notified categories. And the government can tighten restrictions at any time.
So the prudent infrastructure posture is not "everything must stay in India", nor "anything goes". It is residency by design: sensitive and likely-restricted data placed on infrastructure where you can prove it stays in-country, and the flexibility to keep the rest wherever makes sense until the rules say otherwise.
DPDP requires reasonable security safeguards and breach notification. Both are architecture.
"Reasonable safeguards" means access control that limits who can reach personal data, segmentation that contains a compromise, and encryption that protects data at rest and in transit. Breach notification means you can actually detect a breach, and reconstruct what happened, which requires monitoring and comprehensive, tamper-resistant logging. You cannot notify the Board of a breach you never detected, and you cannot describe its scope without the logs.
These are not new ideas to a good security team. What DPDP does is make them a legal obligation with a deadline and put the burden of proof on you.
Availability and integrity of personal data are part of protecting it, and that puts tested recovery inside the DPDP conversation.
A ransomware attack that encrypts or corrupts personal data is a data-protection failure as much as a security one. Being able to recover that data, cleanly, from immutable backups, into a clean environment, within a sensible time, is part of safeguarding it. Recovery you have proven, not just designed, belongs in the compliance programme, not beside it.
If your organisation handles personal data at scale, there is an additional tier to plan for.
Significant Data Fiduciaries, designated by the government based on the volume and sensitivity of data they handle, carry heavier duties: periodic data-protection impact assessments, independent audits, and the standing possibility of localisation for certain notified data. Assessing early whether you are likely to be designated an SDF matters, because it changes both your obligations and your residency architecture. It is far cheaper to design for it than to retrofit it after a designation.
Treat 2026 as the build year, because the programme is longer than it looks.
Map your personal data and where it flows. Classify it by sensitivity and regulatory exposure. Architect residency for the sensitive and restricted classes. Put in place the access control, segmentation, encryption, monitoring and logging that "reasonable safeguards" and breach notification require. Build the ability to find, export, correct and delete an individual's data, and to enforce retention and deletion. Prove your recovery. And if you may be an SDF, plan for the audits and impact assessments now.
That is not a legal checklist. It is an infrastructure roadmap, and it does not complete itself in a quarter.
The gap between a DPDP policy and DPDP compliance is filled with infrastructure work, data mapping, residency, controls, rights-fulfilment, recovery, and it is work best done by people who build and operate this for a living.
Proactive Data Systems designs and builds DPDP-aligned data center and data-protection infrastructure for Indian enterprises, with residency, security, recovery and governance built in. We are a Cisco Preferred Cloud and AI Partner, Dell Platinum Partner and NetApp Preferred Partner, with 35 years in enterprise IT, more than 1,500 organisations served, and a 24/7 service desk in India. To turn a DPDP policy into infrastructure that proves it, you can ask Proactive for a DPDP-readiness assessment, alongside your legal team.
Disclaimer: This article translates DPDP obligations into infrastructure implications for general guidance. It is not legal advice, and the law and its rules continue to evolve. Confirm your specific obligations, and any Significant Data Fiduciary designation, with qualified legal counsel, and treat this as a complement to legal advice, not a substitute for it.
Amitabh Mishra AGM, Cybersecurity, Proactive Data Systems
We'll get back to you shortly.
