India-EU Data Transfers: Adequacy Status and SCCs

India holds no EU adequacy decision. There is no partial recognition, no sectoral carve-out, no pending framework to rely on in the meantime. Every transfer of personal data from the EEA to India requires an Art. 46 safeguard, and in practice that means the Standard Contractual Clauses plus a transfer impact assessment that survives your client’s legal review.

The Commission’s adequacy list currently runs to fifteen or so jurisdictions — the United Kingdom, Switzerland, Japan, South Korea, New Zealand, Israel, Uruguay, Argentina, Andorra, the Faroe Islands, Guernsey, Jersey, the Isle of Man, Canada for commercial organisations subject to PIPEDA, and the United States for organisations certified under the Data Privacy Framework. India is not on it, and the passage of the DPDP Act 2023 does not put it there. Adequacy is a Commission decision taken after a formal assessment under Art. 45; a new domestic statute is at most a precondition.

Key Takeaways

• No adequacy. Art. 46 safeguards are mandatory for every EEA-to-India flow.
• Module 2 for a controller-to-processor engagement, Module 3 where you are a sub-processor to an EU processor.
• Clause 14 requires a documented transfer impact assessment; for India it must address s. 69 IT Act, the Telecommunications Act 2023, the CERT-In directions and the absence of judicial pre-authorisation.
• The DPDP Act cuts both ways: it is not an adequacy substitute, and its s. 16 gives the Government power to restrict outbound transfers.
• Supplementary measures — EEA-held encryption keys, pseudonymisation, no plaintext access — are what usually make the assessment work.

Choosing the Right SCC Module

The Standard Contractual Clauses are set out in Commission Implementing Decision (EU) 2021/914 of 4 June 2021. They are modular, and picking the wrong module is the most common drafting error in Indian engagements.

Module	Parties	Typical Indian scenario
1	Controller to controller	European client shares data with an Indian entity that decides its own purposes — rare in services
2	Controller to processor	The default: an EU client engages your firm to process on its instructions
3	Processor to processor	You are a sub-processor to an EU processor, or you engage an Indian sub-processor
4	Processor to controller	An EU processor returns data to a non-EU controller

Module 2 is the ordinary case for an Indian IT-services firm, BPO, GCC or CRO working directly for a European controller. It carries the Art. 28(3) content inside the clauses themselves: clause 8 sets out the data protection safeguards including purpose limitation, security and sensitive-data handling; clause 9 governs sub-processors on either specific prior authorisation or a general authorisation with an agreed minimum notice period; clause 10 covers data subject rights; clause 11 gives data subjects a redress route; clause 12 allocates liability; clause 16 lets the exporter suspend or terminate on non-compliance.

Module 3 applies where you sit one rung down the chain — where a European software vendor is itself the processor for its customers and you provide engineering or support underneath it. Most Indian services firms are on Module 3 more often than they realise, and Module 3 is drafted with a different instruction-flow logic: your instructions come from your own client, who is passing on the ultimate controller’s instructions, and clause 8.1 requires the chain to be respected. Signing a Module 2 set for a Module 3 relationship leaves a real hole around whose instructions govern.

Clause 7, the docking clause, is optional and lets additional parties accede later — worth including where a client group will onboard multiple entities. Clause 17 requires the SCCs to be governed by the law of an EU member state; clause 18 fixes the forum in a member state and confirms that a data subject may sue there. Our guide to the standard contractual clauses covers annex drafting, which is where most reviews fail: Annex I.B must describe the actual processing, not paraphrase the master services agreement, and Annex II must list specific technical and organisational measures rather than say “industry standard”.

The Transfer Impact Assessment

Clause 14 requires both parties to warrant that they have no reason to believe the laws and practices of the destination country prevent the importer from meeting its obligations, having considered the circumstances of the transfer, the laws and practices in force, and any safeguards applied. That warranty has to be documented. The EDPB’s Recommendations 01/2020 on supplementary measures set out the six-step method, and our transfer impact assessment guide works through it.

For India, an assessment that does not engage with the following will be sent back:

Section 69 of the Information Technology Act, 2000 empowers the Central Government or a State Government to direct interception, monitoring or decryption of information generated, transmitted, received or stored in any computer resource, on grounds including sovereignty, security of the State, public order and preventing incitement to a cognisable offence. Section 69B allows monitoring and collection of traffic data for cyber security. The procedural safeguards sit in the Information Technology (Procedure and Safeguards for Interception, Monitoring and Decryption of Information) Rules, 2009. Section 69(3) obliges intermediaries and any person in charge of a computer resource to extend technical assistance, with penal consequences for refusal.

Telecommunications interception. The Indian Telegraph Act 1885, s. 5(2), read with Rule 419A, was the historic basis, with the Supreme Court’s safeguards in PUCL v. Union of India (1997) 1 SCC 301 requiring authorisation by a designated senior official and review by a committee. The Telecommunications Act, 2023 now carries the corresponding powers. In each case authorisation is executive rather than judicial — a Home Secretary and a review committee, not a court and not an independent authorisation body. That is the single point a European reviewer will fix on, because it maps directly onto the Schrems II reasoning about effective remedies.

The CERT-In directions of 28 April 2022 require reporting of specified cyber incidents within six hours of noticing them, retention of ICT system logs for 180 days within India, and retention of subscriber and KYC records by data centres, VPN providers and cloud service providers. A six-hour incident-reporting duty to a state agency is a fact your client’s assessment has to weigh, and the in-India log retention requirement interacts awkwardly with any commitment to keep EU data solely within the EEA.

DPDP Act exemptions. Section 17 allows the Central Government to exempt instrumentalities of the State from the Act’s application by notification, and s. 36 lets the Government require a Data Fiduciary to furnish information. These exemptions are broad and are the obvious obstacle in any future adequacy assessment. The comparison in DPDP Act 2023 vs GDPR sets out the enforcement architecture in more detail.

The counterweight, which you should state rather than omit. In K.S. Puttaswamy v. Union of India, (2017) 10 SCC 1, a nine-judge bench of the Supreme Court held that privacy is a fundamental right under Art. 21 of the Constitution and subjected State interference to a proportionality test: legality, legitimate aim, necessity and proportionality, with procedural safeguards. A credible TIA acknowledges the access powers, then explains the constitutional constraint and the practical likelihood that a given dataset is targeted. An assessment that pretends the powers do not exist is worse than useless; one that treats them as fatal ignores the case law.

Supplementary Measures That Work

The EDPB recommendations describe use cases where technical measures make the assessment tenable. The ones that hold up in Indian engagements:

• Encryption with keys held exclusively in the EEA, so the Indian entity never has the ability to produce plaintext even under compulsion.
• Pseudonymisation performed before transfer, with the re-identification key retained by the EU controller.
• Split or multi-party processing, where no single location holds a re-identifiable dataset.
• Restricting plaintext access to named EEA-resident personnel, with Indian teams working against masked data — common in clinical data management.
• Contractual and organisational measures: warrant canaries, transparency reporting, a commitment to challenge orders, immediate notification to the exporter, and documented refusal policies.

Our catalogue of Schrems II supplementary measures sets out the full menu and what each one does and does not solve.

Note the limits of the alternatives. Binding Corporate Rules under Art. 47 work for a captive or GCC inside a single group but require supervisory-authority approval and take a year or more. The Art. 49 derogations — explicit consent, contract necessity — are for occasional, non-repetitive transfers and cannot carry an ongoing outsourcing relationship. The comparison in BCR, SCC and DPF sets the three side by side.

The Indian Side of the Flow

Do not assume the analysis is one-directional. Section 16 of the DPDP Act empowers the Central Government to restrict transfers of personal data out of India to notified countries, and s. 16(2) preserves stricter sectoral rules. The Reserve Bank of India’s 2018 payment-data circular requires payment system data to be stored in India, with only limited processing abroad. If your engagement touches European payment data routed through Indian systems, you have a genuine two-way localisation problem, not a paperwork exercise.

And for health and clinical data, the transfer analysis sits on top of an Art. 9 problem: the underlying processing needs a special-category condition as well as a transfer mechanism, and European sponsors audit that combination hardest. The processor obligations that come with it are set out in GDPR for Indian companies, and the tooling to keep the resulting per-client transfer register current is compared in GDPR compliance software for Indian companies.

FAQ

Will India get an adequacy decision?

There is no decision and no formal adequacy process announced as complete. The DPDP Act’s enactment makes an assessment conceivable, but the broad State exemptions in s. 17, the Government’s information powers in s. 36, the executive rather than judicial authorisation of interception, and the constitution of the Data Protection Board are all live issues. Plan on SCCs, and revisit the position when the Commission publishes an assessment — not before.

Which module do we sign?

Module 2 if your client is the controller and you process on its instructions. Module 3 if your client is itself a processor and you sit beneath it. If you are unsure which your client is, ask them in writing; the answer determines the module, the instruction chain and the liability allocation, and getting it wrong is not fixed by signing both.

Do we need a TIA for every client?

You need one per transfer scenario, not per contract. Most services firms can maintain a small number of assessments keyed to data category, access model and sub-processor chain, then map clients onto them. What you cannot do is reuse one client’s assessment verbatim for a materially different data type — a marketing contact list and a clinical dataset produce different answers.

Does the DPDP Act help our transfer file?

Marginally. It shows a domestic legal framework exists, which is better than nothing in the “laws and practices” limb of clause 14. It is not a substitute for adequacy, its core obligations do not commence until 2027, and it contains exemptions that make the government-access analysis harder rather than easier.

Can our EU client just rely on us being ISO 27001 certified?

No. Certification is evidence of security measures under Art. 32 and useful in Annex II, but it is not an Art. 46 transfer safeguard. The Art. 42 certification route exists in principle and has almost no approved schemes in practice. You still sign SCCs, and your client still assesses the destination country’s law — the scope question behind all of it is covered in whether the GDPR applies outside the EU.