India's DPDP Rules: The Engineering Work Due by May 2027

India notified the Digital Personal Data Protection Rules, 2025 on 13 November 2025, as G.S.R. 846(E). Most of the rules that touch your product are not in force yet. Rule 1(4) says rules 3, 5 to 16, 22 and 23 "shall come into force eighteen months after the date of publication of this Gazette". Count eighteen months and you land on 13 May 2027, a little over seven months from today.

Those cover notices, security, breach intimation, retention and erasure, children's data and rights requests. Rule 4, which lets Consent Managers register with the Data Protection Board, comes earlier: one year after publication, so around 13 November 2026. The government's announcement calls it an 18-month phased timeline.

This is for CTOs and product heads at Indian consumer apps, fintechs, edtechs and e-commerce companies, and at foreign companies with Indian users. The Act reaches processing outside India when it is "in connection with any activity related to offering of goods or services to Data Principals within the territory of India" (section 3(b)). What follows is the software you have to build or change. It is not a legal gap assessment: whether you are in scope, which exemptions apply and how your purposes are worded are questions for counsel.

Who Actually Has Build Work

If all your customer data sits in one packaged SaaS platform, much of the plumbing (encryption, access logs, deletion jobs) comes from the vendor's roadmap. Your work is notices, configuration and contracts. Read those contracts: rule 6(1)(f) wants security safeguards written into them, and an illustration to rule 8 makes you responsible for your cloud provider keeping data and logs for the required year.

The heavy work falls on companies that run their own apps and databases, feed a warehouse from a dozen pipelines and ship third-party SDKs in the mobile client. That is most of the Indian consumer internet.

What Each Rule Asks of Your Software

Notice (rule 3)

The notice must be "understandable independently of any other information" you publish. At minimum it gives "an itemised description of such personal data", the specified purpose, and a specific description of the goods, services or uses the processing enables. It must also say how to withdraw consent, exercise rights and complain to the Board.

In practice:

• Render notices from a data inventory. Field by field, mapped to purposes. "We may collect information such as" is not itemised.
• Version every notice. Each consent record has to point at the exact text the user saw.
• Plan for languages. Section 6(3) of the Act requires the option to read a consent request in English or any language in the Eighth Schedule to the Constitution. Keep notice content as translatable strings, not a PDF.
• Cover existing users. Section 5(2) requires a notice, "as soon as it is reasonably practicable", to people who consented before the Act commenced. That is a campaign to your whole user base.

Consent, withdrawal and Consent Managers

Consent under section 6 must be specific and limited to the data the purpose needs. Section 6(10) puts the burden of proof on you: in a dispute, you show that notice was given and consent obtained. That sentence is why you need a consent ledger rather than a boolean column.

A workable ledger records, per user and purpose: notice version, timestamp, channel (web, app, Consent Manager) and action (given or withdrawn). Append only.

Withdrawal has to be as easy as giving consent (rule 3(c)(i), section 6(4)). If consent was one tap during onboarding, withdrawal cannot be an email to support. It also has to travel. Section 6(6) requires you to cease processing, and cause your Data Processors to cease, within a reasonable time. So the consent service publishes withdrawal events to every system and vendor acting on that purpose: CRM, marketing platform, analytics pipeline.

A Consent Manager is a registered single point of contact through which a user can "give, manage, review or withdraw her consent" (section 6(7)). Under the First Schedule it must be a company incorporated in India with a net worth of at least two crore rupees, its platform must be independently certified against standards the Board publishes, it must not be able to read the data it routes, and it keeps consent records for at least seven years.

The rules leave that standard to the Board. Build an inbound path now, so a consent or withdrawal arriving from an external platform is handled exactly like one from your own UI, and commit to a wire format only once the Board publishes one. Registration opens around 13 November 2026, so integration realistically starts in early 2027.

Security safeguards and logs (rule 6)

The minimum list: encryption, obfuscation, masking or tokenisation; access control on the systems involved; "visibility on the accessing of such personal data, through appropriate logs, monitoring and review"; backups so processing can continue after an incident; and retention of "such logs and personal data for a period of one year".

The logging requirement is where most systems fall short. Infrastructure logs do not tell you who read which customer's record from which service, and you need that answer a year later. So: application-level access logging on every personal data store, shipped somewhere services cannot alter, kept at least a year. Start early; rolling it out across many services takes longer than any single feature here.

Breach intimation (rule 7)

On becoming aware of a breach, you tell each affected user "without delay", through the user account or a registered contact channel: what happened, the likely consequences for them, what you are doing, what they can do, and who to contact. The Board gets a description without delay, then within 72 hours a detailed report on causes, mitigation, any findings about who caused it, remedial measures and the user intimations sent. The Board can allow longer on a written request.

In software: a way to compute the affected set (which depends on the access logs above), templates written in advance, a notification path that does not run through the breached system, and a runbook naming who files with the Board.

Erasure and retention (rule 8)

Section 8(7) requires erasure when consent is withdrawn or the purpose is no longer served, unless another law requires retention. Rule 8 adds two things.

First, three Third Schedule classes face a deemed end of purpose after three years without contact: e-commerce entities with at least two crore registered users in India, online gaming intermediaries with at least fifty lakh, and social media intermediaries with at least two crore. Account access and stored-value tokens are excepted. You must warn the user at least 48 hours before erasure, and a login cancels it. That is an inactivity tracker, a scheduler and a notification job. The three years run from the last contact or the commencement of the Rules, whichever is later, so no deletion is due for years, but the tracking must be right from the start.

Second, rule 8(3) sets a floor: personal data, traffic data and processing logs are kept for at least one year from the processing. The rule's illustration is an e-book order whose details must survive account deletion. So "delete my account" cannot mean DELETE FROM users. It means: stop processing, move what must be kept into a restricted store with a retention date, and erase it when the date passes. Every table needs a retention class, and so does every copy in backups, the warehouse and your processors' systems.

Rights requests and contact details (rules 9 and 14)

Users can ask for a summary of their data and processing and the identities of every fiduciary and processor you shared it with (section 11), ask for correction, completion, updating or erasure (section 12), and nominate someone to act for them on death or incapacity (section 14). Rule 14 requires you to publish how to make a request and which identifier you need, and to answer grievances within a published period of no more than ninety days. Rule 9 requires the contact details of your Data Protection Officer, or of someone who can answer, in every response.

To build: in-app request intake, identity verification tied to the account, a case tracker running the ninety-day clock, an export that finds a user's data across services, and a sharing register so "who did you share it with" is a query rather than an investigation.

Children and persons with disabilities (rules 10 to 12)

Under the Act a child is anyone under eighteen. Before processing a child's data you need the verifiable consent of a parent, and rule 10 requires checking that the parent is an identifiable adult. The check can use identity and age details you already hold for a registered parent, details the parent provides, or "a virtual token mapped to such details" from an authorised entity, which includes a Digital Locker service provider. MeitY's DigiLocker publishes requester APIs for organisations that fetch verified documents; have counsel confirm which sources satisfy the rule for your flows.

Section 9(3) bans tracking, behavioural monitoring and targeted advertising directed at children. For a consumer app that is an SDK problem, and the safe default is to switch analytics and ad SDKs off for any account flagged as a minor rather than configure them into compliance.

Rule 11 covers lawful guardians of persons with disabilities: you verify that the guardian was appointed by a court, a designated authority or a local level committee. That is a document upload and a manual review queue.

Rule 12 and the Fourth Schedule exempt some processing from the parental consent requirement and the tracking ban, among them healthcare, educational institutions (for educational activities and safety), real-time location for safety, and confirming that a user is not a child. An edtech should not assume it counts as an "educational institution". Get that answered in writing.

Significant Data Fiduciaries (rule 13)

If the government notifies you as a Significant Data Fiduciary, rule 13 adds an annual Data Protection Impact Assessment and audit with a report to the Board, due diligence that your algorithmic software does not put users' rights at risk, and keeping any personal data the government specifies inside India. Section 10 of the Act adds a Data Protection Officer based in India and an independent data auditor.

What Getting It Wrong Costs

The Schedule to the Act sets maximum penalties: up to 250 crore rupees for failing to take reasonable security safeguards, up to 200 crore for failing to notify a breach, up to 200 crore for breaching the obligations on children's data, up to 150 crore for a Significant Data Fiduciary's additional obligations, and up to 50 crore for breach of any other provision.

A Seven-Month Plan

October 2026: inventory. List every store and pipeline holding Indian users' personal data, including backups, the warehouse, logs and processors. Map each field to a purpose. Flag child users, check the Third Schedule thresholds, and get counsel's view on scope and exemptions.

November 2026: design. Notice content model and versioning, consent ledger schema, retention classes per table, rights request flow. Start access logging. After around 13 November, watch the Board for registered Consent Managers and the interoperability standard.

December 2026 to January 2027: notices and consent. Ship the consent service, with withdrawal events fanned out to processors. Translate notices.

February 2027: retention and erasure. Restricted retention store, erasure jobs across primary stores and processors, and the inactivity tracker if you fall in a Third Schedule class. Amend processor contracts for safeguards and the one-year retention.

March 2027: rights and breach. Request intake, verification, the ninety-day case tracker, cross-service export, sharing register. Breach runbook, templates and an independent notification path, then one tabletop exercise.

April 2027: children and existing users. Age gating, parent verification, SDK switches for minors, guardian review. Send the section 5(2) notice to existing users. Integrate with Consent Managers if the standard is out.

Early May 2027: test and freeze. Withdraw a consent and confirm the marketing platform stopped. Request an erasure and confirm the warehouse copy went into retention. Assemble the evidence, and stop changing things in the week before 13 May.

This assumes three or four parallel streams. On older or undocumented systems, the inventory alone takes longer than a month.

Where This Fits

If you built for GDPR, a good part of the plumbing carries over, and our GDPR engineering guide covers the consent and deletion patterns. The differences that bite are the itemised notice, the one-year retention floor and verifiable parental consent up to eighteen. For another Asian market with its own regime, see Indonesia PSE registration.

We build consent services, retention and erasure jobs, access logging and rights request workflows into existing products, and we add engineers to your team through staff augmentation when the plan needs more hands than you have. We are engineers, not lawyers: scope and wording belong with your counsel, and we build to their answer. Write to office@c9group.dev.