You have a deadline, a dozen systems to check and no idea where that person appears in any of them. This is the one place that runs it.
It rarely arrives as a formal request. It arrives as a message somebody has to recognise.
A former patient wants a copy of everything you hold, and asks the front desk for it.
A user emails support saying “delete my account and all my data”, and support closes the ticket.
A rejected candidate asks what you still have on file six months after the interview.
No jargon for a moment. Here is the thing that actually lands in someone’s inbox, and why it is not an ordinary support ticket.
A customer, a patient, an employee or a student writes and asks what personal data you hold about them — or asks you to correct it, or to delete it. Under India’s Digital Personal Data Protection Act, that is not a favour you may grant. It is a right they can enforce, and you have a limited time to answer.
The Act calls that person a Data Principal and calls you the Data Fiduciary. The industry calls the request a DSR — a data subject request. Same thing, three names.
The hard part is almost never the law. It is that the person exists in your CRM, your billing system, your helpdesk, two spreadsheets and a vendor’s database, and somebody now has to find all of it, decide what may lawfully be deleted, and prove afterwards that they did.
This is the whole list. Anything else a vendor offers you is another country’s law wearing an Indian label.
“What do you hold about me, what is it used for, and who else have you given it to?” You answer with a summary a person can read, not a database export.
“My address is out of date and my name is spelled wrong.” Correcting it in one system is not enough — it has to reach everywhere that copy travelled.
“I have finished with you. Remove what you hold.” The right reaches what you processed on consent, and even there not where a law requires you to keep it.
“If I die or cannot act for myself, this named person may exercise these rights instead.” A nomination hands someone else standing over the whole record.
“You handled this badly.” The only one with a deadline written into the Rules — ninety days to put it right, under Rule 14(3), before they can go to the Board.
Data portability is not a right under the DPDP Act — that is GDPR Article 20, and it did not survive into India’s law. Any India tool selling it as a DPDP right is selling you someone else’s statute.
Five steps, and only two of them need a human decision. The rest is bookkeeping that should never have been anybody’s job.
However it arrived — the public rights page, a link you sent, your own app, or an email your front desk typed in by hand — it becomes one request in one queue. Nobody has to remember which inbox this kind of thing lives in.
From the date it arrived, not the date somebody noticed. The due date is calculated, the traffic light goes green, and reminders are scheduled. No spreadsheet, and nothing to remember to start.
A code goes to the phone or email already on your records — never to one typed into the request. How hard this step is depends on what they asked for, which is the part most tools get wrong.
Your CRM owner, your billing owner, your helpdesk owner each get one task for their system and nothing else. They tick what they did. They never log into anything new, and they never see the whole request.
The person is told what was done, and what could not be done and why. Everything that happened is already recorded — you do not assemble evidence afterwards, because it was being written the whole time.
A rights request touches more of the organisation than anyone expects. Each of them needs something different from it.
One list, worst deadline first, across every open request. You see what is late, what is close and what is waiting on somebody else — without chasing five teams around the building to find out.
You log it in one short form and you are done. You never have to decide whether it is an access request or a grievance, and you cannot start the clock late — the date it arrived is what counts.
One task for your system, by a signed link good for seven days. Confirm what you did or say why you could not. No new account, no training, and no sight of any other system’s data.
When a deletion is refused, the ground is recorded against the provision it rests on — out of scope, or retention required by law — not as a free-text note somebody typed. The timeline behind it cannot be edited afterwards, including by us.
One question — is anything overdue — answered from the same records the team works in, so the number on your slide is the number in the system rather than one retyped last week.
Rights requests are not the only clock running. They sit beside breach obligations, vendor gaps and retention duties, sorted by what bites first.
Statutory deadlines outrank internal ones, and what is already overdue sits above what is merely due soon — whichever module it came from. The order on screen is the order to work in.
The list is the status. It is worked out from the underlying records every time it loads, so it cannot quietly drift away from what is actually true the way a tracked spreadsheet does.
Each line opens the request, the breach or the vendor sitting behind it. This is a way into the work, not a report you read in one place and then go and act on in another.
The rights queue itself: what was asked, how it arrived, whether identity is settled, and how long is left.
That is the worst possible moment to be inventing one. See the queue, the identity ladder and a refused erasure on a live tenant instead.
Handing someone’s records to an impostor is a data breach you caused yourself. So the check gets harder as the request gets more dangerous.
A “correction” that changes the phone number on file is really an attempt to take over the account. So the code goes to the old number, never the new one. A stolen link cannot be walked up into control.
A flurry of requests, a child, a documentary claim — each can raise the check. Nothing lowers it automatically. Relaxing a check that has already been set takes two named people, on the record.
Ask to see your data and delete it in the same message, and you are checked once, at the stricter of the two. No repeating yourself — and no quietly answering the easy half at the easy bar.
The code is six digits with three attempts, a four-minute life and a ten-minute lockout — and the attempts are counted per person across every open request in a rolling fifteen minutes, so asking for a fresh code does not buy fresh guesses.
Most tools let the clock pause while someone “awaits information”. That is how a thirty-day promise quietly becomes ninety.
Not from when it was triaged, assigned or understood. A date entered by hand has to be in the past, so nothing can be back-dated to buy time or forward-dated to hide a late one.
Not for the person being slow to reply, and not for your team being busy. The only thing ever excluded is an outage on our side, because our servers failing is not your contravention.
The Act sets no deadline for an access, correction, erasure or nomination request. It sets ninety days for complaints, under Rule 14(3), and that one is separate and immovable. Thirty days is our default for the rest, and you can set it anywhere from seven to forty-five.
A single extension to a hard ninety-day ceiling, needing a stated reason and a notice to the person. Reminders at day seven and fourteen. A request left waiting on the person for thirty days running closes honestly as lapsed, rather than sitting open forever.
A tool that deletes whatever it is told to delete is not compliant. It is obedient — and the Act does not ask for obedience.
One person proposes the deletion and a different person approves it. Approving your own is refused, and so is an approval with nobody named as proposer. One compromised account cannot destroy a record.
Approval moves the record into a reversible quarantine — seven days by default, never less than twenty-four hours. Anyone can stop it inside that window. Only afterwards does anything become permanent.
Where a named law requires you to keep the data, the request comes back refused with grounds — or partly done, where some systems could act and others could not. The person is told which, and why.
Tax rules, clinical record rules, an open dispute — all are checked before anything is queued, by the same engine that governs automatic retention, so the two can never disagree about what is lawful to delete.
A public page with no account, no password and no app — because putting a login in front of a legal right is not a neutral choice.
Identifiers are stored as one-way hashes, so what a request is matched against is never the raw value.
The Board will not ask whether you have a process. It will ask what you did about one named person, on one particular date.
Every step of every request is added to a timeline the database itself refuses to change or delete. Not a rule the team follows — a constraint that rejects the attempt, including ours.
Per request: what was asked, the full timeline, each system’s task and outcome, the identity checks and the confirmations. Every part fingerprinted, and one fingerprint over the whole thing.
Producing that summary writes its fingerprint back into the timeline that cannot be edited. Anyone can recompute it later and see whether the evidence still matches what was recorded.
The packaged ZIP download is not live yet — it needs file storage we have not provisioned. The summary and its tamper-evident anchor need no such thing and work today.
Someone whose personal data you hold — a customer, patient, employee or student — asking you to show it to them, correct it, delete it, let someone act for them, or complain about how you handled it. India’s DPDP Act calls that person a Data Principal and calls you the Data Fiduciary. The industry calls the request a DSR, or data subject request. They all mean the same thing: a request you are legally obliged to answer, not a favour you choose to grant.
For access, correction, erasure and nomination, the Act sets no fixed period. What the Rules do fix is ninety days to redress a grievance, under Rule 14(3). Be careful of any tool advertising a “30-day DPDP deadline” — thirty days is a sensible operating target and it is our default, but it is a setting in a seven-to-forty-five day band, not a duty in the statute. Presenting the two as the same thing leaves you defending a promise nobody asked you to make.
Five: access to information about processing (§11), correction and completion (§12), erasure (§12(3)), grievance redressal (§13) and nomination (§14). Data portability is not among them — that is Article 20 of the GDPR, and it did not carry over into India’s Act. A platform offering portability as a DPDP right is either selling a GDPR product with the country name changed, or has not read the statute.
No, and that is deliberate. Whoever takes the call fills in one short form — who asked, when, and what they said. They do not have to decide whether it is an access request or a grievance, or which sections apply. The clock runs from the date it arrived, so a request sitting unread for two days has already used two days, and logging it late does not hide that.
No. A system owner gets one task for their system by a signed link that works for seven days, confirms what they did or explains why they could not, and that is the whole interaction. They never sign into a new tool, never see the rest of the request, and never see another system’s data. The people who actually have to act are usually the ones with no appetite for another login.
By making the check match the danger. Complaining needs nothing extra, because Rule 14(3) means complaining must stay easy. Viewing data through a link you sent is proved by the link. Viewing data from a public form needs a code sent to the contact already on your records — never to one typed into the request. Changing or deleting data, and naming someone to act for the person, sit at the strictest tier. And a “correction” that changes the contact details is challenged against the old ones, so a stolen link cannot be walked up into control of the account.
The request comes back refused with grounds, or partly done where some systems could act and others could not, and the person is told which and why. There are two separate grounds here and running them together is a common mistake. The first is scope: §12(1) gives the right of correction and erasure over personal data for the processing of which the person previously gave consent, including consent under §7(a) — so an employment record processed under §7(i) sits outside that right rather than being excused from it. The second is retention: even where the right does attach, §12(3) does not require erasure where a law requires you to keep the data. Note that §11 access is not confined the same way, so “we cannot delete it” is never an answer to “show me what you hold”. A tool that deletes whatever it is told to will eventually destroy something a statute required you to keep — and the audit trail will show you chose that tool.
Inside the holding window, yes. An approved deletion sits in a reversible quarantine — seven days by default and never less than twenty-four hours — during which anyone can stop it. Only after the window closes does anything become permanent. Approval needs two different people to begin with; approving your own proposal is refused.
A per-request summary: what was asked, the full timeline that cannot be edited, every system’s task and outcome, the identity checks and the confirmations — each part fingerprinted with one fingerprint over the whole, and that fingerprint written back into the unchangeable log so it can be shown to be untampered. It contains no personal data. The packaged ZIP download is still waiting on file storage we have not provisioned; the summary and the anchor work today.
Real client quotes, attributed by role and sector — we never name a client.
Working across
The command centre, the queue, an identity check that escalates, and a deletion that comes back refused with grounds — on real screens rather than slides.
Thank you — we have it. Someone will reply by email, usually within one working day.
Nothing else is needed from you. If it is urgent, email tushar@ruleexpert.com and it will reach the same people.
RuleExpert