India's Digital Personal Data Protection Act — the DPDP Act, passed in 2023 — is the country's first comprehensive data protection law, and it reaches almost anyone handling the personal data of people in India. It governs digital personal data (including paper records you later digitize), and it applies extraterritorially wherever the processing relates to offering goods or services to people in India. If your product has Indian users, DPDP is your problem, whether your servers sit in Mumbai or Virginia.
One thing to get straight before you plan: the Act is enacted and the DPDP Rules, 2025 have been notified, but many substantive obligations commence in phases across a transition period rather than all at once. That is a reason to start now, not to wait — the work below takes longer than the runway.
Most DPDP guidance is written for lawyers. This one is written for the people who actually have to implement it — the engineering and cloud teams who will build the consent flows, lock down the data, and wire up breach notification. It's a practical checklist that translates the law's obligations into things you can do in your cloud environment. It is guidance, not legal advice; pair it with your counsel for the specifics of your business.
The clock is already running. The DPDP Rules were notified on 13 November 2025, starting a phased rollout. The Data Protection Board is already constituted and accepting complaints; the enforcement and penalty machinery — along with Consent Manager registration — takes effect on 13 November 2026; and full substantive compliance (notice, consent, Data Principal rights, security safeguards, breach reporting, retention, and children’s data) is required by 13 May 2027. Those are the two dates to plan against.
The vocabulary you actually need
DPDP uses a few specific terms. You only need five to get started:
- Data Principal — the individual the data is about (your user).
- Data Fiduciary — the entity that decides how and why personal data is processed (that's you).
- Significant Data Fiduciary (SDF) — a Data Fiduciary the Central Government designates as high-risk based on the volume and sensitivity of data it processes, carrying extra obligations. The thresholds have not been notified, and only the government can designate you — so treat SDF status as something to plan for, not self-declare.
- Data Processor — anyone processing data on a Fiduciary's behalf (your cloud provider, your SaaS vendors).
- Consent Manager — a DPDP-specific intermediary, registered with the Data Protection Board, through which a user can give, manage, review, and withdraw consent. India-only, and worth designing for even if you don't integrate one on day one.
The law is built on a simple principle: you may process someone's personal data only for a lawful purpose, with their consent (or a small set of "legitimate uses"), and you are accountable for protecting it the whole time you hold it.
1. Know what personal data you hold — and where
Why it matters: Every other obligation — consent, security, erasure, breach notification — depends on knowing what personal data you have and where it lives. You cannot protect, delete, or report on data you haven't mapped.
- ▢ Inventory every store that holds personal data of Indian users — databases, buckets, data warehouses, logs, backups, and third-party SaaS.
- ▢ Record, for each: what categories of personal data it holds, why (the purpose), and which vendor or region it sits in.
- ▢ Flag any data your cloud config exposes publicly — a misconfigured bucket of personal data is both a security and a DPDP problem.
- ▢ Keep the map current automatically. A quarterly spreadsheet is stale the week after you write it; this is the part teams most often operationalize with tooling.
2. Get consent right — and be able to prove it
Why it matters: DPDP requires free, informed, specific consent, preceded by a clear notice, and consent must be as easy to withdraw as it was to give. "Accept all" dark patterns won't survive scrutiny.
- ▢ Present a plain-language notice describing what you collect and why, before or at the point of collection — available in English or any Eighth Schedule language, at the user's choice.
- ▢ Capture consent per purpose — not one blanket checkbox — and store an auditable record of what was consented to and when.
- ▢ Provide a withdrawal path that is as simple as the opt-in, and stop the relevant processing when consent is withdrawn.
- ▢ Design your consent store so a registered Consent Manager can drive it later; that means consent as structured, per-purpose state you can read and revoke through an API — not a boolean buried in a user row.
- ▢ For children's data, implement verifiable parental consent and avoid tracking or targeted advertising to minors.
3. Honour Data Principal rights
Why it matters: Users have the right to a summary of the data you hold and how you process it, to correction and erasure, and to nominate someone to act on their behalf. These rights are only real if your systems can act on them, at scale, within the timeframes you publish.
- ▢ Build a request workflow for access, correction, and erasure — and make sure erasure actually reaches backups and downstream copies.
- ▢ Be able to return a summary of the personal data you hold on a user and the processing you do with it — not just a raw table dump.
- ▢ Publish a reachable grievance channel with a named contact, and track requests to resolution within your stated timeframe.
- ▢ Propagate erasure and correction to every Data Processor you shared the data with.
4. Secure the data with "reasonable safeguards"
Why it matters: DPDP requires reasonable security safeguards to prevent personal data breaches, and the penalty ceiling for failing that duty is the highest in the Act — up to ₹250 crore under Section 8(5). The law doesn't prescribe exact controls, so you map to a recognized baseline and keep the evidence.
- ▢ Encrypt personal data in transit and at rest; manage keys properly.
- ▢ Enforce least-privilege access to personal data, and log and review who accessed it — retaining those logs for at least a year.
- ▢ Continuously check cloud configuration against a benchmark like the CIS Benchmarks so "reasonable safeguards" is something you can evidence, not just assert.
- ▢ Bind every Data Processor with a contract that flows these security obligations — and breach reporting — down to them.
5. Be ready to report a breach — on two clocks
Why it matters: On a personal data breach, DPDP requires you to notify both the Data Protection Board of India and each affected Data Principal without delay, with detailed information to the Board ordinarily within 72 hours (Rule 7 of the DPDP Rules). Separately, the CERT-In Directions require reporting specified cyber incidents within 6 hours. Six hours is the deadline that actually breaks teams — and you cannot meet it if you don't know what was breached, which loops straight back to your data map (step 1). The ceiling for failing the notification duty is up to ₹200 crore under Section 8(6).
- ▢ Define what qualifies as a personal data breach, who declares it, and who is on the hook at 3 a.m.
- ▢ Maintain a runbook that can, fast, answer: what data, whose data, how much, what consequences, what mitigation, what cause.
- ▢ Pre-draft notification templates for the Board, for CERT-In, and for affected users so the clock isn't spent writing from scratch.
- ▢ Rehearse it. A tabletop exercise against the 6-hour clock will find the gaps that a document review never does.
6. Handle retention, deletion, and cross-border flows
Why it matters: You may keep personal data only as long as it serves the purpose it was collected for, then must delete it. DPDP also allows cross-border transfers except to countries the government restricts — so where data flows matters.
- ▢ Set and enforce retention periods per data category; automate deletion when the purpose ends or consent is withdrawn.
- ▢ If you run e-commerce, social media, or online gaming at the scale in the Rules' Third Schedule, build the advance pre-erasure notice for dormant accounts — a real engineering task with a real deadline attached.
- ▢ Map where personal data is transferred and stored, including by your vendors, and keep that current.
- ▢ If you may be designated a Significant Data Fiduciary, plan for the extra duties — a Data Protection Officer based in India, Data Protection Impact Assessments, and periodic independent audits.
Where to start: the first 30 days
- Week 1 — Map it. Build the personal-data inventory (step 1). Nothing else is possible without it.
- Weeks 2-3 — Secure it. Close public exposure, enforce encryption and least privilege, and get your Processor contracts in order (step 4).
- Week 4 — Rehearse it. Stand up the breach runbook and a Data Principal request workflow (steps 3 and 5), and run one tabletop against the 6-hour clock before you need it.
If you want a baseline before you start, our free DPDP readiness checker walks the same obligations as a 3-minute self-assessment — it runs entirely in your browser, and nothing you enter is sent anywhere.
The through-line
DPDP compliance isn't a separate project bolted onto security — it's data governance plus cloud security fundamentals, pointed at one question: can you account for every piece of personal data you hold, protect it, and act on it when a user or the regulator asks? The teams that will pass an audit are the ones who can see their personal data, secure it, and prove both. For the authoritative text, the Act and its rules are published by India's Ministry of Electronics and Information Technology.
Much of this is the cloud security work you may already be doing, pointed at a specific regulator — see the guide to how the cloud security categories fit together, which leans on the same inventory-and-least-privilege foundation DPDP demands. And if you'd rather run these obligations as a system than a spreadsheet, that's exactly what our DPDP compliance platform does: breach deadlines on both clocks, DPIA lifecycle, SDF classification, vendor due diligence, and regulator-ready audit packs — SaaS or fully on-premises.