DPDP Act vs GDPR: A Comparison Framework for Indian Businesses
For Indian companies that already comply with the GDPR, most of the machinery carries over to the DPDP Act, but many of the judgements behind it do not.
- TYPE
- White paper
- POSITION AS OF
- October 2026
- READING TIME
- 18 min read
- FILE
FULL TEXT
DPDP Act vs GDPR: A Comparison Framework for Indian Businesses
Selecting and copying text is turned off on this page. To keep a copy, download the PDF.
Executive summary
Many Indian software, IT services and health-tech companies built a GDPR programme because European clients asked for one. With most duties under the Digital Personal Data Protection Act, 2023 (the DPDP Act) commencing on 13 May 2027, the question is how much of that programme can be reused for Indian users.
Our answer: most of the machinery carries over, much of the reasoning does not. The EU's General Data Protection Regulation (Regulation (EU) 2016/679, the GDPR) is calibrated to risk. Many duties switch on at a threshold, such as "risk", "high risk" or "large scale", or after a balancing test. The DPDP Act mostly draws fixed lines: a closed list of grounds, notice of every breach to every affected person, and one age of adulthood, 18. Copying GDPR judgements into India leads to under-compliance; reusing GDPR tools and evidence saves months.
- Carries over: security programme, data inventory, retention schedule, consent records, rights tooling, vendor contract discipline.
- Must be added: consent, or a listed legitimate use, wherever the GDPR programme relies on legitimate interests; breach notices to every affected Indian user and a 72-hour report to the Data Protection Board of India; parental consent for anyone under 18; grievance redressal and nomination; consent requests offered in Eighth Schedule languages.
- Can be dropped for Indian data: legitimate-interests assessments, portability and objection workflows, the EU representative, and transfer clauses for data leaving India. Impact assessments and a data protection officer become mandatory only on designation as a Significant Data Fiduciary.
- Does not change: GDPR duties for EU data. India has no EU adequacy decision, so EU-to-India transfers still need standard contractual clauses or another GDPR tool.
Start by sorting data into populations, because the DPDP Act treats a European client's data processed in Pune very differently from an Indian user's.
Background
This paper is for Indian companies that already process personal data of people in the European Union, as a processor for EU business customers or as a controller selling directly to people in the EU, and that now serve Indian users too. The DPDP vocabulary maps onto the GDPR's: a data fiduciary (s.2(i)) decides why and how personal data is processed, like a controller; a data processor (s.2(k)) acts on its behalf; a data principal (s.2(j)) is the individual, including a child's parent; a Significant Data Fiduciary (SDF, s.10) is a fiduciary the Central Government designates for factors such as the volume and sensitivity of its data, with added duties; and the Data Protection Board of India (the Board) inquires into breaches and imposes penalties.
Where things stand. The DPDP Rules were notified on 13 November 2025. Most of the Act and Rules commence on 13 May 2027, and consent manager provisions on 13 November 2026. The Board exists on paper, but no members had been appointed according to a Lok Sabha answer of 12 August 2026. MeitY consulted in January 2026 on a shorter transition; no change has been notified.
In the EU, the Commission's Digital Omnibus proposal of 19 November 2025 (COM(2025) 837) would, among other changes, require breach notice to an authority only where a high risk is likely, within 96 hours. It is still at committee stage in the European Parliament, so this paper uses the GDPR in force.
Four populations of data. Before mapping any control, list whose data you hold.
- EU clients' data, processed in India under contract with the EU client. The GDPR reaches you through the Article 28 processor contract and transfer clauses. Under s.17(1)(d), most of the DPDP Act does not apply, though accountability (s.8(1)) and reasonable security safeguards (s.8(5)) do.
- People in the EU you serve directly. The GDPR applies under Article 3(2). The DPDP Act also applies, because it covers digital personal data processed in India (s.3(a)) wherever the person lives. Read literally, s.17(1)(d) might cover a user abroad who contracts with you directly; in our view that reading is untested and should not carry a compliance programme.
- Indian users and Indian business customers' data. Fully within the DPDP Act.
- Your own staff and contacts. Indian employees' data rests largely on the employment use in s.7(i); EU-based staff remain under the GDPR.
Trayambic's study on GCCs and BPOs sets out the conditions of s.17(1)(d) in detail.
Legal framework
The rows run from the widest gap to the narrowest, in our assessment.
| Topic | GDPR | DPDP Act and Rules |
|---|---|---|
| Grounds | Six lawful bases, including legitimate interests (Art. 6(1)(f)) | Consent or a closed list of legitimate uses (ss.4, 6, 7) |
| Breaches | Authority within 72 hours where feasible, unless unlikely to result in a risk (Art. 33); individuals only if high risk (Art. 34) | Every affected data principal and the Board without delay; detailed Board report within 72 hours (s.8(6); Rule 7) |
| Children | Consent for online services from 16, or as low as 13 by member-state choice (Art. 8) | Under 18 for all processing; verifiable parental consent; no tracking, behavioural monitoring or targeted advertising (s.9; Rule 10) |
| Individual remedies | Compensation for material or non-material damage (Art. 82); representation by not-for-profit bodies (Art. 80) | Complaint to the Board after the grievance process (s.13(3)); penalties go to the Consolidated Fund of India (s.34); no compensation |
| Special data | Special categories, prohibited unless an Art. 9(2) exception applies | None; volume and sensitivity matter for SDF designation (s.10(1)) |
| Rights | Access, rectification, erasure, restriction, portability, objection, automated decisions (Arts. 15 to 22); one month, extendable by two (Art. 12(3)) | Access to a summary, correction and erasure, grievance redressal, nomination (ss.11 to 14); grievances within 90 days at most (Rule 14) |
| Automated decisions | No solely automated decisions with legal or similarly significant effects, subject to exceptions (Art. 22) | Accuracy, completeness and consistency where data is likely to be used for a decision affecting the person (s.8(3)) |
| Records | Record of processing, with a limited exemption below 250 employees (Art. 30) | None; fiduciary must prove notice and consent (s.6(10)); logs kept at least one year (Rule 6) |
| DPIA and DPO | DPIA where high risk is likely (Art. 35); DPO for public bodies and large-scale monitoring or special-category processing (Art. 37) | Only for SDFs: DPO based in India, independent data auditor, DPIA and audit every 12 months (s.10(2); Rule 13) |
| Representative | Required for non-EU entities caught by Art. 3(2), with exemptions (Art. 27) | No equivalent |
| Transfers | Adequacy, safeguards such as standard contractual clauses, or derogations (Arts. 44 to 49) | Permitted unless the Centre restricts a country (s.16(1)); none restricted; stricter sector rules prevail (s.16(2)) |
| Penalties | Up to €20 million or 4% of worldwide annual turnover, whichever is higher; a €10 million or 2% tier (Art. 83(4), (5)) | Schedule maximums by obligation: ₹250 crore for security safeguards, ₹200 crore for breach intimation or children's data, ₹150 crore for SDF duties, ₹50 crore residual |
| Consent | Freely given, specific, informed, unambiguous; withdrawal as easy as giving (Arts. 4(11), 7) | Also unconditional, by clear affirmative action, limited to necessary data, after an itemised notice (ss.5, 6; Rule 3) |
| Processors | Prescribed contract terms (Art. 28(3)); direct duties on processors | Fiduciary answerable for processors (s.8(1)); valid contract required (s.8(2)) |
| Reach | EU establishment (Art. 3(1)); offering goods or services to, or monitoring behaviour of, people in the EU (Art. 3(2)) | Digital personal data processed in India (s.3(a)); processing abroad linked to offering goods or services in India (s.3(b)); no monitoring limb |
Section 39, already in force, bars civil courts from matters the Board is empowered to decide. From 13 May 2027, s.44(2) omits s.43A of the Information Technology Act, 2000, under which a body corporate negligent in securing sensitive personal data must compensate the person affected. Narrower routes remain, such as a consumer complaint that disclosing personal information given in confidence is an unfair trade practice (Consumer Protection Act, 2019, s.2(47)(ix)).
Analysis
Risk thresholds versus fixed lines
A mature GDPR programme is full of recorded judgements: is this breach likely to result in a risk, is the processing high risk or large scale, does our interest override the person's? The DPDP Act removes most of these switches.
| GDPR threshold | Where it sits | DPDP position |
|---|---|---|
| Legitimate-interests balancing | Art. 6(1)(f) | Consent or a listed use |
| Risk before notifying the authority | Art. 33(1) | Every breach goes to the Board |
| High risk before telling individuals | Art. 34(1) | Every affected person is told |
| High risk before a DPIA | Art. 35(1) | No DPIA unless an SDF |
| Large-scale core activities before a DPO | Art. 37(1) | Designation by the Centre |
| Age between 13 and 16 by member state | Art. 8(1) | 18 for every purpose |
GDPR decision records, such as breach risk matrices and legitimate-interests assessments, therefore cannot be reused for Indian data. The tools that produce them often can.
In places the DPDP Act reaches further. Section 8(3) applies to any decision affecting the person, not only solely automated ones with significant effects. Nomination (s.14) has no GDPR counterpart. And breach notice to individuals has no express exceptions for encrypted data or disproportionate effort, unlike Article 34(3).
Replacing legitimate interests
This is the largest single change. In a typical SaaS programme, legitimate interests carry product analytics, service improvement, security monitoring, fraud checks and marketing to business contacts. None has a home in s.7. For Indian users, each purpose needs one of four answers.
- Part of the service the user asked for. It sits inside the consent for that service, or under s.7(a) where the user voluntarily provided the data for that specified purpose. With no contract ground, the purpose must be stated precisely.
- Its own consent. Analytics beyond what the service needs, AI model improvement with customer content, and marketing are separate purposes, each with an unbundled choice.
- Required by the Act itself. In our view, logging and monitoring that Rule 6 requires is part of operating the service lawfully; reusing those logs for marketing or profiling is not.
- Stop. Some processing, such as enriching contact records from third-party sources, has no workable ground.
Users who joined under a legitimate-interests notice gave no consent. Section 5(2) preserves pre-commencement consent, with a fresh notice as soon as reasonably practicable, but cannot turn legitimate interests into consent. Run a consent campaign before May 2027.
Breaches: no risk filter
One incident touching EU and Indian data runs three timetables.
- CERT-In: report a cyber incident within six hours of noticing it (CERT-In Directions, 28 April 2022).
- DPDP: tell each affected Indian data principal and the Board without delay, and give the Board a detailed report within 72 hours (Rule 7), with no risk threshold.
- GDPR: as controller, notify the authority within 72 hours where feasible unless the breach is unlikely to result in a risk, and individuals only if the risk is high; as processor, tell the controller without undue delay.
For Indian data, replace "should we notify?" with "how fast can we reach everyone?". Trayambic's breach-notification framework sets out the clocks.
Notices, consent records and children
Rule 3 asks for a notice that can be understood on its own, itemising the data and the specified purpose, with a means to withdraw consent, exercise rights and complain to the Board. The person must be able to read the consent request in English or any Eighth Schedule language (s.6(3)). Reuse the GDPR content, but write short Indian notices by purpose rather than translating the global policy.
Consent records carry over well. Under s.6(10), where consent is disputed the fiduciary must prove notice and consent; the timestamped records a GDPR consent platform keeps do this. Add the notice version and language.
Children are a sharper break. Article 8 of the GDPR deals with consent to online services offered directly to children. The DPDP Act treats everyone under 18 as a child for all processing, requires verifiable parental consent, and bans tracking, behavioural monitoring and targeted advertising directed at children. A B2B product should screen out under-18s at sign-up; Part B of the Fourth Schedule permits processing to verify that a user is not a child. Trayambic's ed-tech study covers products built for children.
Enforcement and liability
In the EU, fines scale with worldwide turnover and require intentional or negligent infringement (Court of Justice, Deutsche Wohnen, C-807/21, 5 December 2023). Individuals can claim compensation once they show damage caused by an infringement, with no seriousness threshold for non-material damage (Österreichische Post, C-300/21, 4 May 2023), and consumer associations can sue without a mandate where national law allows (Meta Platforms v Bundesverband, C-319/20, 28 April 2022).
In India, exposure is to Board penalties capped per obligation and weighed by factors such as the gravity and duration of the breach and mitigation (s.33(2)), plus what B2B clients can claim under contract. No compensation claims means lower litigation risk, not lower penalty risk, and the two highest maximums attach to exactly the duties where GDPR habits mislead: security safeguards and breach intimation.
Rights: what to switch on and off
A GDPR rights portal is a good base, with three changes. Access is a summary plus the identities of fiduciaries and processors the data was shared with. Rights under ss.11 and 12 run only for data processed on consent or s.7(a). And two duties are new: a grievance mechanism that a person must use before complaining to the Board (s.13), answered within a published period of at most 90 days (Rule 14), and nomination (s.14).
Portability (Article 20), objection (Article 21) and restriction have no DPDP equivalents. Keeping them for Indian users costs little but is not a legal duty. Withdrawal of consent does much of objection's work: processing must stop within a reasonable time (s.6(6)) and the data be erased unless a law requires retention (s.8(7)). Trayambic's article on data principal rights covers the workflow.
The human-review design built for Article 22 can stay. For Indian users, the legal hook is s.8(3): if an AI output feeds a decision about the person, the data behind it must be complete, accurate and consistent.
Processors and vendor contracts
The GDPR puts duties directly on processors: security (Article 32), breach notice to the controller (Article 33(2)) and controller status if they decide purposes and means (Article 28(10)). The DPDP Act makes the fiduciary responsible "irrespective of any agreement to the contrary" (s.8(1)) and allows a processor only under a valid contract (s.8(2)), so a processor's exposure is mainly contractual.
For an Indian SaaS company serving Indian enterprise customers as processor, the GDPR data processing agreement is a sound template with four changes: incident notice in hours, so the customer can meet Rule 7; logs and security evidence for Rule 6; erasure on instruction, which s.8(7)(b) requires the customer to secure; and sector clauses for RBI, SEBI or IRDAI-regulated customers. Trayambic's vendor contracts checklist covers drafting, and its GCC study covers the clash between Article 28(3)(a) and CERT-In reporting.
Transfers in both directions
India is not on the European Commission's list of adequacy decisions, which has 17 entries, most recently Brazil (January 2026). EU-to-India transfers therefore continue under standard contractual clauses (Commission Implementing Decision (EU) 2021/914) or another Chapter V tool. Clause 14 requires the parties to assess the destination's laws and practices. From 13 May 2027 that assessment should cover s.36 of the DPDP Act, which lets the Central Government require any data fiduciary or intermediary to furnish information, and which s.17(1)(d) does not switch off. The 2021 clauses are designed for importers not themselves subject to the GDPR; the Commission says clauses for importers caught by Article 3(2) are being developed.
Data leaving India needs far less: transfers are allowed unless the Centre restricts a destination, and none is restricted, so in our view no transfer clauses are needed. Sector rules on storage in India continue (s.16(2)). Trayambic's article on cross-border transfers covers data leaving India in detail.
The triage: carry over, add, drop
| GDPR artefact | Verdict for Indian data | What changes |
|---|---|---|
| Security programme (Art. 32) | Carry over | Check against Rule 6; logs for at least one year |
| Record of processing (Art. 30) | Carry over | Not required; add ground, population and s.17(1)(d) status |
| Consent records | Carry over | Add notice version and language (s.6(10)) |
| Rights portal (Arts. 15 to 17) | Carry over and extend | Name recipients; add grievance and nomination |
| Processor agreement (Art. 28) | Carry over and rewire | Hours, not undue delay; Rule 6 and 7 support |
| Retention schedule | Carry over and rewire | Erase when the purpose ends or consent is withdrawn (s.8(7)) |
| Legitimate-interests assessments | Drop and replace | Consent or a listed use, purpose by purpose |
| Breach risk matrix (Arts. 33, 34) | Drop for Indian data | Notify everyone affected and the Board |
| Age threshold of 13 to 16 (Art. 8) | Replace | 18, parental consent, s.9(3) ban |
| Portability, objection, restriction | Optional | No DPDP duty |
| DPIA and DPO (Arts. 35, 37) | Optional unless an SDF | Publish a contact person (s.8(9)) |
| EU representative (Art. 27) | Drop for Indian data | No equivalent |
| Transfer clauses for data leaving India | Drop | Watch s.16 and sector storage rules |
Worked example: a Pune SaaS company launches in India
The company (illustrative) sells a customer-support platform with AI reply suggestions. About 70% of its revenue comes from some 400 EU business customers, for whom it is a processor under Article 28 agreements and Module 2 and 3 clauses. It also sells a self-serve plan to EU freelancers as a controller, with an EU representative. Its GDPR programme has a record of processing, legitimate-interests assessments for analytics and email marketing, a DPIA for the AI feature, a breach runbook with a risk matrix, and a rights portal with data export. In 2027 it launches for Indian mid-market businesses and Indian self-serve users.
- Populations. Every dataset is tagged EU-client, EU-direct, India-client or India-direct. EU-client data keeps its GDPR controls and meets Rule 6, since s.8(5) survives s.17(1)(d). EU-direct users also get DPDP consent, because the company does not rely on the literal reading of s.17(1)(d).
- Indian enterprise customers. As their processor, it now promises incident notice within six hours with the facts their Rule 7 notices need, one-year logs, erasure on termination, and storage in India for two RBI-regulated customers.
- Indian self-serve users. As fiduciary, it writes Rule 3 notices in English and Hindi, with separate consents for analytics and marketing. Sign-up asks for date of birth and blocks under-18s.
- AI suggestions. The DPIA stays as an internal control. Indian content is not used to improve models without consent, and outputs feeding account decisions, such as suspension for abuse, are checked for accuracy under s.8(3).
- Rights. The portal adds a grievance form with a 30-day target, nomination, and named sub-processors in access responses. Data export stays as a feature.
- Breaches. The runbook gains an India branch: CERT-In within six hours, every affected Indian user and the Board without delay, the 72-hour report, and bilingual templates.
- Transfers. EU-to-India clauses stay, with the Clause 14 assessment updated. Indian data sits in Mumbai for regulated customers and Singapore for others.
The incremental effort (illustrative) is about a quarter of the original GDPR build, mostly consent design and breach notification.
Compliance framework
| Action | Owner | Legal basis | By when |
|---|---|---|---|
| Tag datasets by population and s.17(1)(d) status | Privacy lead | ss.3, 17(1)(d) | Dec 2026 |
| Map each legitimate-interests purpose to consent, a listed use or stop | Privacy lead and product | ss.4, 6, 7 | Jan 2027 |
| Revise the processor agreement for Indian customers | Legal | s.8(1), 8(2); Rules 6, 7 | Jan 2027 |
| Draft Indian notices by purpose, with language options | Legal and product | ss.5, 6(3); Rule 3 | Feb 2027 |
| Update the Clause 14 transfer assessment | Legal | GDPR Arts. 44, 46; SCC Clause 14 | Feb 2027 |
| Add an age screen for under-18 users | Product | s.9; Rule 10; Fourth Schedule Part B | Mar 2027 |
| Add an India branch to the breach runbook | CISO and legal | s.8(6); Rule 7; CERT-In Directions | Mar 2027 |
| Gap-check security against Rule 6 | CISO | s.8(5); Rule 6 | Mar 2027 |
| Run a consent campaign for existing Indian users | Product and marketing | ss.5(2), 6 | Apr 2027 |
| Extend the rights portal: recipients, grievance, nomination | Engineering | ss.11 to 14; Rule 14 | Apr 2027 |
| Publish the contact person and rights process | Privacy lead | s.8(9); Rules 9, 14 | May 2027 |
| Leadership sign-off and evidence pack | Leadership | s.8(1), 8(4) | 12 May 2027 |
Phased roadmap to 13 May 2027
- October to December 2026: population tagging; legitimate-interests mapping; decide which GDPR features stay global.
- January to March 2027: notices and consent design; processor agreement; breach runbook; age screen; Rule 6 gaps; transfer assessment.
- April to 12 May 2027: consent campaign; rights portal changes live; a breach drill with one EU and one Indian scenario; evidence pack.
- From 13 May 2027: run both regimes; track Board appointments, SDF designations, s.16 notifications and the Digital Omnibus.
Recommendations
- Sort data by population before mapping controls; s.17(1)(d) status decides how much of the DPDP Act applies.
- Reuse GDPR tools, not GDPR conclusions: re-run every legitimate-interests and breach-risk decision for Indian data.
- Make consent the default ground for Indian users, with separate choices for analytics, AI improvement and marketing.
- Build breach notification for scale: every affected person, fast, in more than one language.
- Keep portability, DPIAs and human review where they help the product, but do not mistake them for DPDP compliance.
- Keep EU transfer clauses and update the local-law assessment for India's new powers.
- Price Indian risk as regulatory and contractual, and watch the Digital Omnibus, which would widen the breach-notification gap if adopted.
Key takeaways
- Most GDPR machinery (security, inventory, consent records, rights tooling, vendor contracts) carries over to the DPDP Act; most GDPR risk judgements do not.
- The DPDP Act has no legitimate-interests ground: every purpose that relies on it needs consent, a listed legitimate use, or to stop for Indian users.
- Every breach affecting Indian data principals must be notified to each of them and to the Board, with a detailed report within 72 hours; there is no risk filter.
- EU clients' data processed in India under a foreign contract is largely exempt under s.17(1)(d), but security duties survive and India has no EU adequacy decision.
- Indian exposure is to Board penalties capped by obligation, not compensation claims; s.43A of the IT Act is omitted from 13 May 2027.
General information on the DPDP Act and Rules, as the law stood at the position date shown. It is not legal advice.
MORE WHITE PAPERS
ALL ARTICLES & WHITEPAPERS
Employee Data from Offer to Exit: A DPDP Lifecycle Framework
Employee data passes through nine stages, from the first CV to the last reference call, and the DPDP Act asks a different question at each: which ground, what notice, how long, and what can go wrong.
Privacy by Design for Product Teams: Building DPDP Into the Build
The DPDP Act never says 'privacy by design', but its duties on consent, accuracy, security, erasure and children can only be met by controls built into the product before launch.
Retention, Deletion and Logs: A Defensible DPDP Schedule
The DPDP Act says erase personal data when its purpose ends, but other laws, two one-year floors in the Rules and CERT-In's log directions decide what must stay, and this whitepaper shows how to reconcile them in one schedule.