Does GDPR Apply to Indian Companies? The Extraterritorial Question

Yes, GDPR can apply to Indian companies. The regulation's extraterritorial scope reaches any organisation that processes personal data of people in the European Union, regardless of where the organisation is based. If an Indian startup has EU users, GDPR is part of its legal surface, and the DPDP Act adds a second one.

This post covers when GDPR touches an Indian company, what the overlap with DPDP looks like, and how to build for both without doubling your work. It is not legal advice; it is a scoping exercise for engineering teams.

When GDPR applies to a non-EU company

GDPR Article 3 creates two paths for extraterritorial application:

1. Establishment in the EU. Any processing in the context of an EU establishment, even a small office, triggers GDPR for that processing.

2. Targeting EU residents. Processing of EU residents' data where the processing relates to offering goods or services to them, or monitoring their behaviour in the EU. A Delhi company with a product that accepts EU users and tracks them with analytics is inside this path.

The second path is the common one for Indian startups: you do not need an EU office to be inside GDPR; you need EU users whose data you process for a service aimed at them.

The overlap problem

An Indian consumer product with global users now sits under two regimes:

| | GDPR | DPDP | |--|------|------| | Who it protects | EU residents | Indian data principals | | When it applies | EU establishment or targeting EU residents | Processing Indian principals' data | | Legal bases | Six, including legitimate interest | Consent + legitimate uses | | Breach clock | 72 hours to EU authority | 72 hours to DPB + CERT-In complications | | Child threshold | Under 16 (varies 13-16) | Under 18 | | Penalty ceiling | €20m / 4% turnover | ₹250 crore |

The regimes overlap but do not align. A consent flow built to GDPR spec is not automatically DPDP-compliant, and vice versa. The differences that bite are legal bases (DPDP has no legitimate-interest escape for marketing), children (18 vs 16), and breach notification (two different authorities).

Where the regimes conflict in practice

Three practical conflicts show up constantly:

• Consent architecture. GDPR allows legitimate interest for some processing where DPDP does not. The safe design is to build everything on consent, which satisfies both, at the cost of more consent prompts.
• Children. GDPR's threshold is 16 (or lower by member state); DPDP's is 18. The stricter threshold, 18, wins for any user who could be in either regime. Building verifiable parental consent to the 18 standard covers both.
• Breach response. GDPR wants one notification within 72 hours to the lead supervisory authority. India wants the Data Protection Board within 72 hours, plus CERT-In on its own timeline. A global breach means a multi-authority runbook.

The pragmatic approach: build to the stricter test

The cheapest way to handle overlapping regimes is to build to the stricter requirement in each dimension:

• Consent with per-purpose granularity and proof: satisfies both regimes
• Withdrawal parity: required by both
• Child protection at 18: covers DPDP and every GDPR member state
• Breach runbook with multiple authorities: the only way to run a global product
• Evidence of everything: both regimes end at "prove what happened"

This is the same principle as accessibility or security: the stricter standard is not double work, it is a single build that happens to clear two bars.

What most Indian companies actually face

The honest scoping for most Indian startups:

• Domestic-only products with Indian users: DPDP is the regime; GDPR is not triggered
• Products with EU users, however few: GDPR is triggered for those users' data
• B2B SaaS selling to EU companies: GDPR flows through contracts even where the regulation's territorial scope is thinner; the customer's contract will require it
• Global consumer products: both regimes, always

The threshold question is "do we have EU users, or EU business customers who will contractually require GDPR?" If the answer is no, GDPR is a contract question, not an engineering one. If yes, build to the stricter test and stop re-litigating it.

Where Erasure sits

Erasure is built for the Indian regime first, which happens to be the stricter test on consent, children, and evidence. Accord's consent model, per-purpose granularity with immutable receipts and withdrawal parity, clears GDPR's requirements too. The GDPR vs DPDP comparison is the full map; the compliance checklist is the work list.

The bottom line

GDPR applies to Indian companies the moment they process EU residents' data, and the DPDP Act applies to anyone processing Indian data. The regimes overlap imperfectly. The engineering answer is boring and correct: build consent, erasure, and evidence to the stricter standard, keep a multi-authority breach runbook, and let the two laws share one implementation.

For most startups the real question is not "does GDPR apply" but "when do we get EU users," because that is the day the second regime switches on.