DPDP rules are notified. What an Indian SaaS founder should fix this quarter.

The Digital Personal Data Protection Act was passed in August 2023. The rules that make it operable were notified in stages through late 2025 and early 2026. As of this quarter, every Indian business that processes personal data — which is to say, every Indian business that has a website — is on the clock.

I have spent the last four months helping mid-stage SaaS companies get to a sane compliance posture. The pattern is consistent. Founders read the Act, write a privacy policy, and assume they are done. The Act is mostly about the plumbing beneath the policy — how data flows, who can see it, and how fast you can find it when somebody asks.

The four things the rules actually require

Strip out the schedules and the proviso language, and the operative requirements are:

1. A consent flow that is granular, specific and easy to withdraw. One checkbox at the bottom of the signup form does not pass.
2. A way for a data principal (your user) to ask for their data, ask for correction, and ask for deletion — and a way for you to respond inside the prescribed window.
3. A breach-notification process. A 72-hour window in most cases — shorter if you are classified as a Significant Data Fiduciary.
4. A retention schedule. If you do not need the data, you cannot keep it. “In case we need it later” is no longer a defence.

The first two are where the engineering work hides.

Consent: the “just-in-time” standard

The rules do not literally use the phrase “just-in-time consent”, but the language is functionally identical: consent must be specific to a purpose, taken at the point at which the purpose arises, and presented in clear, plain language.

What this means for a SaaS signup flow:

• The signup checkbox can no longer bundle “I agree to the terms and agree to marketing emails and agree to product analytics”. Those are three purposes; they need three flags, two of which must default to off.
• If you add a new processing purpose six months in — say, you start using customer data to train a model — you need a fresh, specific consent for that purpose. You do not get to retro-fit the original signup checkbox.
• The withdrawal mechanism must be as easy as the original consent. A buried “email us to opt out” link does not pass.

Data-principal requests: the part everyone underestimates

A user emails you and asks for a copy of all data you hold about them. You have a defined window to respond. How long would it take your team to answer that today, honestly?

For most small SaaS companies, the answer is “we would have to ask engineering, and engineering would have to write a script”. That is fine the first time. It is not fine the tenth time, and the rules do not give you the option of saying no.

The work to do here is unglamorous: build an internal admin tool that, given a user ID, exports their record from every system that holds it — the primary database, the analytics warehouse, the support tool, the email platform, the backups. Do it once, properly, and the next 50 requests take 10 minutes each.

Breach reporting: practise it before you need it

The 72-hour window assumes you can detect the breach. Most small companies cannot. A leaked S3 bucket goes undetected for weeks not because anyone is incompetent but because no alarm was wired.

The practical first step is the boring one: turn on the cloud-provider breach detection (CloudTrail, GuardDuty, equivalent), point the alerts at a channel a human reads, and write a one-page incident-response runbook. The first time you actually need it should not be the first time you have read it.

Retention: the cheapest win

For a small SaaS company, the fastest compliance win is to write down a retention schedule and act on it. Old support tickets, old session logs, old failed-signup records — if you do not have a reason to keep them, the rules say you should not. Deleting them is a one-day engineering project and it shrinks the surface area of every other obligation in the Act.

What I would do this quarter

If I were running a 20-person SaaS company, my next 90 days would look like:

• Month 1: map every system that touches personal data. Publish an internal data-flow diagram. Identify which systems hold what.
• Month 2: rebuild the consent flow at signup. Build the internal admin tool for data-principal requests. Write the retention schedule.
• Month 3: table-top the breach-response runbook. Audit one month of consent records to confirm the new flow is producing clean data. Have your privacy notice reviewed by a lawyer who has actually read the rules.

None of this is glamorous. All of it is cheaper than the first time you need it and do not have it.