DPDP for Engineers: What Changes in Your Code vs GDPR

If your product already does GDPR — a consent banner, a data-export endpoint, a delete flow — India's Digital Personal Data Protection Act will look familiar. Same shapes: a controller (DPDP calls it a data fiduciary), a processor, a data subject (data principal), consent, and a set of user rights. It's tempting to assume your GDPR build covers India too.

Mostly, it does. But a handful of DPDP rules are stricter than GDPR in ways that change actual code paths — not legal boilerplate, but the conditions on a consent check, the trigger on a breach pipeline, the age in an if-statement. Those deltas are where teams get caught. Here's what's the same, what's different, and what each difference means for what you build.

DPDP and GDPR rhyme

Start with the reassuring part. The skeleton maps almost one-to-one:

If you have a working GDPR implementation, you're perhaps 70% of the way to DPDP. The records, the processor agreements, the security-safeguards expectation, the access-and-erasure machinery — that all carries. The remaining 30% is the deltas below, and they're the ones worth coding for deliberately.

Delta 1: consent, not legitimate interest

This is the big one for most apps. GDPR gives you Article 6(1)(f) "legitimate interests" — a lawful basis to process data without explicit consent when you have a genuine business need that doesn't override the user's rights. A lot of analytics, fraud-prevention, and some marketing rides on it.

DPDP has no broad legitimate-interest basis. Processing rests on consent, plus a short, enumerated list of "legitimate uses" (things like a service the user requested, legal obligations, emergencies). Anything you justified under GDPR's legitimate-interest umbrella — behavioral analytics, profiling, marketing — generally needs explicit consent under DPDP.

In code, that means the processing you currently run unconditionally has to move behind a consent gate:

# GDPR-era: ran for everyone under "legitimate interest"
track_behavioral_analytics(user, event)
 
# DPDP: gate it on a recorded, purpose-specific consent
if consent.granted(user, purpose="analytics"):
    track_behavioral_analytics(user, event)

If your consent model only records a single yes/no, you'll need to make it purpose-specific, because consent for "run the service" doesn't cover "profile me for ads."

Delta 2: a child is anyone under 18

GDPR sets the digital-consent age at 16 (member states can lower it to 13). DPDP sets it at 18. That single number reclassifies a large slice of your users as children, and for children DPDP requires verifiable parental consent and prohibits behavioral tracking and targeted advertising aimed at them.

In code: your age gate is 18, not 16; you need a durable "this is a child" attribute that propagates to your analytics and ad layers (not just the UI); and you need a parental-consent flow before processing a minor's data. A GDPR build with a 16 threshold and no parental-verification path is under-compliant for India by default.

Delta 3: breach notification has no risk threshold

Under GDPR, you notify the supervisory authority within 72 hours if the breach poses a risk, and notify affected individuals only if the risk is high. There's a built-in triage step.

DPDP removes the triage. A personal-data breach must be reported to the Data Protection Board and intimated to every affected data principal — without a harm-severity threshold filtering who gets told. Practically, that raises the bar on your incident tooling: you can't just decide "low risk, no notification." You have to be able to enumerate exactly which data principals were affected and reach them. (We covered the timeline mechanics here.)

If your logging can't answer "whose data was in this breach?" precisely, that's the gap to close before you need the answer under pressure.

Delta 4: notice is itemized and multilingual

GDPR wants transparent information; DPDP is more prescriptive about the consent notice. It must be a standalone, itemized notice describing the personal data and the specific purposes, and it must be available in English or any of the 22 languages in the Eighth Schedule of the Constitution, at the user's option.

In code, your consent notice stops being a paragraph of prose and becomes structured, per-purpose, and localizable — an itemized list of (data, purpose) pairs you can render in multiple languages and tie each consent record back to.

Delta 5: fixed penalties and an India-resident DPO

Two more differences that shape priorities rather than code paths:

• Penalties are fixed amounts, not a percentage of turnover. GDPR caps fines at 4% of global revenue; DPDP specifies fixed penalties up to ₹250 crore per instance. The risk math is different — a single serious lapse carries a defined, large number.
• Significant Data Fiduciaries have extra duties: an India-resident Data Protection Officer, periodic Data Protection Impact Assessments, and independent audits. If you're large or processing sensitive data at scale, plan for these.

What stays the same

Don't rebuild what already works. Your GDPR investments largely transfer: data-principal access and erasure (DSAR), the obligation to keep records, processor contracts, and "reasonable security safeguards." The machinery of rights and records is shared — it's the conditions and triggers (consent vs legitimate interest, 18 vs 16, all-breach vs risk-based) that differ.

The through-line: be able to prove it

Both laws reward the same thing — an auditable record. When a regulator or a data principal asks "what did this user consent to, when, and have you honored their deletion request?", the answer has to be producible, not reconstructed. That's an architecture decision: record consent and data events immutably, with purpose and timestamp, the moment they happen.

This is how NamoID is built. Consent and provider connections are written to an append-only event store with their purpose, scope, timestamp, and actor; a data-principal export assembles a user's complete history from those events; and deletion cascades to a soft-delete plus a tombstone event, so "we deleted this user" is itself on the permanent record. The result is that the DPDP deltas above — purpose-specific consent, child flags, breach enumeration, rights fulfillment — all read off the same immutable trail instead of being bolted on per feature.

FAQ

Does my GDPR setup make me DPDP-compliant? Largely, but not entirely. The deltas — consent instead of legitimate interest, under-18, all-breach notification, multilingual itemized notice — need specific changes. The shared 70% (rights, records, processor terms) carries over.

Can I rely on legitimate interest for analytics in India? No. DPDP has no broad legitimate-interest basis; analytics and marketing generally need explicit, purpose-specific consent.

Is the child age really 18? Yes — higher than GDPR's 16. More of your users are "children" under Indian law, with verifiable parental consent required.

When does this bite? Substantive obligations are enforced from 2027, but the engineering work — purpose-specific consent, age-gating, breach enumeration, an immutable audit trail — is worth doing now; retrofitting it later is far harder.

Build the deltas in, not the whole thing again

DPDP isn't a second GDPR project; it's a GDPR project with sharper conditions. Move the processing you justified under legitimate interest behind purpose-specific consent, set the child age to 18 with a real parental-consent path, make your breach pipeline enumerate every affected user, and localize an itemized notice — then prove all of it with an immutable record.

NamoID gives you that record by default: an identity layer with consent-as-events, data-principal export, and deletion tombstones in an append-only audit trail. If you're porting a GDPR build to India, that's the part you don't want to hand-roll.