GDPR for Indian companies:
scope, transfers and fines, explained.

The GDPR applies to an Indian company with no EU establishment when it offers goods or services to people in the EU or monitors their behaviour there, under Article 3(2). It also reaches Indian companies indirectly as processors: an EU customer must bind its Indian vendor by contract to GDPR-standard obligations under Articles 28 and 44 to 49.

The text is Regulation (EU) 2016/679. Article 3 has two routes in. Article 3(1) covers processing in the context of an EU establishment: an EU subsidiary or branch brings the whole of that processing into scope. Article 3(2) covers companies with no EU establishment in two cases:

• Targeting. Offering goods or services to people in the EU, paid or free. A site that is merely reachable from Europe is not enough; euro pricing, EU shipping, EU-language marketing or EU customers named as a market are the signs
• Monitoring. Tracking behaviour that takes place in the EU, which includes profiling through cookies, analytics and ad-tech on an EU audience

The EDPB guidelines on territorial scope work through examples. The third route, the one most Indian IT and SaaS firms actually live under, is contractual: as a processor for an EU controller, you sign a data processing agreement under Article 28 and transfer clauses under Chapter V, and the obligations arrive through the contract.

An Indian company caught by Article 3(2) must appoint a representative in an EU member state where its data subjects are, under Article 27, unless its processing is occasional, excludes large-scale special-category or criminal data, and is unlikely to create risk. The representative is a contact point for authorities, not a shield from liability.

The representative is named in writing, must be established in a member state where your data subjects are, and is mandated to be addressed by supervisory authorities and individuals alongside or instead of you. It keeps your records of processing available. Appointing one does not move liability: the controller or processor remains responsible, and enforcement can still reach it.

The Article 27(2) exemption is narrower than it reads. A SaaS product with continuous EU sign-ups is not processing occasionally, so most Indian companies that target the EU need a representative. The UK GDPR has its own representative requirement for UK data subjects.

Every processing operation needs one of six lawful bases in Article 6: consent, contract, legal obligation, vital interests, public task or legitimate interests. Consent is only valid under Article 7 if it is freely given, specific, informed and unambiguous, as easy to withdraw as to give, and provable by the controller.

Three consequences Indian teams tend to miss:

• The burden of proof is yours. Article 7(1) requires you to demonstrate consent. That means a record of what the person saw, when, and what they chose, not a boolean in a user table
• Not conditional. Consent bundled into terms of service, or required for something the service does not need, is not freely given
• Children. Article 8 sets 16 as the age for consent to online services, which member states may lower to 13. India's DPDP Act uses 18

Cookies and similar trackers are governed by the ePrivacy rules in each member state, which require consent for anything not strictly necessary; the GDPR then sets what that consent must look like. A consent management platform that keeps a receipt for each decision is how most companies meet the Article 7 proof burden. The free cookie scanner shows what fires before consent.

A data protection impact assessment is required under Article 35 before processing likely to result in a high risk to people's rights. Article 35(3) names three cases: systematic, extensive profiling with significant effects; large-scale special-category or criminal data; and large-scale systematic monitoring of public areas. Supervisory authorities publish longer lists.

The DPIA template covers GDPR Article 35 and the DPDP Act side by side, so one assessment can serve both where the processing overlaps.

Yes, but not freely. India has no EU adequacy decision, so a transfer to India needs an Article 46 safeguard, in practice the 2021 standard contractual clauses, plus a transfer impact assessment of Indian law and practice. Binding corporate rules are the alternative for groups; Article 49 derogations cover only occasional cases.

The Commission's adequacy list does not include India. The working mechanism is the standard contractual clauses in Implementing Decision (EU) 2021/914, which come in four modules. For an Indian vendor the common ones are module 2, EU controller to Indian processor, and module 3, EU processor to Indian sub-processor.

Since the Court of Justice's Schrems II judgment in 2020, the clauses are not enough on paper: the exporter must assess whether the law and practice of the destination, including government access powers, let the importer honour them, and add supplementary measures where they do not. Expect your EU customers to send a questionnaire about exactly this, and to ask about encryption, key location and how you would respond to an access request from an authority.

The DPDP Act's own rules on transfers out of India are separate, and covered in DPDP cross-border data transfer.

Under Article 33 a controller notifies its lead supervisory authority within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to create risk. Under Article 34 it tells affected people without undue delay when the risk is high. A processor must tell its controller without undue delay.

The clock runs from awareness, not from the end of the investigation; Article 33(4) lets you notify in phases. An Indian processor's contract with an EU controller usually sets a shorter internal deadline, often 24 to 48 hours, so the controller can meet its 72.

A breach at an Indian company can trigger Indian reporting at the same time: six hours to CERT-In for reportable cyber incidents, and, from 13 May 2027, intimation to the Data Protection Board and affected Data Principals under the DPDP Rules. CERT-In vs DPDP breach reporting sets the Indian clocks side by side.

An Indian company with EU and Indian users runs both regimes at once. They share principles, purpose limitation, data minimisation, security, rights, breach reporting, and differ in mechanics: the DPDP Act has no general legitimate-interests basis, sets 18 as the age of a child, adds registered Consent Managers and fixes its own dates, with substantive duties from 13 May 2027. The full side-by-side table is in the DPDP Act guide, and the clause-level map is on DPDP to GDPR.

One Indian-specific rule matters for outsourcing. Section 17(1)(d) of the DPDP Act disapplies most of the Act where a company in India processes data of people outside India under a contract with a person outside India; Section 8(1) and the Section 8(5) security safeguards still apply. For that data, the GDPR, through your contract, is the regime that governs the detail.

Proposed GDPR amendments in the EU's Digital Omnibus were still in first reading, without a Council mandate, in September 2026. Plan to the regulation as it stands.

GDPR is on the coverage list alongside the DPDP Act, on one control set. The consent platform keeps a proof-of-consent record for each decision; data discovery and DSAR finds personal data, maps cross-border flows and tracks access, correction and erasure requests against statutory due dates; the privacy policy generator drafts GDPR and DPDP notices for free. None of it appoints your representative, chooses your lawful basis or signs your transfer clauses: those stay with you and your counsel.