GDPR when you outsource development to India

"Are you GDPR compliant?" is the first question most European buyers ask an Indian supplier, and it is close to meaningless. Compliance is not a property a vendor carries around. It is a property of a specific arrangement — what data moves, under what contract, with what safeguards, for what purpose. A vendor can answer yes honestly and still leave you exposed, because most of the obligations in that arrangement are yours.

We are an Indian supplier, so read this knowing which side of the table it is written from. It is also the reason the article exists: the version of this arrangement we prefer is the one where we never touch your production data, and that is a harder sell than a reassuring yes.

This is not legal advice. It is an engineering read on where the obligations land. Have counsel review your DPA, your clauses and your assessment before you sign anything.

You are the controller. That does not change.

Under the GDPR, the controller decides why and how personal data is processed; the processor acts on the controller's instructions. When you hire a development firm, you are almost always the controller and they are the processor. You decided the data would be processed, you defined the purpose, and you chose the supplier.

The consequence people miss is accountability. Article 28 requires you to use only processors who provide sufficient guarantees, and the regulator's attention stays on you. You cannot outsource the exposure by pointing at your vendor. If their engineer copies a production database to a laptop, that is your breach to report and your fine to pay, with a contractual claim against them as your only recourse.

The DPA is a precondition, not paperwork

Article 28 requires a written contract between controller and processor before personal data flows. A DPA that gets signed three months into the engagement has already failed at the thing it exists to do.

The clauses that matter in practice, as opposed to the ones that get skimmed:

• Documented instructions. The processor acts only on your instructions. This sounds like boilerplate until a developer decides to "clean up" a dataset or try it in a third-party tool.
• Breach notification timing. You have 72 hours to notify your supervisory authority. If your DPA says the vendor will tell you "promptly", you have no chance of meeting that. Put a number on it, and make it shorter than 72 hours.
• Sub-processor consent. Your vendor's cloud, error tracker, CI runner and AI coding assistant are all sub-processors. You need the current list and the right to object before a new one is added.
• Deletion and return at the end. Including the copies in backups, and a stated retention window for those.
• Audit rights you could actually use. An unlimited right to audit is nice and nobody exercises it. A right to an annual questionnaire plus evidence of a penetration test is less impressive and more real.

India has no adequacy decision

The European Commission has not ruled that India provides essentially equivalent protection. So an EU-to-India transfer is a restricted transfer, and it needs its own legal basis on top of the DPA.

In practice that means standard contractual clauses, paired with a transfer impact assessment — a documented look at whether the law in the destination country would undermine those clauses, principally through government access to data. The assessment is the part that gets skipped, and it is the part that demonstrates you actually thought about it.

One route to avoid: relying on the Article 49 derogations, such as the data subject's explicit consent. They exist for occasional, non-repetitive transfers. Routine outsourcing is neither, and building a programme on a derogation is a weak position to defend.

Your supplier is also now subject to India's own Digital Personal Data Protection Act, whose substantive obligations phase in through 2027. That does not substitute for your transfer mechanism, but a vendor who has not heard of it is telling you something about their compliance maturity.

The question that removes most of the risk

Everything above assumes the development team processes production personal data. Very often they do not need to, and nobody checks.

Ask it directly: which of our engineers, on which environments, will see real personal data — and why? Then work through the answers. Building a checkout flow does not require real customer records; it requires records shaped like real ones. Debugging a specific production incident might genuinely require production access, for a named person, for a bounded window, logged.

When the honest answer is "they do not need it", the controls are ordinary engineering rather than legal architecture:

• Synthetic or anonymised fixtures in development and staging, generated to match the shape and edge cases of production without carrying anyone's identity.
• Production access as an exception, time-boxed and logged, rather than a standing grant that comes with the laptop.
• Separated environments, so a staging misconfiguration cannot reach live records.
• Data minimisation in the test set itself — if a bug can be reproduced without the email address, do not include the email address.

This does not eliminate the DPA or the clauses; you still need them for the residual cases and for the vendor's access to any system holding personal data. It does change the risk from "an offshore team has standing access to our customer base" to "an offshore team works on code, with a narrow and auditable exception process." That is a far easier arrangement to defend to a regulator, and a far easier one to sell internally.

Diligence: evidence, not assurances

Any supplier will tell you they take security seriously. Ask for the artefacts instead:

• A signed DPA they are willing to negotiate rather than one they insist is non-negotiable.
• The current sub-processor list, with locations.
• A recent penetration test report, or an honest statement that there isn't one.
• ISO 27001 or SOC 2 where it exists. Where it does not, a description of the controls that stand in its place — and treat a vendor who claims a certification they cannot produce as disqualified.
• Their incident process: who decides it is a breach, how fast you hear, and what you get told.
• Device and access posture: managed laptops, disk encryption, MFA, what happens on the day an engineer leaves.

For the record and in the interest of not doing the thing described two paragraphs above: Appsarmy holds neither ISO 27001 nor SOC 2, and we say so rather than implying otherwise.

A workable sequence

1. Scope the data first. Decide what the team will actually touch, before procurement.
2. Sign the Article 28 DPA, with a real breach-notification number in it.
3. Put the standard contractual clauses in place and document the transfer impact assessment.
4. Record the sub-processor list and the objection process.
5. Build the environments so the default is synthetic data and production access is an exception.
6. Re-check when scope changes. A new integration or a new AI tool in the pipeline is a new sub-processor.

None of this is exotic, and none of it is a reason to avoid outsourcing to India. It is a reason to be specific about what you are outsourcing. The arrangements that go wrong are rarely the ones where someone thought carefully about the data and wrote it down.

Questions we get asked

If you are evaluating an Indian supplier and want the data scoping done before the contract rather than after, that is the first conversation we have on every offshore engagement — and it usually makes the compliance paperwork smaller, not larger.