What DPDP means for your data

India's Digital Personal Data Protection Act, 2023 changed the basis on which organisations handle personal data. Most of the commentary about it concerns legal obligations. This is about the other half: what actually has to be true of your systems for those obligations to be met.

This describes the shape of the obligations and the technical controls that support them. It is not legal advice, and the implementing rules and timelines have been issued in stages, so confirm the current position for your sector and circumstances before acting.

The vocabulary, briefly

The Act uses terms that map onto roles you already have.

• Data Principal: the individual the data is about.
• Data Fiduciary: whoever determines why and how personal data is processed. If you decide what happens to the data, this is you.
• Data Processor: whoever processes it on a Fiduciary's behalf. Your cloud providers and SaaS vendors are usually here.
• Significant Data Fiduciary: a designation the government may apply based on volume and sensitivity of data and other factors, carrying additional obligations including a Data Protection Officer based in India, independent audit, and impact assessments.

The Act covers digital personal data processed in India, and also processing outside India where it relates to offering goods or services to individuals in India.

The obligations, and what each requires technically

Processing on a lawful basis, with notice

Processing generally requires consent, obtained with a clear notice describing what data is collected and for what purpose. The Act also provides for certain legitimate uses where consent is not the basis: the individual having voluntarily provided the data for that purpose, employment-related purposes, and specified state or emergency situations among them.

What this needs from your systems: a record of what basis applies to each processing activity, and for consent, a record of what was consented to, when, and against what notice text. Consent that cannot be evidenced is difficult to rely on. Notice text changes over time, so the version matters.

Purpose limitation, and erasure when the purpose ends

Data collected for a purpose should be used for that purpose, and erased when the purpose is served or consent is withdrawn, unless retention is required by law.

What this needs: a retention schedule that is actually implemented rather than documented. This is the obligation most organisations are furthest from meeting, because deletion is rarely built. It requires knowing where every copy is (including backups, non-production environments, analytics extracts and ticketing systems) and having a mechanism to remove them.

Consent withdrawal has to actually propagate. If withdrawal stops future processing but leaves the data in five downstream systems, the obligation is not met.

Responding to individuals

Individuals can request a summary of the personal data being processed and the activities involved, seek correction or completion, seek erasure, and use a grievance mechanism. The Act also provides for nomination, allowing an individual to nominate someone to exercise their rights.

What this needs: the ability to find all data relating to one person, across systems, within a defined time. Organisations that have never had to do this usually discover it takes days of manual work across a dozen systems. The fix is knowing your data map well enough to query it, which is discovery work rather than legal work.

Reasonable security safeguards

The Act requires reasonable security safeguards to prevent personal data breaches. It does not enumerate them, which means the standard is judged against what is reasonable for your context.

What this needs: the controls you would expect: access control on a least-privilege basis, encryption in transit and at rest, logging of access to personal data, patching, and monitoring. What matters for the obligation is being able to evidence that these were in place and operating, not just configured.

Breach notification

Personal data breaches must be notified to the Data Protection Board and to affected Data Principals.

What this needs: detection capable of noticing a breach, an incident process that identifies affected individuals and what data was involved, and contact details current enough to reach them. The scoping question, exactly whose data was affected, is the hard part, and it depends on logging that records access to personal data at a level of detail most organisations do not currently keep.

Children's data

Processing personal data of children requires verifiable consent from a parent or lawful guardian, and tracking, behavioural monitoring and targeted advertising directed at children are restricted.

What this needs: an age determination mechanism and a consent flow that works for guardians. If your service is not intended for children but might attract them, this needs a considered position rather than an assumption.

Processors and contracts

A Data Fiduciary engaging a Processor must do so under a valid contract, and remains responsible for compliance.

What this needs: a current inventory of every third party that touches personal data, including the SaaS tools adopted by individual departments, with contracts that address the obligation. The shadow inventory is usually larger than the official one.

Where organisations are typically furthest behind

In practice, three gaps come up repeatedly.

Deletion has never been built. Systems are designed to store, not to remove. Implementing retention and erasure properly is a genuine engineering project, and it is the one most often underestimated.

Nobody knows where the copies are. The data map covers the primary systems and misses the extracts, the reporting environments, the test databases restored from production, and the exports sitting on shared drives.

Consent is captured but not managed. A tick box at signup, with no record of the notice version, no propagation of withdrawal, and no way to demonstrate what a given individual agreed to.

A sensible order of work

1. Map the data. What personal data you hold, where, why, and who it goes to. Everything else depends on this and it is usually the longest task.
2. Establish the basis for each processing activity, and fix the notice and consent capture where consent is the basis.
3. Build the retention and erasure capability. Start with the primary systems and the highest-volume data.
4. Make individual requests answerable in a defined time without a manual scramble.
5. Close the security gaps the mapping exercise revealed, particularly around non-production copies.
6. Get the third-party inventory and contracts current.
7. Test the breach process, specifically the part where you determine who was affected.

The first step is the one that makes the rest possible, and it is the one most often skipped in favour of drafting policies. A policy describing how you handle personal data is not worth much until you know where it is.