# DPDP implementation roadmap: 26 weeks to 13 May 2027

Source: https://dpdp.d2c.in/guides/dpdp-implementation-roadmap/ · Updated 2026-11-13 · DPDP Ready by Mirav Labs

**Short answer:** To be compliant by 13 May 2027, run five overlapping phases across the 26 weeks left: discover (data map, roles), decide (lawful grounds, retention), build (notices, consent ledger, Rule 6 safeguards, rights, erasure, processor contracts), prove (breach drill, tests, evidence) and operate. Start security and vendor contracts early: they carry the highest penalties and the longest lead times.

## Key takeaways

- There are 181 days, about 26 weeks, between 13 November 2026 and 13 May 2027.
- The data map comes first. Notices, consent, rights and erasure all depend on it.
- Security safeguards and processor contracts have the longest lead times, so start them by week 5.
- Start proving from week 17, while the last builds finish: a breach drill, withdrawal and erasure tests, and an evidence pack.
- Plan on 13 May 2027 as fixed. The only change discussed was a proposal to shorten the window, and it has not been adopted.

DPDP programmes rarely stall on legal interpretation. They stall on sequencing: notices written before anyone knows what data exists, consent screens built before purposes are agreed, vendor contracts left until the last month. This roadmap sets out an order of work that avoids those traps, sized to the time left.

From today, 13 November 2026, there are 181 days (about 26 weeks) until the core obligations of the Act and Rules 3, 5 to 16, 22 and 23 apply on 13 May 2027. The plan below is sized to fit that window for a typical single-product organisation. Use it with the [DPDP compliance checklist](https://dpdp.d2c.in/guides/dpdp-compliance-checklist/), which lists what each workstream must deliver.

## How long does it take to implement the DPDP Act?

It depends on how many systems hold personal data, how many vendors you use and how much of the work is product change. A single product with a modern stack can typically finish the core build in 12 to 20 weeks. A group with several brands, legacy systems or hundreds of vendors needs parallel teams. In every case the work falls into five phases that overlap rather than run one after another.

 **Discover**Data map, roles, gaps

 **Decide**Grounds, retention, design

 **Build**Controls in production

 **Prove**Tests, drill, evidence

 **Operate**Run it every day

**Now:** 

## The five phases in detail

Each phase has a clear exit test. Do not move a workstream forward until its inputs have passed the test for the phase before.

| Phase | Weeks | Key outputs | Exit test |
|---|---|---|---|
| Discover | 1 to 4 | Data inventory across systems; fiduciary or processor role per flow; vendor list; gap register rated by exposure | Every store and vendor is listed, and leadership has accepted the gap register |
| Decide | 3 to 7 | Purpose register with consent or a section 7 legitimate use for each purpose; retention periods; notice structure; target architecture for consent and erasure | Decisions signed off in writing by an accountable owner |
| Build | 6 to 20 | Itemised notices (Rule 3); consent ledger and withdrawal; Rule 6 safeguards and one-year logs; rights and grievance portal; erasure orchestrator; processor contracts | Each control works in production, not just in a design document |
| Prove | 17 to 24 | Breach drill against the Rule 7 timeline; withdrawal, rights and erasure tests; evidence pack | Tests pass, and evidence is filed against each obligation |
| Operate | 22 onwards | Grievance desk live; quarterly control tests; privacy review for new features and vendors | Named owners run each control without the project team |

### Discover: map before you write anything

Scan databases, object stores, logs, search indexes, analytics tools, data warehouses and backups. Tag each field by data category. For each flow, record whether you decide the purpose and means (a Data Fiduciary under section 2(i)) or act on someone else's behalf (a Data Processor under section 2(k)). The [fiduciary vs processor guide](https://dpdp.d2c.in/guides/data-fiduciary-vs-data-processor/) explains how to make that call. Close obvious exposures as you find them, such as personal data written to debug logs.

### Decide: the choices only leadership can make

Every purpose needs either consent under section 6 or one of the legitimate uses listed in section 7. There is no general "legitimate interests" ground. Retention periods need agreement too, because section 8(7) requires erasure once the purpose is no longer served, while Rule 8(3) requires every fiduciary to keep personal data, traffic data and logs for at least one year. Both must be designed together.

### Build: controls in production

This is the longest phase and where most effort goes. Notices must itemise the data and describe each specific purpose. The consent ledger must record each consent and withdrawal with the notice version, because section 6(10) puts the burden of proof on you. Safeguards follow Rule 6: encryption, masking or tokens, access control, logging and monitoring, backups and contract terms. Rights handling must publish how to make requests and a grievance response period of no more than 90 days (Rule 14).

### Prove and operate

Run at least one breach drill against the Rule 7 sequence: tell affected people and the Board without delay, then file the detailed report within 72 hours. Test that withdrawal stops processing at your processors, that erasure reaches every copy, and that a rights request can be answered end to end. File the results. Then hand each control to a named owner.

## The 26-week plan at a glance

Ten workstreams cover the obligations that apply to every fiduciary. The bars show when each is active; colours group them by type.

If you have children among your users, add a workstream for age gating and verifiable parental consent under Rule 10, running alongside notices and consent. If you might be designated a Significant Data Fiduciary, add one for the DPO, data auditor and DPIA; the [SDF guide](https://dpdp.d2c.in/guides/significant-data-fiduciary/) covers what it involves.

## Who owns each workstream?

One senior leader should be accountable for the programme. Below that, each workstream needs a single accountable owner (A) and the teams responsible for the work (R), consulted (C) or kept informed (I). HR is responsible for the employee data parts of each stream and for delivering training.

| Workstream | Leadership | Legal | Product | Engineering | Security | Procurement | Support |
|---|---|---|---|---|---|---|---|
| Data map and roles | A | C | C | R | C | C | I |
| Lawful grounds and retention | A | R | C | C | I | I | I |
| Notices and consent ledger | I | C | A | R | C | I | I |
| Rights and grievance portal | I | C | A | R | C | I | R |
| Security safeguards and logs | I | I | I | R | A | C | I |
| Retention and erasure | I | C | C | A, R | C | C | I |
| Breach runbook and drills | I | R | I | C | A, R | C | C |
| Processor contracts | I | R | I | C | C | A | I |
| Training and policies | A | R | C | C | C | I | C |
| Evidence pack and review | A | R | C | C | C | C | C |

Give the programme a weekly 30-minute review with every accountable owner present. A short status per workstream (on track, at risk, blocked) and the decisions needed that week is enough. Blocked decisions are a common cause of slippage.

## What depends on what?

Getting dependencies right is most of the plan. These are the ones that matter:

- **Data map before everything.** Rule 3 requires an itemised description of personal data in the notice. You cannot itemise what you have not found.

- **Purpose register before consent screens.** Consent must be specific to a purpose, so purposes must be fixed first.

- **Consent ledger before the purpose gate.** Data should flow to a purpose only when the ledger shows a valid ground.

- **Retention decisions before erasure.** Engineers cannot build deletion jobs without agreed periods and the one-year floor in Rule 8(3).

- **Vendor register before contracts, and contracts before the breach runbook.** Your 72-hour clock depends on how fast processors tell you.

- **Logging before breach readiness.** Rule 7 asks for the extent, timing and cause of a breach; without logs you cannot answer.

## Common traps that delay DPDP programmes

Traps

- Treating DPDP as a policy-writing exercise

- Waiting for the Board to become functional

- Writing notices before the data map

- Assuming a B2B company is only a processor

- Leaving vendor negotiations to the final month

- Breach plans that only cover the regulator

What to do instead

- Fund product and engineering time from week 1

- Plan on 13 May 2027 regardless of Board appointments

- Draft notices from the inventory and purpose register

- Map roles per flow: you are a fiduciary for your own users and staff

- Send contract updates to vendors by week 5

- Notify every affected person too, as section 8(6) requires

Two more traps are worth naming. First, existing users: section 5(2) requires notice to people whose consent was taken before commencement, as soon as reasonably practicable, so plan a notice campaign for your current base. Second, CERT-In's separate 6-hour cyber incident reporting direction continues alongside the Rule 7 process, so the [breach runbook](https://dpdp.d2c.in/guides/dpdp-breach-notification/) must handle both clocks.

Do not plan around a change of dateA proposal to shorten the 18-month window to 12 months was discussed with industry in early 2026. No amendment has been notified. Plan for 13 May 2027, and treat any change as a reason to review, not to pause.

## A worked example

Our [case study](https://dpdp.d2c.in/case-study/) applies this roadmap to our own commerce platform, D2 Commerce OS, with 1,000+ customers, and publishes the status of all 29 controls. Three lessons carry over to most organisations:

- The fiduciary or processor decision for each flow cleared the way for the rest of the plan.

- Earlier security work covered most of Rule 6; the DPDP-specific gaps were narrower and quicker to scope.

- Ordering the work by penalty exposure put log retention, the breach console and encryption first.

## How to implement this

- **This week:** name an accountable owner and start the data inventory.

- **By week 4:** finish the gap assessment using the [compliance checklist](https://dpdp.d2c.in/guides/dpdp-compliance-checklist/).

- **By week 5:** start security safeguards and send processor contract updates.

- **By week 7:** sign off lawful grounds, retention periods and the notice structure. The [consent and legitimate uses guide](https://dpdp.d2c.in/guides/dpdp-consent/) helps here.

- **Weeks 6 to 20:** build, shipping controls to production as they are ready.

- **Weeks 17 to 24:** run the breach drill and tests, and file evidence.

- **From week 22:** hand controls to their owners.

If you want engineers and privacy practitioners who have run this plan before to work inside your teams, [book a scoping call](https://dpdp.d2c.in/#contact).

## Frequently asked questions

### How long does DPDP implementation take?

A single product company with a modest number of systems typically needs 12 to 20 weeks of focused work. Groups with several products, legacy systems or many vendors need longer, or parallel teams. With about 26 weeks left before 13 May 2027, there is enough time only if discovery starts now.

### How do I implement the DPDP Act step by step?

Map your personal data and your role for each flow, decide the lawful ground and retention period for each purpose, then build notices, a consent ledger, security safeguards, rights handling, erasure and processor contracts. Finish by testing everything, running a breach drill and assembling evidence.

### Can we wait for the Data Protection Board to start before implementing?

No. The Board has been established but no Chairperson or Members had been appointed by early November 2026. That does not move the 13 May 2027 date for obligations under the Act and Rules, and once its Members are appointed, the Board can act on breaches of the obligations that apply from that date.

### Who should own the DPDP compliance plan?

One senior leader should be accountable, with legal, product, engineering, security, procurement, HR and support each responsible for their workstreams. Compliance fails when it sits only with legal, because most of the work is product and engineering change.

### What should we do first if we have very little time?

Build the data inventory, close the highest-exposure security gaps, put processor contracts in place and prepare a breach runbook. Those cover the obligations with the highest penalty ceilings. Then move to notices, consent, rights and erasure.

### Is there a DPDP compliance plan template?

Use the five phases and ten workstreams on this page as the template, and the master table in our DPDP compliance checklist for the obligations each workstream must cover. Add an owner, a target week and an evidence item to every line.