India’s Digital Personal Data Protection Act is a list of things your product has to do — ask properly, honour rights, protect data, erase it, prove all of it. Answer ten questions about what you run and get the engineering backlog that follows: every item that applies, in build order, with the section of the Act beside it and what a team actually delivers.
Build my planReady to start: DPDP Build Plan
Before you start
Ten questions about your product — what it is, who uses it, what it holds, how consent and rights work today. The plan appears on screen the moment you answer the tenth: every item that applies, grouped by phase, with the section of the Act beside it and a PDF to keep.
The DPDP Build Plan is an educational planning tool built from the Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025 as notified. It describes engineering work the duties imply; it is not legal advice, an audit or a certification — engage qualified counsel for compliance determinations and confirm the commencement dates that apply to you.
The flow
What you hold, why, and who answers for it — the map everything else reads from.
Asking properly: itemised notice, a real yes per purpose, and withdrawal that works.
Access, correction, erasure and complaints as product features with owners and clocks.
The Rules' minimum safeguards, and a breach response that beats the 72-hour report.
Retention, erasure, transfers and every third party that touches personal data.
An owner, a dated plan to commencement, and the evidence the Board or a buyer could ask for.
The rule table
The full table the tool draws from: 26 build items across six phases, 15 of them duties every Data Fiduciary carries. Each names the duty in plain language, the section of the Act or the Rule it comes from, and what engineers deliver — never an effort or a price. Published so the plan you get can be checked line by line.
Rule table v1 · September 2026 · against the Act and the Rules as notified in November 2025.
Full methodologyEvery duty in the Act presumes you can say what personal data you hold, where, for which purpose, and who processes it — notice, erasure, breach intimation and rights requests all read from this map.
What gets built: A living register of systems × data categories × purposes × processors × regions, owned by someone, generated from your infrastructure wherever possible and reviewed on a cadence.
Source Act ss.5, 8(6)–(7), 11
Personal data may be processed only for a lawful purpose, with consent or under one of the Act's listed legitimate uses — voluntary provision, employment, a legal obligation, a medical emergency and the rest. Each purpose becomes a notice, a consent record and a retention period downstream.
What gets built: One table of purposes, each with its ground, data items, retention period and owner — the source every notice and consent screen is generated from, not a document beside them.
Source Act ss.4, 6, 7
You must publish the business contact of a Data Protection Officer or a person able to answer questions about the processing, and provide an accessible grievance redressal mechanism.
What gets built: A named person on the website and in the app, repeated in every response to a rights request or grievance, with the published response period beside the name.
Source Act s.8(9)–(10); Rules r.9
The Government may notify a Data Fiduciary as Significant by the volume and sensitivity of the data and the risk to rights. A Significant Data Fiduciary appoints a Data Protection Officer based in India and an independent data auditor, runs an annual impact assessment and audit, performs due diligence on its algorithms, and may face localisation of specified data.
What gets built: A documented assessment of likelihood, and the DPO role, auditor, impact-assessment and audit cadence designed now so they can be switched on the day a notification arrives.
Source Act s.10; Rules r.12
A request for consent must be accompanied or preceded by a notice describing the personal data and the purpose, how to withdraw consent and exercise rights, and how to complain to the Board — and the user may choose English or any of the twenty-two scheduled languages.
What gets built: A notice component generated from the purpose register, versioned so each consent records the notice it was given against, with a language switch for the Indian languages your users choose.
Source Act s.5; Rules r.3
Consent must be free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, and limited to the personal data necessary for the purpose — no pre-ticked boxes and no bundling with the terms of service.
What gets built: Consent screens per purpose, unticked by default, with the notice version, timestamp and channel recorded against the user the moment they agree.
Source Act s.6(1)–(3)
Withdrawing consent must be as easy as giving it. Once withdrawn, processing stops within a reasonable time and the data is erased unless retention is required by law — by you and by your processors.
What gets built: An in-product withdrawal control per purpose, propagated to every system and processor that holds the data, with the stop and the erasure recorded.
Source Act s.6(4)–(6), s.8(7)
Where a Data Principal disputes it, the burden of proving that notice was given and consent obtained is on the Data Fiduciary — a consent you cannot evidence is one you cannot rely on.
What gets built: An append-only consent ledger — user, purpose, notice version, timestamp, channel, withdrawal — queryable per user for rights requests and audits, and exportable as evidence.
Source Act s.6(10)
Analytics, session replay, attribution and advertising SDKs collect personal data the moment they load; they need a consented purpose first, so nothing non-essential loads until the user has said yes.
What gets built: A consent gate in the product that holds every non-essential tag until its purpose is granted, and a cookie-and-SDK register the notice is generated from — the pattern this site itself runs.
Source Act ss.5–6
A child is anyone under 18. Processing a child's personal data requires the verifiable consent of a parent or lawful guardian, and tracking, behavioural monitoring and targeted advertising directed at children are prohibited.
What gets built: An age step, a parent-verification flow using reliable identity or age details or a virtual token, and a child mode with analytics, remarketing and behavioural features switched off.
Source Act s.9; Rules r.10
The Act creates Consent Managers — registered with the Board, interoperable platforms through which a person can give, manage, review and withdraw consent. Consent signals that arrive through one have to land in the same ledger as your own screens.
What gets built: A consent API on your side keyed by user and purpose, so a Consent Manager's grant or withdrawal updates the same ledger and triggers the same downstream stop.
Source Act s.6(7)–(9); Rules r.4
A Data Principal may ask for a summary of their personal data and its processing, for correction, completion, updating and erasure, and may nominate someone to exercise these rights — and you must publish the means to do so and the period you respond in.
What gets built: Intake with proportionate identity checks, case tracking with owners and the published period, fulfilment across systems from the data map, and a nominee record per user.
Source Act ss.11–14; Rules r.13
Every Data Principal has a right of grievance redressal through your published mechanism, and only after exhausting it may approach the Board — so the mechanism has to be real, timed and tracked.
What gets built: A grievance channel with case IDs, the Grievance Officer as owner, the published response period enforced by the system, and an audit trail the Board could read.
Source Act ss.8(10), 13; Rules r.13
Erasure and correction mean nothing if a copy survives in a warehouse, a CRM or a vendor's store — and the Act requires you to cause your processors to erase as well.
What gets built: Event-driven propagation of correction and erasure to every store and processor named in the data map, with confirmation recorded per request.
Source Act ss.8(7), 12
Reasonable security safeguards are a duty carrying the Act's highest penalty tier, up to ₹250 crore. The Rules name the minimum: encryption, obfuscation, masking or tokenisation; access control; logs and monitoring to detect unauthorised access; retained logs; backups; and processor contracts that carry the same.
What gets built: Encryption at rest and in transit including backups, least-privilege access with scheduled reviews, centralised logs retained for the Rules' period and monitored, and tested restores.
Source Act s.8(5); Rules r.6
On becoming aware of a personal data breach you must intimate each affected Data Principal without delay, in plain language, and the Board without delay — followed by a detailed report to the Board within 72 hours.
What gets built: Detection and severity triage, a decision tree, templates for the user intimation and the Board's report, contact lists, and a drill at least once a year.
Source Act s.8(6); Rules r.7
The Act defines no special categories, but the harm — and the penalty tier for a safeguards failure — scales with what would leak. Field-level protection for the data that would hurt most is how you show the safeguards were reasonable.
What gets built: Field-level encryption or tokenisation for the sensitive fields with separate keys, stricter access reviews, and masking in logs, analytics and support tools.
Source Act s.8(5); Rules r.6
You may engage a Data Processor only under a valid contract, and the Rules require it to bind the processor to the safeguards — when a processor fails, the duty and the penalty are still yours.
What gets built: A processor register from the data map, a standard India data-processing addendum with security, breach-assistance, erasure and sub-processor terms, and a review date on each.
Source Act s.8(2); Rules r.6
Once consent is withdrawn or the purpose is served, personal data must be erased — by you and your processors — unless retention is necessary under law. Data you no longer need is exposure you no longer need.
What gets built: A retention period per purpose in the register, scheduled erasure jobs across every store, erasure requests to processors, and a completion record.
Source Act s.8(7)
For e-commerce entities and social-media intermediaries with two crore or more registered users in India, and online gaming intermediaries with fifty lakh, the Rules deem the purpose served three years after the user's last interaction — erase, after at least 48 hours' notice to the user.
What gets built: Last-interaction tracking per user, a 48-hour notice job, and erasure automation that runs on the clock rather than on request.
Source Rules r.8, Third Schedule
Transfers outside India are permitted unless the Government restricts a country by notification, subject to any requirements it specifies, and Significant Data Fiduciaries may face localisation of specified data. You cannot comply with a restriction on data whose location you cannot name.
What gets built: A register of every region and recipient from the data map, contractual controls on each transfer, and a watch on Government notifications with a switch-over plan per transfer.
Source Act s.16; Rules r.14, r.12
Every SDK and vendor that receives personal data is a processor or a fiduciary in its own right; you need to know what each receives, on which ground, under which contract, and in which country.
What gets built: A vendor register with data received, purpose, ground, contract and region, and egress controls so a new vendor cannot receive personal data before it is registered.
Source Act ss.6, 8(2)
Personal data sent to a model provider is a transfer to a processor — it needs a purpose, a ground, a contract and minimisation, and the prompts and completions you log are personal data too.
What gets built: Redaction or tokenisation before prompts, provider terms with no-training and retention limits, prompt and completion logs treated as personal data, and a register of what each model receives.
Source Act ss.6, 8(2)
Where personal data is likely to be used to make a decision that affects the person, or to be disclosed to another Data Fiduciary, you must ensure it is complete, accurate and consistent.
What gets built: Validation at capture, reconciliation across systems, a correction route that reaches every consumer of the data, and lineage for the decisions the data feeds.
Source Act s.8(3)
The DPDP Rules were notified in November 2025 with most duties on an 18-month clock — as notified, May 2027. A backlog without an owner and dates against that clock is a wish, not a plan.
What gets built: A named owner reporting to leadership, this backlog dated against the commencement with owners per item, and a quarterly review that leadership sees.
Source DPDP Rules, 2025 — commencement, as notified
The Board can call for information and buyers ask for proof at vendor review. Consent records, notice versions, the data map, processor contracts, the breach log, the rights and grievance logs — and for a Significant Data Fiduciary the impact assessment and audit reports — are the pack.
What gets built: One evidence index kept current by the systems that generate it — exports from the consent ledger, the data map and the case logs — rather than a folder assembled under pressure.
Source Act ss.6(10), 10; Rules r.12
FAQ
Short answers to what people ask before they take it — how the plan is prioritised, why it never estimates effort, and what it can and cannot tell you.
A free planning tool that turns India's Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025 into an engineering backlog for your product. Ten answers about what you run, who uses it and how personal data is handled today select the build items that apply, each with the section of the Act it satisfies and what engineers deliver.
Founders, product owners and engineering leads responsible for software that processes the personal data of people in India — consumer apps, marketplaces, SaaS, fintech, healthtech, edtech and internal systems — and companies outside India serving Indian users. It is written for the people who will build the features, not for lawyers.
No. The plan is an educational tool built from the Act and the Rules as notified, with section and rule references you can check. It shows the engineering work the duties imply for a product like yours; it is not legal advice, an audit or a certification — engage qualified counsel for determinations and your dates.
Items marked Must are duties every Data Fiduciary carries — notice, consent, rights, safeguards, breach response, erasure. Items marked Applies to you switch on from your answers, such as children's consent or cross-border controls. Recommended items are good practice the Act rewards. Where your answers say something already exists, the item asks you to verify it rather than build it.
No, deliberately. Every item names the work — what a team builds and why — but no effort or price, because an estimate without knowing your systems would be invented, and DigiWagon's own rates belong in a conversation, not a tool. Send the backlog through and we will size it against your actual architecture.
No. The full backlog appears on screen the moment you answer the tenth question, grouped by phase with every citation, and the PDF is generated locally in your browser. Your answers never leave the page unless you choose to send the plan to our team, and the contact form only asks for what a reply needs.
Send your backlog through and we'll size it against your actual systems in a working session — the consent ledger, the rights centre, erasure automation, the breach runbook, the vendor map. Engineering that makes compliance a property of the platform rather than a policy beside it.
Ask an AI about this page
One click opens the assistant you already use with a question that points it at this page, so the answer comes from what we publish, not a guess.
The question it opens withRead https://digiwagon.com/tools/dpdp-build-plan and tell me what "DPDP Build Plan" helps me decide, what inputs I should gather before using it, and how DigiWagon suggests acting on the result. Stick to what the page says and mark anything you are not sure about.
