The DPDP Act and DPDP Rules 2025 for SaaS builders: what to do now

India’s Digital Personal Data Protection Act is the country’s first dedicated data protection law, and it changes the obligations of anyone building software that handles Indian users’ personal data. If you run a SaaS product with Indian customers or users, this applies to you — including if your company is based elsewhere but offers services to people in India.

The Act is deliberately less prescriptive than Europe’s GDPR. It sets out principles and left the operational detail to rules, and those rules now exist: the Digital Personal Data Protection Rules, 2025 were notified on 13 November 2025. Most of the obligations that matter to a SaaS product apply from 13 May 2027, 18 months after notification. That sounds like a long runway until you count how much of it is engineering work.

For a builder, the practical question is: what do I actually need to do, and by when?

The DPDP Rules 2025 timeline

The Rules come into force in three phases (Deccan Herald, Legal500 analysis):

• 13 November 2025: provisions setting up the Data Protection Board took effect on notification.
• November 2026, 12 months on: the rules for registering Consent Managers apply.
• 13 May 2027, 18 months on: the operational duties apply. That covers consent notices, security safeguards, breach reporting, data retention and erasure, children’s data, and the extra duties for Significant Data Fiduciaries.

If you’re reading this in late 2026, the honest summary is that two-thirds of the runway are already gone, with about six months left.

Know what personal data you hold and why

The Act’s central rule is that you process personal data for a lawful purpose, with consent or one of the Act’s “legitimate uses”, and only collect what you need. The first step is an honest inventory: what personal data does your product collect, what do you use it for, and could you do the job with less?

The “data minimisation” principle isn’t just compliance — it’s also good security. Data you don’t collect is data you can’t leak.

Make consent real and revocable

Where you rely on consent, it has to be free, specific, informed and — importantly — easy to withdraw. For a SaaS product that means a consent flow that says what you’re collecting and why, in plain language, and a way for users to take back that consent and have their data deleted.

Buried consent in a terms page doesn’t count. The user has to actually understand what they’re agreeing to.

Rule 3 spells out what the consent notice must contain. It has to stand on its own, separate from your other terms, in clear and plain language, and include an itemised list of the personal data you process, the specific purpose for each, a description of what the processing enables, and a clear way to withdraw consent, exercise rights and complain to the Data Protection Board. In product terms: a dedicated consent screen per purpose, and a withdraw button that’s as easy to find as the accept button was.

Appoint responsibility and answer to users

The Act gives individuals rights over their data: to access it, correct it, and have it erased in many cases. A SaaS product needs a way to handle those requests — usually a support process and a data-deletion path that actually deletes the data everywhere it lives, including backups.

Someone inside the company needs to own this. It doesn’t have to be a full-time role for a startup, but a named owner matters when a request or a breach lands.

Protect the data with “reasonable security safeguards”

The Act requires data fiduciaries to take reasonable security safeguards to protect personal data. It doesn’t mandate a specific toolchain, which is both freeing and vague. In practice, for a SaaS product, that means the basics done properly: access controls, encryption of data at rest and in transit, logging, and a tested incident response plan.

This is where application security becomes a compliance requirement rather than a nice-to-have. A security assessment before launch, a DevSecOps pipeline that catches issues early, and a way to detect leaked credentials are the concrete steps that back up a “reasonable safeguards” claim.

Be ready for a breach

The Act requires notifying affected users and the Data Protection Board when a breach occurs, and Rule 7 sets the timing. Affected users must be told without delay, with what happened, the likely consequences, what you’re doing about it and what they can do to protect themselves. The Board gets an initial notice without delay, then a detailed report within 72 hours of you becoming aware of the breach, unless it allows longer.

Seventy-two hours isn’t long if you’re discovering your logging gaps during the incident. Know who you’d notify, what you’d say, and how you’d contain the damage, and rehearse it once before you need it.

Keep logs, and delete what you no longer need

Rule 6 expects reasonable security safeguards to include access logs kept for at least one year and reviewed regularly. Rule 8 adds a one-year minimum retention for certain personal data, traffic data and logs, after which you should erase them unless another law needs them kept.

Rule 8 also sets an erasure rule for large e-commerce, online gaming and social media platforms above specified user thresholds: personal data has to be erased after three years of user inactivity, with 48 hours’ notice to the user first. Most SaaS products won’t hit those thresholds, but the direction is clear. Retention needs a schedule, and deletion needs to be a job that actually runs.

What to do before May 2027

For most SaaS builders, the practical list is: inventory your data, rebuild consent and deletion flows to match Rule 3, name an owner, get the security basics and one-year logging in place, set retention schedules, and rehearse a breach response against the 72-hour clock. If you’re also selling or building AI features, the same discipline extends into ISO/IEC 42001 territory, since the two laws increasingly travel together in customer security questionnaires.