Denshin / Blog / Process
DPDP Rules: what product teams actually have to change before May 2027
The DPDP Rules were notified in November 2025 and most obligations apply from May 2027. How notices, consent records, breach reporting, retention and vendor contracts turn into engineering tickets, and a rough seven month plan.
Denshin Team · Product & Engineering · 12 October 2026 · 5 min read
India's Digital Personal Data Protection Rules were notified on 13 November 2025. For most of the year since, the conversation has happened among lawyers. That is changing, because the dates are now close enough that the work lands on engineering teams, and a lot of it is the unglamorous kind: finding where personal data actually lives, writing deletion jobs, keeping logs nobody reads until something goes wrong.
This is the version we walk clients through. It is not legal advice. Read the gazette text with your counsel; what follows is how the obligations turn into tickets.
The dates
- 13 November 2025: Rules notified. The provisions setting up the Data Protection Board took effect straight away.
- Around 13 November 2026: consent manager registration and obligations begin, one year after notification.
- Around 13 May 2027: the bulk of the obligations on businesses apply, 18 months after notification. Notices, consent, security safeguards, breach reporting, retention and erasure, children's data.
Eighteen months sounded generous in November 2025. As of October 2026 there are about seven left, and if your product has a few years of data sitting in places nobody has mapped, seven months is not much.
Start with an inventory, not a policy
Every compliance effort we have seen go well started with a boring spreadsheet: what personal data we hold, where, why, who can read it, and when it gets deleted. Rows for the obvious places, like the users table and the CRM, and for the less obvious ones: application logs that print request bodies, the S3 bucket of uploaded ID documents, the analytics tool, the support inbox, the CSV someone exported in 2024 and emailed to a vendor.
The logs are usually the surprise. A request logger that dumps full payloads will quietly write phone numbers, addresses and sometimes OTPs into CloudWatch, where the default retention is forever (we covered that setting in the small AWS charges post). Fix the logger before you write the privacy notice.
Notices and consent are product work
The Rules expect a notice that makes sense on its own, in clear and plain language, listing the personal data and the specific purpose, with a way to withdraw consent that is as easy as giving it. People can also ask for the notice in English or any language in the Eighth Schedule of the Constitution, which matters if your users mostly read Marathi or Tamil. In practice that becomes:
- A notice per purpose, shown where the data is collected, rather than a link to a 4,000 word privacy policy.
- Separate consent for separate purposes. "We use your number for delivery updates" and "we use your number for offers" are two checkboxes, not one.
- A consent record: who, which notice version, which purposes, when, from which screen. Append only, like a ledger.
- A withdrawal option in account settings, and the work it triggers downstream: stop the marketing sends, tell the vendors who hold a copy.
The consent record is the piece teams skip. When someone asks whether a person agreed to something, the answer has to come from data, not from a screenshot of the signup form as it looked last year.
Security safeguards and access logs
The safeguards listed in the Rules are fairly ordinary: encryption, masking or tokenisation, access control, visibility into who accessed what, backups, and the ability to detect and deal with unauthorised access. One specific requirement stands out: logs and the data needed to investigate an incident have to be kept for at least a year, unless another law says otherwise.
For most of the web apps we build, that means encryption at rest switched on (it usually already is), role based access in the admin panel instead of one shared admin login, an audit trail of who viewed or exported records, and access logs kept for a year or more. Note the tension with the logging point above. You want access logs kept for a year. You do not want those logs to be full of the personal data itself.
Breaches come with a clock
When there is a personal data breach, affected people have to be told without delay, in plain language: what happened, the likely consequences, and what they can do about it. The Data Protection Board gets an intimation without delay and a detailed report within 72 hours of you becoming aware. Penalties for failing to notify go up to Rs 200 crore. For failing to take reasonable security safeguards, up to Rs 250 crore.
Seventy-two hours is short when the first question is "which users were affected" and answering it needs a developer to write a query against production. Write that runbook now. Who decides it is a breach, who drafts the notices, which queries produce the affected list, how the emails go out in bulk. Then rehearse it once, on a quiet afternoon, with a made-up incident.
Retention and erasure
Personal data should not outlive its purpose. Large e-commerce, gaming and social media platforms above set user counts get a fixed rule in the Rules: erase after three years of inactivity, with 48 hours' notice to the person first. Everyone else still has the principle to follow. Engineering wise, this is a scheduled job per data category, a definition of "inactive" that someone in the business has signed off, and deletion that actually reaches backups, search indexes, analytics exports and vendors. Deleting the row in the main table is the easy ten percent.
Children
If people under 18 can use your product, you need verifiable consent from a parent before processing their data, and no tracking, behavioural monitoring or targeted advertising aimed at them. If your signup never asks for age, decide whether it should. Ed-tech and gaming products feel this one most.
Vendors are still your problem
Every processor you hand personal data to acts on your behalf, and the obligation stays with you. That covers the email provider, the SMS gateway, hosting, analytics, and the AI API you send support tickets to. List them, get contracts that cover security and deletion, and check that "delete this user" actually propagates. Sending customer documents to a hosted model is a decision about processing personal data and deserves the same review as any other vendor, a point we also made in AI for Indian SMEs.
Seven months, roughly
- November: the inventory, and fix the loggers that write personal data.
- December and January: notices, consent records, the withdrawal flow.
- February and March: deletion jobs, the access audit trail, admin roles.
- April: breach runbook and rehearsal, vendor contracts.
- Early May: buffer. There will be something you missed.
None of this needs a new platform. Most of it is hygiene a good product should already have, now with a deadline attached. Dates, thresholds and penalties above are as of October 2026; check the notified Rules and any later amendments with your legal advisor before relying on them.
Tags: DPDP, Data Protection, Compliance, India, Privacy
All posts · Work with Denshin