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, 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.
Data map, roles, gaps
Grounds, retention, design
Controls in production
Tests, drill, evidence
Run it every day
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 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 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 must handle both clocks.
Do not plan around a change of date
A 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 reference case study shows this roadmap applied to an illustrative HR and payroll SaaS. It is a reference case built to show the method, not a named client. The programme ran in 16 weeks because the company had one product and a modern stack. Three lessons carry over to most organisations:
- The fiduciary or processor decision for each flow cleared the way for the rest of the plan.
- The first fix, removing personal data from logs, shipped before the gap report was final.
- Processor terms for customers and sub-processors ran in parallel with engineering, not after it.
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.
- 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 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.
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.
Turn this guide into a working programme
A 30-minute scoping call maps your gaps against the Rules and the order to close them. You get a fixed-fee proposal within three working days.
Related guides
This guide explains the Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025 as notified on 13 November 2025. It is general information, not legal advice. Check the official text, and your counsel, before relying on it.