DPDP Implementation: A Step-by-Step Guide for Indian Startups

DPDP compliance implementation follows six phases: data discovery, notice and consent, retention and erasure, breach response, Data Principal rights, and audit evidence, in that dependency order, taking 3 to 6 months manually or roughly 60 minutes with automated tooling.

Our DPDP compliance checklist covers the 12 things you need. This guide covers the sequence, because doing them in the wrong order wastes weeks. Consent design without a data map means redesigning it later. A retention policy before discovery is a guess dressed up as a schedule.

Phase 1: See what you actually have (weeks 1 to 2)

Before you can protect or delete personal data, you have to find it. Run a discovery pass across your production databases, logs, analytics tools, support systems, and spreadsheets. Most teams are surprised by what turns up in logs and third-party tools: this is what we call shadow PII, personal data collected as a side effect of debugging or analytics rather than by design.

Output of this phase: a data inventory mapping every category of personal data to where it lives, why you collect it, and who else (vendors, processors) touches it.

Phase 2: Fix notice and consent (weeks 2 to 4)

With the data map in hand, rewrite your privacy notice to cite the DPDP Act specifically [Rule 3], and rebuild consent capture so each purpose gets its own itemised consent [§6]: marketing separate from analytics, separate from any cross-border transfer. Record the timestamp, purpose, and exact notice text shown at the moment of consent, because that record is what an audit actually checks.

This phase depends entirely on Phase 1. You cannot itemise consent for data categories you have not yet identified.

Phase 3: Set retention and build the erasure path (weeks 3 to 6, overlapping)

For every data category in your inventory, assign a retention period: a number, a date, or a trigger event [Rule 8]. Then build the mechanism that actually executes deletion, across primaries, replicas, backups, and any processor holding a copy on your behalf. A retention policy that is not automated is a document nobody follows past the first quarter.

Phase 4: Build the breach playbook (weeks 4 to 5, can run in parallel)

Define internally what "aware" means for your team, name an incident owner, and pre-draft the notification templates you will send to the Data Protection Board and to affected users [Rule 7]. This does not depend on Phases 1 to 3 and can be built in parallel by whoever owns security or engineering leadership.

Phase 5: Stand up the rights and grievance workflow (weeks 5 to 7)

Publish your Grievance Officer or equivalent contact [Rule 9], and build the intake and response path for access, correction, erasure, and nomination requests, with a system that can respond within 90 days [Rule 14(3)]. This phase depends on Phase 1 (you need the data map to actually locate and act on a user's data) and benefits from Phase 3's erasure mechanism already existing.

Phase 6: Lock in evidence (ongoing from week 1)

Every phase above should produce an audit trail as a byproduct, not an afterthought: consent logs, deletion logs, breach response records. Under the DPDP Act, the operating assumption is that you can prove compliance on request. Retrofitting evidence after the fact is far more expensive than logging it as you go.

What this looks like compressed

Run manually with a small team, this sequence realistically takes 3 to 6 months, mostly because discovery and consent rebuild are slow without tooling. Automated discovery, consent infrastructure, and audit logging compress Phases 1, 2, 3, and 6 into roughly 60 minutes of setup, which is what Privacy Labs is built to do. See our companion piece on how long DPDP compliance actually takes for the detailed breakdown, or run a free Compliance Score below to see which phase you are stuck in.