The DPDP Act for Indian businesses: what IT actually has to change

The Digital Personal Data Protection Act, 2023 applies to organisations processing the personal data of people in India. Most coverage of it has been legal. This is the operational version: what actually has to change in your systems, and in what order.

What the Act asks of you

Stripped of the legal framing, the obligations that translate into IT work are these. You must know what personal data you hold and why. You must limit its use to the purpose it was collected for. You must apply reasonable security safeguards. You must be able to respond when someone asks what you hold about them, or asks you to delete it. And you must be able to notify a breach.

Every one of those is easy to state and hard to do if you have never mapped your data. That is why the first piece of work is almost never a technical control.

Start by finding the data

Most businesses cannot answer where personal data lives. It is in the CRM, obviously. It is also in spreadsheets on individual laptops, in shared mailboxes, in a folder called Old HR on a file server, in a form-submission inbox nobody reads, and in a backup taken in 2021 that nobody has thought about since.

A data map does not have to be elaborate. A list of systems, what personal data each holds, who can reach it, and how long it is kept covers most of what you need. In Microsoft 365, content search and sensitivity labelling will find a large proportion of it faster than asking people.

The controls that matter most

Once you know where the data is, the safeguards worth prioritising are consistent across almost every business we audit.

Named accounts, not shared logins. This is the single most common gap, particularly at reception desks, in clinics and at retail counters. A shared login means you cannot say who accessed a record, which defeats both your audit trail and your ability to investigate a complaint.

Multi-factor authentication everywhere. Including on accounts people think are unimportant. Compromised credentials remain the most common route into a business.

Encryption on endpoints and backups. A lost laptop with an unencrypted drive is a reportable event. An encrypted one usually is not.

Access reviews on a schedule. Not because the Act names a frequency, but because access sprawl is how data ends up somewhere you did not intend. Quarterly is a reasonable default.

Retention that actually deletes. Keeping everything forever is the opposite of purpose limitation, and it enlarges every breach you might ever have.

Responding to a request

If someone asks what you hold about them, you need to find it across every system, not just the obvious one. This is where the data map pays for itself, and where businesses without one discover the problem the hard way, with a clock running.

Practically, this means knowing which systems can be searched, who can run the search, and how a response is assembled and recorded. Rehearse it once before you need it. The first attempt is always slower than anyone expects.

Breach response

You cannot notify what you cannot detect, and you cannot describe what you cannot reconstruct. That makes logging the foundation of breach response rather than an afterthought. Centralised, time-synchronised logs with sensible retention are what turn an incident from a guess into a timeline.

Agree the escalation path in advance: who decides it is a breach, who notifies, who talks to customers. Deciding that during an incident wastes the hours that matter most.

A realistic order of work

Map the data. Remove shared logins. Turn on multi-factor authentication. Verify encryption rather than assuming it. Centralise logging. Set retention. Rehearse a request and a breach. Most businesses can do the first four in a few weeks, and they cover a large share of the practical risk.

What we would avoid is buying a compliance platform before doing any of that. Tooling helps once you know what you hold. It does not tell you what you hold.

Where this sits with other obligations

DPDP is not the only thing asking these questions. CERT-In directions cover incident reporting and log retention. Sector regulators add their own expectations, particularly in financial services. The useful news is that the underlying controls overlap heavily, so work done for one satisfies much of another. Build once, evidence many times.