DPDPA Compliance for Engineering Teams: India's Digital Personal Data Protection Act in Practice

India’s Digital Personal Data Protection Act — DPDPA, also written DPDP Act 2023 — has been the most-anticipated and most-misunderstood piece of Indian tech law of the decade. It was passed in 2023, notified in stages through 2024, and as of early 2026 is in full enforcement with the first significant penalty actions being taken by the Data Protection Board. For product teams operating in India, this is no longer hypothetical.

I want to write this for engineers — not for lawyers — because most of the compliance work falls on the engineering side, and most of the GDPR-shaped intuitions transfer only partially. There are parts of DPDPA that are stricter than GDPR. There are parts that are looser. There are parts that don’t exist in GDPR at all. Treating DPDPA as “GDPR with extra steps” produces architectures that fail audit.

The legal model in one paragraph#

DPDPA defines a Data Principal (the natural person whose data is processed), a Data Fiduciary (the entity determining the purpose and means of processing — equivalent to a GDPR Controller), and a Data Processor (a third party processing on behalf of a fiduciary). It defines obligations of the fiduciary — purpose limitation, lawful processing, reasonable security, breach notification, retention limits, and rights of the principal. It establishes the Data Protection Board of India (DPBI) as the supervisory authority, with the power to levy administrative penalties up to ₹250 crore (~$30M) per category of breach. It applies extraterritorially: a foreign entity processing data of Indian principals, while offering goods or services in India, is in scope.

That paragraph is the entire legal frame. Now the engineering reality.

Where DPDPA matches GDPR#

For teams already running GDPR programs, the carryover is large.

• Lawful basis for processing. Consent is the primary basis; the others (legitimate use, legal obligation, etc.) are narrower than GDPR’s six bases but conceptually similar.
• Purpose limitation. Data collected for one purpose cannot be used for another without re-consent. Engineering implication: purposes must be encoded as metadata on every data flow, and downstream systems must enforce purpose checks.
• Retention limits. Data must be deleted when no longer needed for the specified purpose. Engineering implication: every record needs a retention tag and a deletion job.
• Rights of the principal. Access, correction, erasure, grievance redressal. Engineering implication: a customer-facing rights portal and an internal DSAR (data subject access request) workflow are non-negotiable.
• Privacy by design. Not literally a DPDPA term, but the law’s structure assumes it. Engineering implication: data-minimization and consent-management are baked into product design, not bolted on.

If your GDPR program is real, this carryover is straightforward. If your GDPR program was performative — checkbox cookie banners and a quiet privacy policy — DPDPA will find the gaps.

Where DPDPA differs#

Five differences matter for engineering.

Consent must be free, specific, informed, unconditional, unambiguous, and limited to the necessary purpose. GDPR has similar wording but DPDPA’s “unconditional” is stricter. You cannot make the use of your service conditional on consent for unrelated processing. If you tie newsletter sign-up to product use, that consent is invalid. Engineering implication: consent flows must offer real choice, and the system must function correctly when the user declines optional consents.

Consent notice must be available in English plus 22 scheduled languages. This is a real engineering ask. Most production privacy programs in India have implemented this with a language-routing layer on the consent banner that maps device locale or user preference to a translated notice. The translations themselves are typically maintained as content collection — not hard-coded — so legal can update text without a deploy.

Cross-border data transfer. DPDPA permits cross-border transfer except to countries notified as restricted by the government. As of early 2026, no countries are notified, so in practice transfer is unrestricted, but the framework allows future notification. Engineering implication: data-flow inventories must track which countries data is transferred to, and architectures should anticipate the possibility of a future “this country is restricted” notification.

No explicit category of “sensitive personal data.” GDPR carves out health, biometric, political, sexual orientation, etc. as special categories with stricter rules. DPDPA does not — all personal data is governed by the same framework, with extra obligations only for “Significant Data Fiduciaries” (large processors notified by the government). Engineering implication: you do not need a separate sensitive-data lane, but you do need to monitor whether your processing volume or sensitivity will get you classified as SDF.

Children’s data. Anyone under 18 is a child under DPDPA, and verifiable parental consent is required for any processing. This is stricter than GDPR’s 16 (or 13 in some member states). Engineering implication: age verification is required for any product that might attract minors, and the verification has to be verifiable — a self-declared age gate is not sufficient if a regulator audits.

Breach notification within 72 hours, to the principal and to the DPBI. GDPR is 72 hours to the regulator but only “without undue delay” to data subjects. DPDPA requires notification to both within 72 hours. Engineering implication: breach detection and notification tooling must reach end-users in 72 hours, not just the regulator.

The Significant Data Fiduciary tier#

If you process large volumes of personal data or operate in a “sensitive” sector (the criteria are not yet fully specified but include healthcare, financial services, telecommunications, and platforms above certain user thresholds), you can be designated a Significant Data Fiduciary. The extra obligations include:

• Appointing a Data Protection Officer (a real role with named individual).
• Conducting periodic Data Protection Impact Assessments (DPIAs).
• Independent annual audits.
• Algorithmic processing transparency — for AI/ML systems making consequential decisions, you must be able to explain the logic to the principal.

If you are a meaningful-scale product in India, plan for the SDF designation. The first wave of designations was issued in late 2025; the second wave is expected in mid-2026.

A practical engineering checklist#

What we actually implement for DPDPA programs at clients in 2026:

1. A consent management platform with consent artefacts stored as signed, immutable records. Open-source tools like Indykite or commercial ones like Transcend, OneTrust, and Privado all work; we have built custom systems for clients whose consent volumes outgrew the SaaS options.

2. Data flow inventory maintained as code (not docs) — typically a YAML or JSON manifest checked into the data engineering repo, parsed by a build step, and used to generate the data-flow diagrams the auditor wants.

3. Purpose tagging on every record at creation. Every row in the database has a purpose tag. Every batch job has a purpose annotation. Every cross-system data flow is auditable to purpose.

4. Retention enforcement as a scheduled job, not a manual cleanup. Deletion is logged; the log is retained beyond the data itself.

5. DSAR workflow with a customer-facing portal, an internal ticketing integration (typically Jira or Linear), and a 30-day SLA. The 30 days is not a legal requirement under DPDPA itself but is the practical standard the DPBI has signaled.

6. Breach detection and notification pipeline that reaches both the DPBI and affected users within 72 hours. The notification template — to users — must be in the user’s preferred language.

7. Vendor inventory with DPA (data processing agreement) status for every third party touching personal data. Cloud providers, analytics tools, customer support platforms, email senders, ad networks — all on the list.

8. Age verification at signup for any service that does not explicitly bar under-18s. The standard pattern in 2026 is DigiLocker-mediated Aadhaar verification, which proves age without revealing the underlying Aadhaar number.

9. Privacy notice in 23 languages with a content-management workflow so legal can update without a deploy.

10. Internal training and tabletop exercises — engineering staff need to know what a DSAR looks like and how to respond. The first time you do this should not be when one arrives.

What’s coming in 2026 and 2027#

The DPBI has signaled three near-term priorities. First, finalizing the SDF designation criteria — expected mid-2026. Second, issuing detailed sectoral rules for healthcare and education — both expected late 2026. Third, beginning enforcement actions, which started in early 2026 with smaller penalties as the Board calibrates its posture.

The thing to watch is the interaction with the AA framework (covered in the AA implementation post) and with sector-specific regulations from the RBI and SEBI. The DPBI has stated that sector regulators have primary jurisdiction in their respective sectors, with the DPBI as backstop. This is a workable arrangement but it does mean engineering teams in regulated sectors are accountable to two regulators on data matters.

Where pdpspectra fits#

We run DPDPA programs end-to-end out of our Kathmandu, Boston, and London teams — gap analysis, technical implementation, the consent UX, the data flow inventory, and the operational rails. If you are entering the Indian market or scaling an existing operation past the threshold where DPDPA becomes operationally serious, our team does the platform work.

Related reading: the AA framework implementation post, the GDPR engineering implementation guide, and the cross-border data transfer post.

---

DPDPA is not GDPR-in-saris. Talk to our team about your Indian compliance program.