DPDP for product teams: what changes on Monday morning

India's Digital Personal Data Protection Act was passed in 2023. The rules that make it work were notified in November 2025, with most of the obligations on businesses taking effect 18 months later, in May 2027. Many firms have handed the law to legal and compliance teams. That is a mistake, because most of what the law asks for has to be built into the product.

Notice becomes a screen

Before collecting personal data on the basis of consent, a business must give a notice that stands on its own, is written in plain language, lists the data being collected and says what it will be used for. The notice must also explain how to withdraw consent and how to complain.

For product teams, this means the notice is a designed screen, not a link to a privacy policy. It has to be readable on a phone, available in the languages the law allows, and specific to the journey the customer is in.

Consent becomes a set of switches

Consent under the Act has to be free, specific, informed, unconditional and unambiguous, given through a clear action. Withdrawing it must be as easy as giving it.

Consider what that means in practice:

• A single "I agree" covering marketing, credit bureau checks and sharing with partners will not hold. Each purpose needs its own choice.
• Pre-ticked boxes are out.
• If consent took one tap, withdrawal cannot require an email to a grievance officer.
• When consent is withdrawn, the systems downstream have to stop using the data, which means the product needs to know where the data went.

If consent took one tap, withdrawing it cannot take an email.

Rights become features

Customers can ask to see a summary of their data, have it corrected or erased, and nominate someone to act for them. Each of these is a feature, with a request flow, a verification step, a status the customer can check and a deadline the business has to meet.

Firms that already handle these requests by email will find the volume and the deadlines hard to manage without building something.

Retention becomes a design decision

Data must be erased once the purpose for collecting it has been served, unless another law requires it to be kept. For regulated financial firms, KYC and transaction rules often do require retention, so the real work is mapping which data is kept, under which rule, for how long, and making sure the rest is actually deleted.

Breaches need a plan, not a policy

A personal data breach has to be reported to the Data Protection Board and to each affected person. That needs a way to know which customers were affected and a way to reach them quickly, both of which are product and engineering problems.

What to do now

1. Map every place the product collects personal data, and the purpose of each.
2. Split bundled consents into separate choices, and design withdrawal next to each.
3. Build a requests flow for access, correction and erasure, even a simple one.
4. Write a retention table with legal teams, then build the deletion jobs it implies.

The deadline is close enough that the work belongs in this year's product roadmap. Firms that start with the screens, not the policy documents, will find the law much easier to live with.