The Digital Personal Data Protection Act was passed in 2023, but for two years it had no operating manual. That changed when the Ministry of Electronics and IT notified the DPDP Rules, 2025 in November 2025. The Rules switched on the Data Protection Board immediately and gave every business that handles personal data of people in India an 18-month runway, which ends in May 2027.
Eighteen months sounds generous. It is not. In the readiness assessments our cybersecurity practice has run this year for fintech, healthcare and e-commerce clients, the policy work, meaning privacy notices, contracts and governance, usually takes weeks. The engineering work takes quarters. Consent has to be captured and enforced at the API layer. Data has to be found before it can be erased. Breach detection has to be fast enough to meet a 72-hour reporting window. None of that lives in a policy document.
This post is the playbook we use: what each operative rule requires from your systems, and the order we recommend building it in.
A note before you read on: this is an engineering perspective, not legal advice. Work with qualified counsel on how the Act applies to your specific business, especially on lawful-use exemptions and sector regulation from the RBI, SEBI or IRDAI that may stack on top of DPDP.
The Timeline: Three Dates That Matter
The Rules are phased rather than switched on at once:
November 2025, on notification: Rules 1, 2 and 17 to 21 took effect. These cover definitions and the constitution and functioning of the Data Protection Board. Nothing here changes your systems directly, but the regulator now exists.
November 2026, at twelve months: Rule 4 takes effect, opening registration for Consent Managers. These are India-incorporated platforms that let people give, manage and withdraw consent across businesses from one interface. If you plan to integrate with them, your consent architecture needs to be interoperable before this date. That is next month.
May 2027, at eighteen months: the substantive obligations take effect. This is Rule 3 (notice), Rules 5 to 16 (including security safeguards, breach intimation, retention and erasure, children's data, Significant Data Fiduciary duties, Data Principal rights and cross-border transfer) and Rules 22 and 23. This is where penalties bite.
One caveat: in January 2026, MeitY put out for consultation a proposal to shorten the window to 12 months for some obligations, particularly those on Significant Data Fiduciaries. At the time of writing, that proposal has not been notified. We advise clients to plan against May 2027 but to design for November 2026. If the timeline is compressed, you will not be caught short. If it is not, you finish early.
Why This Is an Engineering Problem
The Act's penalty schedule makes the priorities clear. The largest single penalty, up to ₹250 crore, is for failing to take reasonable security safeguards to prevent a personal data breach. Failing to notify the Board or affected individuals of a breach, and violating the obligations on children's data, each carry up to ₹200 crore. Significant Data Fiduciary failures can reach ₹150 crore, and most other violations ₹50 crore.
Look at what those obligations actually require. Every one of them is a property of a running system, not a document:
Reasonable security safeguards means encryption, access control and monitoring that actually work.
Breach intimation means you can detect a breach, scope which people were affected and produce a report within 72 hours.
Erasure means you can find every copy of a person's data, including in backups, analytics warehouses and third-party processors.
Consent means your systems refuse to process data for a purpose the person did not agree to, or has since withdrawn.
A company can have flawless policies and still fail every one of these in practice.
Rules 3 and 4: Notice and Consent Become a Runtime Concern
Rule 3 requires the notice you give a Data Principal to be understandable on its own, separate from other information, and to give an itemised description of the personal data and the specific purposes for which it is processed. It must also tell people how to withdraw consent, exercise their rights and complain to the Board, and withdrawing must be as easy as consenting was.
The engineering consequence is that consent has to become data. A checkbox on a signup form that sets marketing_opt_in = true does not meet this standard. What we build instead is a consent ledger:
Purpose registry. Every processing purpose (order fulfilment, credit decisioning, marketing, model training) gets a stable identifier, a plain-language description and the data categories it needs.
Consent records as append-only events. Each grant or withdrawal is an immutable event with the purpose ID, the notice version shown, a timestamp and the channel. This gives you an audit trail if the Board ever asks you to show that consent was obtained.
Enforcement at the data access layer. Services check consent state before processing for a purpose, through a policy decision point or a sidecar, not by trusting each team to remember. Withdrawal propagates as an event, so downstream systems stop processing promptly.
Consent Manager readiness. Expose consent state through an API that a registered Consent Manager can read and update. Rule 4 opens their registration in November 2026.
The most common gap we find is purpose sprawl. Data collected "to deliver the service" quietly flows into analytics, personalisation and, increasingly, AI model training. Each of those flows needs either its own consent or a defensible legitimate use under the Act. Map them now.
Rule 6: What "Reasonable Security Safeguards" Means in Practice
Rule 6 is the most prescriptive part of the Rules, and it maps closely to controls that mature security teams will recognise. At a minimum it expects:
Encryption, obfuscation, masking or virtual tokens to protect personal data.
Access control over the computer resources that process personal data.
Visibility into access, through logs, monitoring and review, so unauthorised access can be detected, investigated and remediated.
Continuity measures, such as backups, so processing can continue if data is compromised or lost.
Log retention for at least one year, unless another law requires longer.
Contracts with Data Processors that require them to apply the same safeguards.
Our implementation priorities, in order:
Classify before you encrypt. You cannot protect what you have not found. We start with automated discovery across databases, object storage, data warehouses, log pipelines and SaaS exports, and tag columns and objects by personal data category. Expect surprises. Application logs and debugging dumps are the most common place we find unprotected phone numbers, Aadhaar-linked identifiers and health information.
Tokenise high-risk fields at the edge. For identifiers such as PAN, account numbers and health records, field-level tokenisation at ingestion means most downstream services never see the raw value. This shrinks the breach blast radius far more effectively than encryption at rest, which protects against stolen disks, not compromised applications.
Tie access to identity, not network. This is where DPDP and zero-trust architecture meet: every query against personal data should be attributable to a named human or workload identity, authorised for a purpose, and logged.
Make logs a compliance asset, not a liability. Rule 6 requires you to keep access logs for a year. Those logs must not themselves leak personal data, so log identifiers and tokens rather than raw values.
Rule 7: Building for the 72-Hour Breach Clock
Rule 7 has two parts. On becoming aware of a personal data breach, you must inform each affected Data Principal without delay, in plain language, covering what happened, the likely consequences, the steps you are taking and the steps they can take to protect themselves. You must also intimate the Board without delay and, within 72 hours, submit a detailed report on the facts, the cause, the extent, the mitigation and the notifications made. There is no materiality threshold. The duty applies to any personal data breach.
Seventy-two hours is very little time if you cannot answer the question "whose data was in that bucket?" Three capabilities make it achievable:
Detection that pages a human. Anomaly alerts on bulk reads, unusual export volumes and access outside normal patterns, routed into the same on-call rotation as production incidents.
Blast-radius queries ready in advance. Because personal data is already classified and access is logged (Rule 6), you can answer "which Data Principals were exposed through this credential in this window?" with a query rather than a forensic project.
A rehearsed playbook. Pre-approved notification templates in English and the main regional languages of your user base, a named decision-maker, and a tabletop exercise at least twice a year. Our incident-ready CI/CD practices apply here too: test the response path before you need it.
Remember that CERT-In's existing directions already require certain cyber incidents to be reported within six hours. DPDP does not replace that. Your runbook has to satisfy both.
Rule 8: Retention and Erasure Need a Data Lifecycle
Under the Act, personal data has to be erased once its purpose is served, unless another law requires you to keep it. Rule 8 and the Third Schedule make this concrete for large platforms: e-commerce and social media intermediaries with at least two crore registered users in India, and online gaming intermediaries with at least fifty lakh, must erase data after three years of user inactivity. Before erasing, they must notify the user at least 48 hours in advance so the person can log in and keep the account. Separately, every Data Fiduciary must keep the associated personal data, traffic data and logs for at least one year for purposes the Rules specify.
So you have a minimum retention period and a maximum retention period, and you have to apply both precisely. The patterns we use:
Retention policy as code. Each data category carries a retention rule in the data catalogue, and scheduled jobs enforce it. No manual purges.
Crypto-shredding for hard-to-reach copies. Encrypt each person's data under a per-user key. Deleting the key makes every copy unreadable, including copies in backups and snapshots, without rewriting immutable storage.
Erasure that reaches processors. Your erasure workflow must send deletion requests to every processor holding the data and record their confirmation.
Rules 10 to 16: Children, Significant Data Fiduciaries and Data Principal Rights
Children's data (Rule 10). Under the Act, anyone under 18 is a child. Processing their data requires verifiable consent from a parent or lawful guardian. The Rules accept verification using reliable identity and age details the business already holds, or a virtual token issued by an authorised entity, including through DigiLocker. A self-declared age checkbox does not meet the standard. EdTech, gaming and social platforms need a proper age-assurance flow, and the Act separately bars tracking, behavioural monitoring and targeted advertising directed at children.
Significant Data Fiduciaries (Rule 13). If the government notifies you as an SDF, you take on an annual Data Protection Impact Assessment and audit, due diligence to check that algorithmic software you deploy does not risk the rights of Data Principals, and possible localisation of categories of data the government specifies. For AI-heavy businesses, the algorithmic due diligence requirement is significant. It overlaps directly with the governance we recommend in our post on building secure AI agents.
Data Principal rights (Rule 14). People can request access, correction, completion and erasure, and nominate someone to exercise their rights. You must publish how to make these requests and resolve grievances within 90 days. At scale, this needs a self-service rights portal backed by the same data map you built for Rule 6, not an email inbox.
A 90-Day Starting Plan
For organisations starting now, this is the sequence we recommend. Each phase produces something the next phase depends on.
Days 1 to 30: discover and decide. Appoint an accountable owner. Run automated personal data discovery across production, analytics and logs. Build the purpose registry. Identify every Data Processor and every cross-border flow. Assess whether you are likely to be notified as an SDF.
Days 31 to 60: control the crown jewels. Tokenise the highest-risk fields. Put identity-bound, logged access in front of every personal data store. Stand up breach detection on bulk access patterns. Draft and rehearse the 72-hour playbook.
Days 61 to 90: make it self-operating. Ship the consent ledger and enforce it at the access layer. Automate retention and erasure, including processor deletion. Launch the Data Principal rights workflow. Then schedule a mock Board inquiry to test whether you can actually produce the evidence.
The Opportunity Behind the Obligation
It is tempting to treat DPDP as a cost centre. Our experience points the other way. The organisations that do this work well end up with something they did not have before: a precise map of their data, faster incident response, and a consent model that makes customers more willing to share data, not less. Those are the same foundations that responsible AI, data monetisation and enterprise sales due diligence all require.
May 2027 will arrive quickly, and the timeline may yet be shortened. The engineering takes longer than the paperwork, so start there.
If you would like an independent DPDP readiness assessment of your systems, our Cybersecurity & Compliance practice runs fixed-scope engagements that end in a prioritised, engineering-ready remediation backlog.