India's Digital Personal Data Protection Act has moved from "passed but waiting on rules" to "actively enforced" over the last twelve months. The Rules under the Act were notified, the Data Protection Board is operational, and the first enforcement actions have started landing. Founders who deferred DPDP work because nothing was being enforced are now reading the news with mounting unease.
This is the practical checklist we wish more founders had. It skips the academic explanation of the Act and focuses on what to build, how to operate, and where the penalties actually bite.
The status check — where are you now?
Before the checklist, do this honest five-minute audit:
- Do you have a written privacy notice that's actually accurate (not boilerplate)?
- Do you have a way to handle deletion and access requests within the statutory timeline (45 days)?
- Do you know where Indian users' data is stored and processed?
- Can you produce, on demand, a list of every third party you've shared user data with?
- Do you know whether you're a "Significant Data Fiduciary" (SDF) — which triggers additional obligations?
If you can't say "yes, confidently" to all five, you're in the same boat as 80% of the Indian SaaS market. Read on.
The checklist
1. Consent — built into your flows, not bolted on
DPDP requires consent to be free, specific, informed, unconditional, and unambiguous, and given via clear affirmative action. In practice this means:
- No pre-ticked checkboxes. Default-off, user-checks-in.
- Granular consent for distinct purposes. Lumping "marketing emails, analytics, and product improvements" into one checkbox is non-compliant. Each material purpose needs its own toggle.
- A consent log. You need to be able to produce the timestamp, mechanism, and exact text of consent for any user on request. Most SaaS apps don't have this — they have user records with a
terms_accepted_attimestamp, which doesn't survive scrutiny. - Easy withdrawal. Consent must be as easy to withdraw as it was to give. If you sign people up in two clicks, deleting consent must be at most two clicks.
The pragmatic build: a consent service that records every consent event (granted, modified, withdrawn) with the actual consent text version that was shown. We use a tiny user_consents table with (user_id, purpose, granted_at, withdrawn_at, consent_version_id). Three days of engineering, settles 80% of the consent surface.
-- The smallest consent record that survives a DPB audit. Versioning the-- consent text matters: a user must be shown the exact text they agreed-- to (or its updated version, with re-consent) — not whatever the privacy-- notice says today.CREATE TABLE user_consents ( id BIGSERIAL PRIMARY KEY, user_id UUID NOT NULL REFERENCES users(id), purpose TEXT NOT NULL, -- 'marketing' | 'analytics' | 'profiling' | ... consent_version_id UUID NOT NULL, -- FK to consent_text_versions granted_at TIMESTAMPTZ NOT NULL, withdrawn_at TIMESTAMPTZ, source TEXT, -- 'signup' | 'preferences' | 'cookie-banner' ip_address INET, user_agent TEXT);CREATE INDEX ON user_consents (user_id, purpose, granted_at DESC);2. Data Principal Rights — production-grade, not "we'll handle it manually"
Users have the right to access, correction, completion, erasure, and grievance redressal. The 45-day timeline isn't generous when you don't have tooling.
Build (don't operate manually):
- A self-service DSR portal. Logged-in users should be able to request data export and account deletion from inside the product. No support tickets.
- An export pipeline. When a user requests their data, you should be able to package it as a structured export (JSON or CSV) within 24 hours, not 30 days.
- A hard-delete path. Not just
status = 'deleted'. Actual deletion, with downstream propagation to analytics, backups, third parties. - A grievance flow. A documented escalation path with response SLAs, owned by a named person.
The hard-delete path is where most SaaS apps fail. Soft-delete is everywhere, and the Act doesn't accept "we marked them as deleted." You need to be able to demonstrate genuine erasure, including from your analytics pipeline, your CRM, your support tool, and your data warehouse.
“We assumed our soft-delete pattern was "basically fine." An external audit found 14 systems where the deleted user's data still resolved. Fixing that took a quarter. We should have built the hard-delete pipeline three years before we needed it.”
3. Purpose limitation and data minimisation
You can only collect what's necessary for the stated purpose. The temptation to "collect everything just in case" is now a liability.
Audit your sign-up form, your onboarding, and your event tracking. If you're capturing fields you haven't used in the last 6 months, stop capturing them. If you're capturing data that's broader than your stated purpose, narrow the capture.
A useful exercise: produce a single-page data inventory — for each personal data field, the purpose, the legal basis (consent or legitimate use), the retention period, and the systems where it lives. If you can't fill that table from memory, you're not in control of your data.
4. Retention — every field has a clock
DPDP requires deletion when the purpose is fulfilled. In practice you need explicit retention policies per data category, not an undifferentiated "we keep it forever."
Common categories and reasonable defaults:
- Account data: deleted on account closure, with a 30-day grace period.
- Communications: 12–24 months depending on use.
- Payment records: 7 years (governed by Income Tax / GST requirements, which override DPDP).
- Marketing data: until consent is withdrawn, max 24 months without active engagement.
- Logs containing personal data: 6–12 months max, then either deleted or pseudonymised.
The implementation is unglamorous: scheduled jobs that delete or anonymise rows whose retention clock has expired. We run these as nightly Postgres jobs; they're 50-line scripts that meaningfully reduce risk.
5. Cross-border transfers — know your destinations
Cross-border transfer rules under DPDP are evolving and the government has reserved the right to designate specific countries as restricted. As of mid-2026, transfers to most major jurisdictions (US, EU, UK, Singapore, Japan) remain permitted with appropriate safeguards. Transfers to countries on a future restricted list will require additional steps.
Build now: a documented inventory of every third party that receives personal data — analytics providers, infrastructure providers, CRM, support tools, communication platforms — and their hosting jurisdiction. The list is required if regulators ask, and you don't want to be assembling it in a panic.
6. Security — reasonable safeguards, demonstrably
The Act requires "reasonable security safeguards." This is judgement-based, not prescriptive, which makes it harder to know if you're done.
The minimum we recommend:
- Encryption in transit (TLS 1.2+) and at rest.
- Role-based access control with least privilege.
- Audit logging on access to personal data, retained for at least 12 months.
- Annual penetration testing or equivalent.
- A documented incident response plan with timed escalation.
The audit log is the part most teams skip. You need to be able to show, in the event of a breach, who accessed what and when. Most application logs don't capture this granularity by default.
7. Breach notification — 72 hours, with details
You must notify the Data Protection Board and affected users in case of a personal data breach, "without delay" — and the Rules clarify timing expectations that line up with a 72-hour ceiling for material breaches.
Pre-build:
- An incident classification matrix so you can tell whether something counts as a notifiable breach in the heat of the moment.
- Notification templates for Board, users, and the press, pre-reviewed by counsel.
- A runbook with named escalation owners and timed steps.
You will not write these well during an actual incident. Do it now.
8. Significant Data Fiduciary (SDF) — know if you're one
The government can designate companies as SDFs based on volume of data, sensitivity, risk, and other factors. SDFs have additional obligations: appoint a Data Protection Officer (DPO), independent data audit, Data Protection Impact Assessments (DPIAs), and more.
You probably don't need to assume you're an SDF unless designated, but if you process large volumes of sensitive personal data (financial, health, biometric, children's data), build with SDF expectations in mind — appointing a DPO and running DPIAs are good practice regardless.
9. Children's data — special rules
Processing children's (under-18) data requires verifiable parental consent. Tracking and targeted advertising to children are prohibited.
If your product is consumer-facing, build an age gate. If the product is enterprise B2B with no plausible children-as-users path, document that.
10. Documentation — the part that decides enforcement outcomes
Every regulator we've seen, anywhere in the world, treats the question "show me your records" as a major signal of compliance maturity. The DPB is no different.
Keep, written and dated:
- Privacy notice version history.
- Consent records (per-user).
- Data inventory and processing register.
- Third-party processor list with DPAs.
- Incident log (including non-notifiable incidents).
- Annual review of all of the above.
A team that can produce these in a day is treated very differently from one that can't.
Where to spend first
If you're triaging, this is the order we'd put effort:
- Privacy notice + consent flows — gets you the most surface area for the least engineering. Two-week project.
- Data inventory + processing register — required documentation that everything else depends on. One-week project, mostly meetings.
- DSR self-service + hard-delete pipeline — the operational obligation that scales with users. 3–4 week engineering project.
- Retention automation — once you have a data inventory, retention jobs are a one-week add-on.
- Audit logging + incident response runbook — necessary but lower urgency unless you're handling sensitive categories.
“We thought DPDP was a documentation problem. It's actually an engineering problem dressed as a documentation problem. The teams who treat it the right way get to compliance in a quarter; the teams who don't are still re-writing privacy notices in year two.”
Frequently asked questions
Are we exempt because we're a small startup?
No. There is no small-business exemption in DPDP. Obligations attach from your first Indian user.
We use only foreign SaaS — do we still need to do this?
Yes. Your data processors don't absorb your DPDP obligations. You remain the Data Fiduciary regardless of where the data sits.
Is implied consent ever acceptable?
Very narrowly. The Act recognises certain "legitimate uses" where consent isn't required (employment, statutory obligation, medical emergency, etc.). For most commercial SaaS, you need affirmative consent.
Does DPDP override sectoral rules (RBI, SEBI, IRDAI)?
No — DPDP is additive. If you're regulated by RBI/SEBI/IRDAI, you have to satisfy both their sectoral requirements and DPDP.
Closing thought
The Indian SaaS ecosystem has spent two years treating DPDP as a future problem. It isn't anymore. The teams who built the basic infrastructure — consent, DSRs, retention, documentation — when it was cheap and quiet are now positioned to absorb scrutiny without panic. The teams who deferred are doing it now under deadline pressure, and the result is worse, slower, and more expensive.
If you want help mapping a DPDP-readiness plan against your current product surface, we offer a focused compliance-architecture review aimed at builders, not lawyers. It pairs well with the legal review you'll still need from counsel.
