The honest answer on DPDP vs GDPR is that most of the machinery carries over and the single most important design decision does not. Your data inventory, records of processing, DPIA practice, security controls, processor contracts and rights-fulfilment tooling all survive the move to India's Digital Personal Data Protection Act, 2023. Your lawful basis does not.
That divergence turns a mapping exercise into an engineering project. GDPR gives you six lawful bases, and most commercial processing in the EU runs on legitimate interests or contractual necessity rather than consent. DPDP is built around consent and a closed list of legitimate uses in the Act. If your European programme leaned on legitimate interests — and almost every analytics, enrichment, fraud-scoring and marketing pipeline does — there is nothing to port it onto.
So the planning question is not how much of GDPR counts. It is which processing activities currently run without consent, and what the consent layer has to look like before mid-May 2027, when the operational rules bind.
What Your GDPR Programme Already Covers
A GDPR programme covers more of DPDP than teams expect: the reusable half is the evidence and the plumbing rather than the legal design. Genuine reuse, in rough order of value:
- Data inventory and records of processing. DPDP's notice must itemise the personal data and the specific purposes, which you cannot write without the inventory GDPR already made you build. Our GDPR asset inventory guide describes the artefact; DPDP consumes the same one.
- DPIA practice. Notified Significant Data Fiduciaries owe a Data Protection Impact Assessment and an audit every 12 months, and a team that already runs GDPR risk assessments has the method and the reviewers.
- Security control work. Encryption, masking, tokenisation, access control, logging and backups all appear in DPDP's security rule. The control is the same control; only the evidencing changes.
- Processor contracting. The Act permits a Data Fiduciary to involve a Data Processor only under a valid contract, and the security rule requires a safeguards clause in it. Your existing data processing agreements are the right starting draft.
- Rights-fulfilment tooling. The intake form, identity check, queue and SLA timer built for subject access requests serve DPDP rights requests against a different published response window.
- Incident response capability. Detection, triage, forensics and comms transfer intact. The runbook's timings do not.
What does not transfer is the reasoning layer: the lawful basis register, the legitimate interests assessments, and every product decision that rested on them.
Lawful Basis Is Where the Mapping Breaks
Lawful basis is where a GDPR-to-DPDP mapping stops being a mapping. GDPR's Article 6 offers six bases, and a mature European programme spreads its processing across consent, contract, legitimate interests and legal obligation, per purpose. DPDP's architecture is narrower: consent, plus certain legitimate uses the Act itself enumerates. There is no legitimate-interest basis of the GDPR kind to balance into.
Take a B2C fintech with a European product and an Indian launch:
- Product analytics and behavioural segmentation. Legitimate interests with an opt-out in the EU. Under DPDP it needs consent: itemised in the notice, captured as a discrete permission, and switchable off without breaking the signed-in experience.
- Data enrichment from third-party sources. A legitimate interests assessment and a notice update in the EU. Under DPDP you need a basis you probably do not have, because the person never saw the enrichment coming.
- Fraud and credit scoring. Often legitimate interests or legal obligation in the EU. Under DPDP, check it against the Act's legitimate uses first and treat consent as the fallback, not the reverse.
Three consequences follow for engineering. Consent becomes a per-purpose data structure rather than a boolean, because the notice itemises purposes. Withdrawal has to be as easy as granting was, which rules out consent captured in one tap and withdrawn only by emailing support. And pipelines downstream have to read consent state instead of assuming it, because a withdrawal must stop processing rather than flag an account.
Teams that cost this out usually find the consent layer is the largest line item in their DPDP programme, and that it sits in the product backlog rather than the compliance one. Our DPDP compliance checklist sequences it against the other eleven duties.
Want your GDPR lawful basis register mapped against DPDP?
Share your work email and we'll send the mapping worksheet we use to sort GDPR processing purposes into DPDP consent, legitimate uses, and the ones that need re-architecture.
DPDP vs GDPR: The Differences Side by Side
The DPDP vs GDPR differences that matter operationally are fewer than the comparison tables circulating online suggest, but each of the 10 dimensions below changes a build decision rather than a policy sentence.
| Dimension | GDPR | DPDP |
|---|---|---|
| Lawful basis | Six bases under Article 6; most commercial processing runs on legitimate interests or contractual necessity | Consent, plus certain legitimate uses enumerated in the Act; no legitimate-interest test |
| Roles | Controller and processor | Data Fiduciary, Data Processor, and Significant Data Fiduciary as a third tier |
| Third tier | No equivalent designation mechanism | The Central Government notifies a fiduciary, or a class of them, as significant |
| DPO trigger | Arises from criteria set out in the regulation | Arises from being notified; the DPO must be based in India and answer to the board |
| Breach: regulator | Article 33 notification to the supervisory authority within 72 hours | First intimation to the Board without delay; detailed submission within 72 hours of becoming aware |
| Breach: individuals | Article 34 communication where there is a high risk to rights and freedoms | Intimation to each affected Data Principal without delay, not risk-gated |
| Retention | Storage limitation; keep no longer than necessary | A one-year minimum for personal data, traffic data and processing logs, plus a three-year inactivity clock for three notified classes |
| Cross-border transfer | Chapter V: adequacy decisions, standard contractual clauses, derogations | Permitted, subject to requirements the Central Government may specify by order; localisation applies only to notified SDFs |
| Independent audit | Not a general requirement | A notified SDF appoints an independent data auditor and audits annually |
| Penalty structure | Maxima set as a percentage of global annual turnover or a fixed sum, whichever is higher | Seven Schedule bands with fixed rupee ceilings, the highest on the security-safeguards duty |
Breach Notification Runs Two Clocks, Not One
Breach notification is the divergence most likely to be missed, because the GDPR-shaped runbook looks close enough to pass review. GDPR's well-known 72-hour clock runs to the supervisory authority under Article 33, and communication to data subjects under Article 34 is required where the breach is likely to result in a high risk to their rights and freedoms. Two clocks, one of them risk-gated.
DPDP splits its two clocks differently. Each affected Data Principal must be told without delay, with the breach's nature, extent and timing, the consequences relevant to them, the mitigation under way, the safety measures they can take, and a contact who can answer their questions. The Board gets a first intimation without delay too, then a detailed submission within 72 hours of becoming aware — or a longer period it allows on written request.
Two defects appear when you read a GDPR runbook against that. It will under-notify individuals, because it waits for a high-risk determination DPDP does not ask for. And it will notify them late, because "without delay" is tighter than the 72 hours the team has internalised as the deadline for everything. A playbook built from our GDPR breach notification guide needs that branch rebuilt rather than retimed, with the extra content DPDP asks for.
Significant Data Fiduciary Has No GDPR Equivalent
The Significant Data Fiduciary tier has no GDPR equivalent, and that absence confuses teams in both directions. GDPR sorts everyone into controller or processor and scales obligations through risk-based tests you apply to yourself. DPDP adds a third tier the Central Government designates by notification — you do not opt in and you do not self-assess into it.
The difference shows up in the DPO question. Under GDPR the obligation arises from criteria set out in the regulation, so counsel can read the criteria and answer today. Under DPDP it arises from being notified, and until that happens the Significant Data Fiduciary duties do not apply to you at all.
A notification brings a DPO based in India who represents the entity, is responsible to its board of directors or equivalent governing body and is the grievance contact; an independent data auditor; a DPIA and an audit every 12 months with significant observations reported to the Board; due diligence that algorithmic software used to process personal data is not likely to risk Data Principals' rights; and the localisation duty for data the Central Government specifies. A GDPR-shaped controller and processor model has no slot for any of it, so design the roles now and document the escalation path rather than building the tier speculatively.
A Retention Floor Against a Storage Limitation Instinct
Retention is where a GDPR team's instincts work against them. Storage limitation trains you to delete early; DPDP's security rule requires retention of personal data, associated traffic data and processing logs for a minimum of one year from the date of processing, unless another law requires otherwise. That floor applies to everyone, not only to large platforms.
The floor is deliberate — an anti-tampering measure, which is why it sits inside the security rule rather than the retention rule. It collides head-on with deletion-by-default architecture. If your erasure job wipes audit logs along with the account, or your warehouse has a 90-day TTL on event data, you have a conflict to resolve rather than a policy to reword.
On top of the floor sits a three-year inactivity clock for three notified classes: e-commerce entities with at least two crore registered users in India, online gaming intermediaries with at least fifty lakh, and social media intermediaries with at least two crore. Those classes must erase personal data three years after the Data Principal last approached them or exercised a right, whichever is latest, unless another law makes retention necessary — and must warn the individual at least 48 hours beforehand that logging in will stop it. Nothing in GDPR requires a pre-deletion warning, so that is new code.
Cross-Border Transfer Is More Permissive Than Chapter V
Cross-border transfer under DPDP is more permissive than most teams assume and more permissive than GDPR's Chapter V machinery. Personal data may be transferred outside India, subject to requirements the Central Government may specify by general or special order concerning making that data available to a foreign State, or to a person or entity under its control or acting as its agency.
That is not an adequacy-and-SCC regime. Teams arriving from the India data protection vs EU comparison expect a transfer impact assessment, a clause library and a list of approved countries, and there is no Indian equivalent to find. The restrictive duty — not transferring specified personal data and its traffic data outside India — is a Significant Data Fiduciary duty, and bites only once you have been notified.
The practical advice is to stop treating transfers as the gating item they are under GDPR and spend that engineering time on consent before the mid-May 2027 cliff. Keep the transfer register you already maintain: an order under this rule would be easier to absorb with a current one, and enterprise customers will keep asking for it regardless.
How the Two Penalty Regimes Are Built
The two penalty regimes are built on different units, which makes headline comparisons useless. GDPR's maxima are a percentage of global annual turnover or a fixed sum, whichever is higher, so exposure scales with group size. DPDP's Schedule sets seven bands with fixed rupee ceilings, so exposure scales with the duty you breached.
The Schedule's bands reach up to 250 crore rupees for failure to take reasonable security safeguards to prevent a personal data breach; up to 200 crore rupees for failure to notify the Board or affected Data Principals of a breach, and the same ceiling for breaching the additional obligations relating to children; up to 150 crore rupees for breaching the Significant Data Fiduciary obligations; up to 10,000 rupees for a Data Principal's own duties; and up to 50 crore rupees for any other contravention of the Act or Rules.
Two things are worth saying plainly, because both circulate as fact. The 250 crore figure is not a general-purpose number — it attaches only to the security-safeguards duty, and most contraventions fall into the 50 crore residual band. And penalties cannot be doubled; claims of 500 crore exposure have no basis in the Act. Every band reads "may extend to," and the Board must weigh the breach's nature, gravity and duration, the data affected, repetition, gain realised or loss avoided, mitigation taken, proportionality and the penalty's likely impact. Prompt mitigation is a statutory factor, which is a reason to make incident response good rather than merely documented.
Does GDPR Compliance Cover DPDP? Questions Teams Ask
Does GDPR compliance cover DPDP? These are the questions teams ask once they have seen the differences and have to decide what to build, in what order, before the operational rules bind.
Partly, and the part it does not cover is the expensive one. Your data inventory, records of processing, DPIA practice, security controls, processor contracts, rights-fulfilment tooling and incident response capability are all genuine reuse. Lawful basis is not: DPDP is built around consent and the Act's enumerated legitimate uses, with no legitimate-interest balancing test, so processing you justified that way in the EU needs a new basis and usually a new consent flow. Breach timings, the one-year retention floor and the Significant Data Fiduciary tier also need fresh work rather than a mapping.
Only as a starting point. DPDP's notice must stand on its own, understandable independently of anything else you publish, and must itemise the personal data together with the specific purposes and the goods, services or uses the processing enables. It must also give the communication link and the other means by which a person can withdraw consent, exercise rights and complain to the Data Protection Board. Most EU banners describe categories rather than itemising data, and route withdrawal through a preference centre harder to reach than the original accept button — which fails the requirement that withdrawal be comparably easy.
Only if you are notified as a Significant Data Fiduciary. The Act then requires a Data Protection Officer based in India who represents the entity, is responsible to its board of directors or equivalent governing body and is the contact point for grievance redressal, so an EU-based DPO does not satisfy it. Every Data Fiduciary still has to publish contact details for someone who answers questions about its processing, and that person can sit anywhere.
Not unchanged. The security rule sets a minimum one-year retention period for personal data, associated traffic data and processing logs from the date of processing, unless another law requires otherwise, and that floor applies to every Data Fiduciary. A pipeline that purges everything attached to an account the moment a GDPR erasure request lands will cut into data the Rules require you to keep. Separate the records that satisfy a rights request from the logs that evidence processing, and give each its own clock.
Mid-May 2027, eighteen months after the Rules were published in the Gazette on 14 November 2025. That tranche carries notice, consent, security safeguards, breach intimation, retention, rights and cross-border transfer, and it is a single cliff rather than a ramp. The Board is already constituted, so the enforcement machinery will exist before the duties bind.
Map your GDPR programme against DPDP in 30 minutes
Book a demo and we'll walk your lawful basis register, breach runbook and retention policy against the DPDP Rules, marking what your GDPR work already satisfies and what has to be rebuilt.
Book a demo
Re-Architect the Consent Layer First
Sequence this by what takes longest to build, not by what reads worst in a gap analysis. The consent layer is the long pole: per-purpose records, a withdrawal path as easy as the grant, and pipelines that read consent state instead of assuming it. That work lands in the product roadmap, competes with revenue features and cannot be bought as a policy document, which is why it should start before the retention and breach work — both of which are weeks of engineering against a clear specification.
Everything else follows from an inventory you probably already have, and you have until mid-May 2027. Sort each processing purpose into consent, a legitimate use under the Act, or needs-re-architecture; fix the breach runbook's individual-notification branch; reconcile deletion jobs against the one-year floor; and keep the Significant Data Fiduciary duties designed but unbuilt until a notification arrives. The primary source is the Ministry of Electronics and Information Technology at meity.gov.in, and the notice and security rules are worth reading in full rather than through a summary.
For the full duty-by-duty sequencing with the sector overlays on top, start from the DPDP compliance checklist and treat this comparison as the triage pass that says which items your GDPR programme already paid for.
