India finally has a new data protection law- the Digital Personal Data Protection Act, 2023 (DPDPA). Overall, like the EU’s General Data Protection Regulation (GDPR) (and most data protection laws around the world) the DPDPA the reflects some key privacy principles such as purpose limitation[1], data minimisation[2], accuracy[3], storage limitation[4], accountability[5] and data subject rights.[6] But it differs from the GDPR in certain key respects. The Indian law is more consent-centric, allows for lesser flexibility in breach reporting obligations, has a higher age of consent, among other differences. In this blog post, we examine the key differences between these laws and how GDPR compliant organisations should approach the DPDPA. 

Data categorisation Applies uniformly to all personal data; excludes publicly available data. No special categories of data​ Publicly available data in scope. Recognises special categories of data such as racial/ethnic; political views; biometrics; etc.   ​
Grounds for processing Consent centric; legitimate interests limited​ Broader legitimate interests for processing​
Types of actors Fiduciaries; Significant Fiduciaries; Processors (no direct obligations on Processors)​ Controllers; Processors​
Children’s data Age of consent 18; verifiable parental consent.​ Age of consent 13-16; reasonable efforts for parental consent​
Retention Timelines Rules to prescribe specific timelines for data retention​ Controllers determine retention period subject to justification​
Breach Notification All data breaches to be reported to DPB and data principals. Rules to be prescribed.​ Risk based breach reporting; Only high-risk breaches to be reported to data subjects​
Cross border flows Permitted except to blacklisted countries​ Permitted through adequacy decisions, SCCs, BCRs. ​
Consent Managers New institutional mechanism for consent management. Must be registered with DP Board​ NA​

 The dramatis personae

Both the legislations recognise the following actors: (i) a data subject[7] – known as ‘data principal’[8] under the DPDPA – who is the individual to whom the data relates, (ii) a data controller[9] – known as ‘data fiduciary’[10] under the DPDPA – who determines the purpose and means of data processing and (iii) a data processor[11], who processes data on behalf of the data controller (or data fiduciary).

 Unlike the GDPR, the DPDPA creates another category of ‘significant data fiduciaries’[12] (SDFs). The Indian government can designate any data fiduciary or class of data fiduciaries as SDFs based on certain factors, including the volume and sensitivity of the personal data they process, the risk to data principal’s rights and the impact on India’s national security.[13] SDFs are subject to higher obligations under the DPDPA including the appointment of a data protection officer[14] and an independent auditor to carry out data audits.[15] They will also need to periodically carry out data protection impact assessments[16] and undertake other measures which the government can prescribe through rules.[17] It is likely that the government will notify a class a businesses, for instance companies working in healthtech or fintech, as SDFs instead of individually notifying each company.

The Indian law recognises the role that data processors play. But it does not place any specific obligations on them. The GDPR places specific obligations on processors including providing guarantees with respect to appropriate technical and organisational measures to meet the prescribed requirements[18] and processing data only pursuant to a binding contract with the data controller[19]. In the absence of specific legal obligations on processors under the DPDPA, fiduciaries engaging processors will have to ensure that their contracts are water-tight, because the ultimate liability under the law will rest on them alone. At this stage, data fiduciaries must evaluate if their contracts with processors sufficiently capture their obligations and indemnify them from lapses on the latter’s part.

What data does the law apply to?

Both laws cover ‘personal data’ – which is data relating to an identifiable natural person. But, unlike the GDPR (which applies to all personal data, digitised or not)the DPDPA applies only to personal data that is in digital form or is digitised after its collection.[20] Businesses in India which maintain physical entry-exit registers, or hotels which collect physical copies of guest ID cards, can take some comfort in knowing that the law does not apply to data collected entirely offline. But for most digital businesses this is an insignificant difference.

The GDPR recognises sensitive data as ‘special categories of personal data’ which include racial or ethnic origin, political opinions, religious or philosophical beliefs, genetic or biometric data, data concerning health or data concerning a person’s sex life or sexual orientation.  Processing such data requires heightened obligations such as explicit consent. The DPDPA does not specifically classify any types of personal data as sensitive.

Companies typically begin their data protection compliance journeys by inventorising the data they collect and classifying it into personal data, sensitive personal data and non-personal data. While this classification is not strictly necessary for the Indian law, it is still a useful exercise to carry out, and can give useful insights on the likelihood of classification as an SDF. SDFs also need to carry out data protection impact assessments, and this gradation of data is an important part of these exercises.

Publicly available data out of scope

An interesting feature of the DPDPA is that it takes ‘publicly available’ personal data entirely out of the scope of the legislation.[21] This essentially means that if you scrape personal data from a user’s an individual’s blog, none of the obligations under the law apply to you. Similarly, if the personal data you process is also publicly available elsewhere, the law would still not apply to this data. This is in contrast to the GDPR, where irrespective of where personal data is sourced from or is otherwise available, the obligations of the law continue to apply. Some commentators speculate that the Indian law carves this exemption to facilitate the training of AI models[22], which require large scale data scraping. However, given that the Indian law is silent on the definition of ‘publicly available data’, and how tedious it would be map whether a publicly available alternative is available for each data point you process, the utility of this exemption remains to be seen.

The big difference: Grounds for Processing – legitimate interests vs legitimate uses

Under both the GDPR and the DPDPA you need to identify a legal basis (like consent) to process any personal data. The GDPR has six legal bases on which you can process personal data including consent and ‘legitimate interests’. Given the flexibility that it affords, the ‘legitimate interests’ ground is often the first port of call for businesses complying with the GDPR.[23] While the GDPR does not provide an exhaustive list of activities that would qualify as a legitimate interest, some examples include processing for direct marketing purposes, preventing fraud or ensuring the network and information security of IT systems.[24]

DPDPA also allows for the processing of personal data for certain ‘legitimate uses’.[25] But this is not the same as the wider ‘legitimate interests’ ground that the GDPR provides. The DPDPA lists nine legitimate uses, out of which the ones relevant for businesses are: (i) voluntary provision of data when the user voluntarily provides data to the specified purpose. For instance, when a customer  provides their personal details for you to be able to draw up a receipt for the purchase; (ii) compliance with any judgement/law in India; (iii) employment related purposes.​ The scope of this provision does not enable a wide range of data processing activities, unlike the legitimate interests ground in the GDPR.

In sum, the Indian law is far more consent centric, and has a much narrower category of legitimate uses. And so, businesses must account for this when evaluating DPDPA compliance. You will need to update privacy policies, and user journeys which rely heavily on legitimate interests; and also collect explicit consent for many processing activities. You must also carefully evaluate the exemptions provided under the Indian law. For instance, data collection for fraud prevention could be justified as being necessary for the prevention of a crime, which is a processing activity exempt[26] from the usual notice and consent framework.

Processing of children’s data

The age of consent under the GDPR ranges between 13-16 years of age, depending on the individual member state. [27] In instances where the individual is below the age of consent, the entity processing data has to make ‘reasonable efforts’ to ensure that it secures parental consent.[28] While not defined under the GDPR, the two factors considered by regulators in determination of ‘reasonable efforts’ includes (i) inherent risk and (ii) the available technology.[29] For instance, asking for a child’s email address for a subscription to a newsletter is lower on the risk spectrum compared to facilitating participation in an unmoderated chatroom. Therefore, the former would require a comparatively lesser degree of effort for age verification.

The DPDPA, however, treats everyone below 18 years of age as a child.[30] Processing of personal data of an individual below the age of 18 requires ‘verifiable parental consent’.[31] Additionally, the DPDPA also prohibits any behavioural monitoring, targeted advertising or tracking targeted at children[32] and any processing activity that may be detrimental to the child’s well-being.[33] While certain classes of data fiduciaries and certain purposes for processing of data are exempt from these restrictions, these will be notified through subsequent rules.[34]

The requirement of ‘verifiable parental consent’ under the DPDPA is similar to the obligation under the US Children’s Online Privacy Protection Rule (COPPA Rule).[35] For the DPDPA, the standard for what counts as ‘verifiable parental consent’ will be notified through rules.[36] According to media reports, the government is keen to find a technical solution to prescribe as a standard, which may include relying on the Government’s DigiLocker service, to map parent-child relationships based on government issued identity documents.[37]

Given the difference in the threshold of establishing parental consent in both legislations, entities subject to DPDPA will likely need to rearchitect their age gating and parental consent frameworks based on the standards prescribed by the Indian government.

 Data retention periods

There is no prescribed retention period for data collected under the GDPR. It requires that entities retain data only until it is necessary for the purposes for which it was collected.[38] While not a carte blanche, the provision vests a degree of flexibility with the data processing entity to determine the retention period for the data it collects.

The DPDPA follows a similar standard, but with a more prescriptive approach to deciding when a purpose is served. [39] It specifies that if the user does not avail of the service for a period of time, or if they don’t exercise their rights for a period of time: the purpose will automatically be deemed to be served. [40] For instance, if a user downloads an app and then does not use it for X number of months; the purpose will be considered fulfilled and the user data will have to be deleted. The government will define that this X period is through subsequent rules.[41]

Therefore, the DPDPA provides far less flexibility in terms of determining data retention periods. Companies operating in India will need to update and ensure that their data retention policies are aligned with the timelines notified under the rules.

Reporting of data breaches

Under the GDPR, breaches which are likely to result in risks to the rights and freedoms of individuals must be reported to the supervisory authority[42] Breaches which pose a higher risk also need to be reported to data subjects.[43] However, if in the assessment of the controller, a data breach is unlikely to result in a risk to the rights and freedoms of individuals, it need not reported at all.[44]

In contrast, the DPDPA requires all personal data breaches to be reported to both the impacted users and the Data Protection Board (DPB).[45] The government will provide more clarity on the manner and the form of these breach reports through rules.[46]

Therefore, organization’s data breach response plans will need to be updated to account for these differences between the Indian law and the GDPR. It is also important to account for the fact that data fiduciaries already have an obligation to report data breaches and other specified cyber incidents to Computer Emergency Response Team–India (CERT-In).[47] The DPDPA does not change this obligation.[48] So, data fiduciaries may have to file at least two reports for each data breach.

 Cross border flow of data

The GDPR follows a ‘whitelist’ or adequacy regime, where transfer of personal data outside the European Economic Area is allowed, subject to the recipient country offering an adequate level of protection for personal data in the assessment of the European Commission.[49] Personal data can also be transferred pursuant to standard contractual clauses or Binding Corporate Rules approved by data protection authorities, or where individuals provide explicit consent to such transfer.[50]

The DPDPA, in contrast, has adopted a ‘blacklist’ regime where data transfers are generally allowed, unless the transfer is to a country that is notified by the government.[51] Since cross border data transfers, by default, are permissible under the DPDPA unless there is an express restriction, the legislation enables free and flexible data transfers.

The DPDPA does not mention the criteria for the notification of countries under the blacklist.  Indicatively, these factors could be based on India’s geopolitical equations with countries.[52]

 Consent Managers

The DPDPA envisages ‘consent managers’ as an institution registered with the DPB, which would enable users to give, review and withdraw their consent through an accessible, transparent and interoperable platform.[53] More details about the consent management framework will come through rules.[54]

Consent management-based frameworks have been envisaged by the Indian government even before the DPDPA. The Reserve Bank of India’s Account Aggregator (AA) Framework[55] provides an ecosystem for individuals to share their data across regulated entities through an AA. The AA is a data blind intermediary which enables individuals to exercise granular control over the use of their data. Similarly, NITI Ayog’s Data Empowerment and Protection Architecture (DEPA)[56] draft policy envisaged the idea of data blind ‘consent managers’ which enable the flow of data from data sources to data users based on user consent. It is likely that the DPDPA ‘consent manager’ will be based on such these existing conceptualisations of a framework.

Once the consent management framework is developed under the DPDPA, the next step for businesses would be to align their consent architecture with it. This also presents a business opportunity for companies to act as consent managers, facilitating sharing of data with diverse users within a secure ecosystem and to innovate on business models which plug into the government’s vision.


In summary, while companies who have carried out a GDPR compliance exercise have a head start on DPDPA compliance, the differences require a close examination. Organizations must undertake a granular review of their data processing activities, data processor contracts, consent management and age gating mechanisms, and data retention and breach reporting practices to ensure compliance with the Indian law standards. A failure to adapt could result in legal and monetary repercussions, making it imperative for companies to get started early. Lastly, the rule making process will bring in greater clarity on granular compliance requirements. It is therefore important that organisations actively engage in the rule making process and provide inputs in the consultation stage.

 Authored by:  Ayush Verma, Associate and Aman Taneja, Principal Associate with inputs from Sreenidhi Srinivasan, Partner at Ikigai Law.


[1] Article 5(1)(b), the GDPR; Section 7, Digital Personal Data Protection Act, 2023

[2] Article 5(1)(c), the GDPR; Section 4, Digital Personal Data Protection Act, 2023

[3] Article 5(1)(d), the GDPR; Section 8(3), Digital Personal Data Protection Act, 2023

[4] Article 5(1)(e), the GDPR; Section 8(7), Digital Personal Data Protection Act, 2023

[5] Article 5(2), the GDPR; Section 8, Digital Personal Data Protection Act, 2023

[6] Section 11-Section 14, Digital Personal Data Protection Act, 2023; Chapter 3, the GDPR

[7] Article 4(1), the GDPR

[8] Section 2(j), Digital Personal Data Protection Act, 2023

[9] Article 4(7), the GDPR

[10] Section 2(i), Digital Personal Data Protection Act, 2023

[11] Section 2(k), Digital Personal Data Protection Act, 2023

[12] Section 2(z), Digital Personal Data Protection Act, 2023

[13] Section 10(1), Digital Personal Data Protection Act, 2023

[14] Section 10(2)(a), Digital Personal Data Protection Act, 2023

[15] Section 10(2)(b), Digital Personal Data Protection Act, 2023

[16] Section 10(2)(c)(i), Digital Personal Data Protection Act, 2023

[17] Section 10(2)(c)(iii), Digital Personal Data Protection Act, 2023

[18] Article 28(1), the GDPR

[19] Article 28(3), the GDPR

[20] Section 3(a), Digital Personal Data Protection Act, 2023

[21] Section 3(c)(ii), Digital Personal Data Protection Act, 2023

[22] Sarvesh Mathi, Digital Personal Data Protection Bill, 2023: How Will India’s Data Protection Law Impact Artificial Intelligence, available at

[23] Luke Irwin, What Is Legitimate Interest Under the GDPR?, available at

[24] European Commission, What does ‘grounds of legitimate interest’ mean?, available at,security%20of%20your%20IT%20systems

[25] Section 7, Digital Personal Data Protection Act, 2023

[26] Section 17(1)(c), Digital Personal Data Protection Act, 2023

[27] Article 8(1), the GDPR

[28] Article 8(2), the GDPR

[29] Information Commissioner’s Office, What are the rules about an ISS and consent? available at:,taking%20into%20consideration%20available%20technology

[30] Section 2(f), Digital Personal Data Protection Act, 2023

[31] Section 9(1), Digital Personal Data Protection Act, 2023

[32] Section 9(3), Digital Personal Data Protection Act, 2023

[33] Section 9(2), Digital Personal Data Protection Act, 2023

[34] Section 9(4), Digital Personal Data Protection Act, 2023

[35] Children’s Online Privacy Protection Rule, 16 CFR 312.5

[36] Section 9(4), Digital Personal Data Protection Act, 2023

[37] Suraksha P, Soon, store parental consent in DigiLocker, available at

[38] Article 5(1)(e), the GDPR

[39] Section 8(7)(a), Digital Personal Data Protection Act, 2023

[40] Section 8(8), Digital Personal Data Protection Act, 2023

[41] Section 8(8), Digital Personal Data Protection Act, 2023

[42] Article 33(1), the GDPR

[43] Article 34(1), the GDPR

[44] Article 33(1), the GDPR

[45] Section 8(6), Digital Personal Data Protection Act, 2023

[46] Section 8(6), Digital Personal Data Protection Act, 2023

[47] MeitY’s CERT-In Directions

[48] Section 38(1), Digital Personal Data Protection Act, 2023

[49] Article 45, the GDPR

[50] Article 46(2), the GDPR

[51] Section 16(1), Digital Personal Data Protection Act, 2023

[52] Shouvik Das and Gulveen Aulakh, The new data protection bill: Five takeaways, available at:

[53] Section 6(7) read with s. 2(g), Digital Personal Data Protection Act, 2023

[54] Section 6(9), Digital Personal Data Protection Act, 2023

[55] RBI Master Directions on Non-Banking Financial Company-Account Aggregator, 2016

[56] Data Empowerment and Protection Architecture – Draft for Discussion

More from Ikigai Law