The Digital Personal Data Protection Act does something many Indian organisations have never had to operationalise before: it gives individuals enforceable rights over their own data, and it puts a clock on your response. A right you cannot fulfil within the window is not a compliance gap on paper — it is a live liability the moment someone exercises it.
This is a practical playbook for turning those rights into a workflow.
The rights you must be able to honour
Under the Act, a data principal can ask you to:
- Access — a summary of the personal data you hold about them and how it is being processed.
- Correct and complete — fix data that is inaccurate or incomplete.
- Erase — delete personal data that is no longer necessary for the purpose it was collected for.
- Grievance redressal — raise a complaint and get a response through a defined channel.
- Nominate — appoint someone to exercise these rights on their behalf in the event of death or incapacity.
Each of these looks simple in isolation. The difficulty is that the data they refer to is almost never in one place.
The clock starts when the request lands
The moment a request arrives, a statutory timer begins. Your systems need to answer three questions immediately:
- Is this really them? You cannot hand personal data to whoever asks. Identity verification has to be strong enough to be defensible, without becoming a barrier that itself breaches the right.
- Where does their data live? Across databases, SaaS tools, warehouses, backups and file shares.
- What is the deadline, and who owns it? A request with no owner is a request that quietly ages past its window.
A rights programme is only as good as its slowest system. The one database nobody remembers is the one that makes you miss the deadline.
Identity verification without friction
The failure modes here run in both directions. Verify too weakly and you risk disclosing one person's data to another — a breach in itself. Verify too aggressively and you obstruct a right the Act guarantees. The workable middle is risk-based verification: match the strength of the check to the sensitivity of the data being requested, and record exactly how identity was established so the decision is auditable later.
Orchestration is the hard part
Fulfilling a single access request often means fanning out to a dozen systems, collecting what each holds, and assembling it into one coherent package. Do this by hand and it takes days and produces inconsistent results. The systems that keep pace treat a rights request as an orchestrated job:
- A single intake point, so nothing arrives through a side channel and gets lost.
- Automated fan-out to every connected source, driven by the current data map — not by someone's memory of where data lives.
- A running timer visible to whoever owns the request.
- A complete record of what was collected, from where, and when it was sent.
Common failure modes
- The forgotten system. Data in a legacy tool or a spreadsheet no one re-mapped. If it is not on the map, it will not be searched.
- The manual handoff. A request emailed between teams, ageing at every hop.
- The unlogged fulfilment. You did the right thing but kept no evidence you did — which, when questioned, is nearly as bad as not doing it.
- Erasure without proof. Deleting data is not enough; you need a record that shows it was deleted, when, and from where.
A checklist to pressure-test your programme
- Is there a single intake path for every kind of rights request?
- Can you verify identity in a way you could defend to a regulator?
- Does fulfilment fan out automatically across every system on a current data map?
- Is there a visible timer and a named owner on every request?
- Do you keep an auditable record of what you did, for every request, including erasures?
If you can answer yes to all five, rights fulfilment is a routine operation. If you cannot, each incoming request is a scramble — and the clock does not care.
