Almost every article about the GDPR and India asks the wrong question. It asks whether Art. 3(2) catches an Indian company that targets European consumers. For a small number of Indian D2C brands and consumer apps, it does. For the far larger population of Indian IT-services firms, BPOs, GCCs and clinical-research organisations processing European personal data every day, that is not how the GDPR arrives at all.
It arrives through Art. 28. You are a processor acting on the documented instructions of a European controller, and the obligations reach you through a data processing agreement that your client is legally obliged to impose on you — an agreement you signed, that is enforceable in an EU court, and that is audited. Getting the route right matters, because it changes which obligations apply, who can enforce them against you, and what your client’s procurement team will actually ask for.
Key Takeaways
- Two distinct routes: Art. 3(2) targeting or monitoring, and the processor route under Art. 28.
- A back-office processor acting purely on an EU controller’s instructions is usually not directly caught by Art. 3(2) — the EDPB says so — but is bound in full by contract under Art. 28(3).
- Processor duties that a client will test: Arts. 28(2) and 28(4) on sub-processors, 28(3)(h) on audits, 30(2) records, 32 security, 33(2) breach notification to the controller, and Chapter V for onward transfers.
- Where Art. 3(2) does apply to you, Art. 27 requires processors as well as controllers to designate an EU representative.
- Health and clinical trial data is Art. 9 special-category data, and it is where European sponsors audit hardest.
Route One: Art. 3(2), Targeting and Monitoring
Art. 3(2) applies the GDPR to a controller or processor outside the Union where the processing relates to offering goods or services to individuals in the Union, or monitoring their behaviour there. Recital 23 makes clear that a website reachable from Europe is not enough; there must be an evident intention to target. Recital 24 treats internet tracking and profiling as monitoring. The general test is set out in our page on whether the GDPR applies outside the EU.
Indian companies that fall here: a Bengaluru SaaS product with euro pricing, VAT handling and EU customer logos on the site. An ed-tech platform recruiting students in Germany and Spain. A D2C brand shipping to France. A mobile app with a European app-store presence and localised listings. An adtech or analytics firm building behavioural profiles of users in the EU — that one is caught by Art. 3(2)(b) even though its customer, not the tracked individual, pays it.
Indian companies that do not fall here: a Pune engineering services firm whose only European contact is a Dutch corporate client; a Chennai BPO running payroll for a Swedish employer; a Hyderabad CRO running data management for a French sponsor. None of them offers anything to individuals in the Union or monitors those individuals on its own account. Art. 3(2) does not reach them.
That is the point most guidance misses, and it is why so many Indian compliance programmes are built on the wrong foundation.
Route Two: Art. 28, the Processor Relationship
The EDPB Guidelines 3/2018 on territorial scope address this directly. Where a non-EU processor carries out processing on behalf of an EU controller, the processor does not become subject to the GDPR by virtue of Art. 3(2) merely because its client’s processing is. Instead the controller must, under Art. 28, impose the required obligations by contract — and the EDPB describes the processor as becoming indirectly subject to GDPR obligations through that contract and through Chapter V.
Read carelessly, that sounds like relief. It is not. The obligations are identical in content; only the enforcement route differs. Your client faces an Art. 83(4)(a) fine if it fails to bind you properly, so it will bind you tightly, and it will verify. What changes is that the primary consequence of failure is contractual — indemnities, termination, and losing the account — rather than a direct fine from a supervisory authority.
What the Art. 28(3) contract must contain, and therefore what you have agreed to:
- Process only on documented instructions, including on transfers, and flag instructions you believe are unlawful (Art. 28(3)(a) and 28(3) final paragraph).
- Ensure confidentiality commitments from authorised personnel (b).
- Implement Art. 32 security measures ©.
- Engage no sub-processor without prior specific or general written authorisation, with notice of changes and an opportunity to object (Art. 28(2)), and flow down the same obligations to every sub-processor, remaining fully liable for their performance (Art. 28(4)).
- Assist the controller with data subject rights requests (d) and with Arts. 32-36 obligations including breach and DPIA support (f).
- Delete or return the data at the end of the engagement (g).
- Make available all information necessary to demonstrate compliance and allow and contribute to audits and inspections (h).
Our detailed treatment of the data processing agreement and of Art. 28 itself sets out the drafting; the controller and processor distinction matters more than it looks, because a services firm that starts making its own decisions about purposes becomes a controller for that processing and loses the shelter of acting on instructions.
Obligations the GDPR imposes on processors directly, where the GDPR applies to them. Art. 30(2) requires a processor to maintain its own record of processing activities — categories of processing carried out on behalf of each controller, the controller’s identity and its representative and DPO, third-country transfers with the documented safeguards, and a general description of the Art. 32 security measures. Art. 32 sets the security obligation on controllers and processors. Art. 33(2) requires the processor to notify the controller of a personal data breach without undue delay — no 72-hour grace, and in practice clients contract for 24 or 48 hours so they can meet their own Art. 33(1) deadline. Art. 37 can require a processor to appoint a DPO on its own account.
Article 27 Applies to Processors Too
Art. 27(1) is often quoted as a controller obligation. It is not: “the controller or the processor” must designate a representative in the Union in writing where Art. 3(2) applies. So an Indian company that both runs an EU-facing product of its own and provides outsourced services needs to look at Art. 27 for the product side even if the services side is outside Art. 3(2).
The representative sits in a member state where your data subjects are located, is addressable by supervisory authorities and individuals under Art. 27(4), and must appear in your privacy notice. Failure to designate is an infringement under Art. 83(4)(a), up to EUR 10 million or 2% of turnover, and it is the easiest possible regulatory finding. Our pages on Art. 27 and on choosing an EU representative cover the mandate and the Art. 27(2) exemptions — which almost never apply to a services firm, because its processing is neither occasional nor low-risk.
Health and Clinical Data: Where the Audit Gets Serious
Indian CROs, data management vendors, medical coding operations and healthcare BPOs process European patient and trial data at scale, essentially always as processors for European sponsors. Health data, genetic data and biometric data used for identification are special categories under Art. 9(1). Their processing is prohibited unless an Art. 9(2) condition applies in addition to an Art. 6 basis, and most of the relevant conditions — scientific research, public health, healthcare provision — depend on member-state law that differs by country.
Three consequences for a processor. First, your client’s DPIA is effectively mandatory under Art. 35(3)(b), and Art. 28(3)(f) obliges you to assist with it, which means producing security architecture, data flow and sub-processor detail on demand. Second, Art. 83(5) puts Art. 9 breaches in the higher fine band — up to EUR 20 million or 4% of worldwide turnover — so your client’s risk appetite for a weak processor is close to zero. Third, this is where the audit right in Art. 28(3)(h) stops being theoretical: pharmaceutical sponsors run on-site vendor qualification audits as a matter of routine, and the privacy annex is now part of them.
It is also where the DPDP Act diverges most sharply from the GDPR, because Indian law has no special-category regime at all — the point is developed in our comparison of the DPDP Act and the GDPR.
What a European Client Will Ask For
Expect a package, not a certificate: a signed DPA with the Art. 28(3) terms; Standard Contractual Clauses with the correct module and completed annexes; a current sub-processor list with locations and notice terms; a transfer impact assessment addressing Indian government access; ISO 27001 or ISO 27701 certification and SOC 2 Type II reports; your Art. 32 technical and organisational measures in writing; a breach notification SLA to the controller; audit rights and a recent audit report; and evidence of staff training and access control.
India holds no EU adequacy decision, so every one of these flows needs an Art. 46 safeguard. Which SCC module applies, and how to answer the government-access questions credibly, is covered in India-EU data transfers. Where the volume of per-client records, annexes and sub-processor chains outgrows a spreadsheet — which for most services firms is somewhere around thirty EU clients — see GDPR compliance software for Indian companies.
FAQ
If Art. 3(2) does not apply to us, can we ignore the GDPR?
No. If you process EU personal data for a European client you are bound by an Art. 28 contract with GDPR-derived terms, enforceable against you by your client under the governing law of that contract. The commercial consequence — losing the account, or indemnifying a fine your client received — usually arrives faster than any regulatory one.
Do we need our own record of processing activities?
Yes, if the GDPR applies to your processing. Art. 30(2) sets out a processor-specific record, structured per controller. The Art. 30(5) relief for organisations under 250 employees does not help a services firm, because its processing is regular and often involves Art. 9 data. See our Art. 30 field guide.
How fast must we report a breach to our client?
Art. 33(2) says without undue delay, with no fixed period. Your contract almost certainly says something tighter, because your client has 72 hours from its awareness under Art. 33(1) and needs time to assess. Treat the contractual figure as the real deadline. Our 72-hour guide explains how the two clocks connect.
Can an EU supervisory authority fine us directly?
Where the GDPR applies to you — via Art. 3(1) or Art. 3(2) — yes, and Art. 83(4)(a) expressly covers processor obligations under Arts. 28 and 32. Where it does not, your exposure is contractual and through Art. 82, which allows a data subject to claim compensation from a processor that failed to comply with obligations specifically directed at processors.
Does DPDP Act compliance cover us for the GDPR?
No. They are different laws with different structures, and no non-EU statute is equivalent to the GDPR. The DPDP Act has no special-category regime, no legitimate-interests basis, no portability right and no processor record obligation of the Art. 30(2) kind. The differences are set out in DPDP Act 2023 vs GDPR.
Legiscope automates this for you
Stop doing compliance manually. Legiscope's AI handles ROPA creation, DPA audits, and gap analysis — in minutes, not weeks.
Start free trial





