DPDP and GDPR are different systems: where comparisons go wrong

Imagine a founder receiving this suggestion: take the company’s European privacy policy, replace the regulator’s name, and publish it for India. The document already describes consent, access requests and security. Surely most of the work is done?

Some operational work may be reusable. The legal analysis needs more care. Similar vocabulary can hide different conditions, rights and thresholds. A polished document becomes misleading when it promises an Indian statutory right that the Indian Act does not contain, or justifies processing using a European legal basis without identifying an Indian route.

As at 22 October 2026, most substantive DPDP duties and rights discussed here are scheduled to commence on 13 May 2027 under the commencement notification. That transition does not suspend other applicable laws. It makes this a useful time to correct mappings before they become embedded in forms and support scripts.

Start with the activity and the people

Under DPDP section 3, the future scope includes digital personal data processed in India, including information collected offline and subsequently digitised. Processing outside India is covered when connected with offering goods or services to Data Principals within India. The reference is to people within India, rather than Indian citizenship alone.

GDPR article 3 has its own establishment and extraterritorial tests. Its extraterritorial provisions include monitoring behaviour within the Union, as the EDPB’s territorial-scope guidelines explain. That monitoring limb should not simply be inserted into a description of DPDP section 3. Conversely, an Indian business cannot assume GDPR is irrelevant merely because its office is in India.

For a hypothetical subscription service, map where the business operates, where its customers are, what it offers them and what processing occurs. A single customer database can support activities requiring more than one legal assessment. The database location alone does not answer every scope question.

Do not rename a legal basis

GDPR article 6 contains several lawful bases, including contractual necessity and legitimate interests, subject to their conditions. DPDP sections 4 and 7 instead provide for consent or specified certain legitimate uses. They do not create an open-ended GDPR-style legitimate-interest balancing route or a general contractual-necessity basis under those labels.

Suppose the service’s European register describes processing as necessary to perform a subscription contract. Its Indian review still needs to identify the relevant DPDP route and facts. Section 7(a), for example, concerns personal data voluntarily provided for a specified purpose where the person has not indicated that they do not consent to that use. Its conditions need to be assessed; changing the register’s heading is insufficient.

The same discipline applies to marketing. A reason supporting fulfilment of an order does not, by itself, explain why the business may reuse the contact information for every future campaign. Split purposes before mapping routes.

Match the right to its actual content

DPDP sections 11 to 14 address access information, correction and erasure, grievance redressal and nomination, within their wording and conditions. They do not reproduce every GDPR right. For example, GDPR article 20 establishes a conditional data-portability right; DPDP does not contain an equivalent general portability entitlement.

A business may voluntarily offer downloads or operate an export feature for contractual reasons. It should describe that service accurately. A support template claiming that every Indian customer has a DPDP right to move all account data directly to a competitor overstates the Act.

Keep operational steps reusable where sensible: receiving a request, checking identity, locating relevant information, reviewing third-party data and delivering a safe response. Attach the correct legal scope and response rules to the request rather than forcing every jurisdiction through one undifferentiated policy.

Build a comparison that produces decisions

Use one row per activity, not one row per broad legal slogan. For the hypothetical service, useful rows might be account creation, billing, optional recommendations and customer support. Record the applicable legal systems, purpose, Indian processing route, European basis where relevant, rights implications and the owner of any unresolved question.

The output should identify a change someone can make: separate an optional purpose, correct a notice, add a request category, or obtain advice on a territorial question. Shared access controls and accurate inventories can support both programmes. Their existence does not establish that every underlying legal test has been met.

The costly failure is false equivalence. A comparison is valuable when it exposes differences that change a decision. A claim that one law is simply a lighter or stricter version of the other rarely tells a product manager what to build.