GDPR When Outsourcing Software Development to India: A Practical Guide

This guide is for founders, operations leads and data protection officers in the EU and UK who want to use an Indian development team without creating a GDPR problem. It explains the mechanisms in plain terms: controller and processor roles, what a data-processing agreement must contain, how international transfers are handled, and the design choices (data minimisation, regional hosting, access controls) that reduce how much of the framework applies at all. It ends with a checklist table. It is practitioner guidance, not legal advice; your DPO or counsel should confirm the position for your data and your sector.

Does GDPR apply when you outsource development to India

GDPR applies to you as the controller regardless of where your developers sit, because it follows the personal data of people in the EU (and, under UK GDPR, the UK), not the location of the vendor. The question is not whether GDPR applies but what it requires of the relationship with the Indian firm.

That depends on one fact: will the firm process personal data? "Process" is broad and includes viewing, copying, storing and deleting. A team building a system on synthetic data and never touching the live database is, in practice, not processing your personal data. A team that migrates your customer records, debugs a production issue by looking at real accounts, or hosts the application under its own cloud account is processing it and must be treated as a processor. Most real projects fall in the second category at some point, so plan for it.

Controller vs processor: who is responsible for what

You are the controller: you decide why personal data is collected and how it is used, and you carry the primary obligations to the people whose data it is. The development firm is a processor: it acts on your written instructions, must protect the data, and may not use it for its own purposes. If the firm uses a cloud provider, a monitoring service or a contractor to do its work, those are sub-processors and you must know who they are and be able to object.

Two consequences follow. The processor cannot decide on its own to copy your production database to a laptop for convenience; that would need your instruction. And you cannot outsource your responsibility: if the processor loses data, the regulator and the data subjects come to you first, which is why the contract and the vetting matter.

What a data-processing agreement with an offshore developer must contain

GDPR requires a written contract between controller and processor, usually called a data-processing agreement (DPA), with a defined minimum content. A DPA for a development engagement should cover:

• Subject matter, duration, nature and purpose of the processing: for example, "building, testing, migrating and supporting the client's booking system for the term of the services agreement".
• Types of personal data and categories of data subjects: customers, staff, patients; names, contact details, payment references, health notes.
• Processing only on documented instructions, including instructions about international transfers.
• Confidentiality commitments from everyone with access.
• Security measures: encryption in transit and at rest, access controls, logging, secure development practices, device security for developers.
• Sub-processors: a list, a right to object to new ones, and the same obligations flowed down.
• Assistance with data-subject requests, breach notification (without undue delay, with a defined internal target such as 24 hours), and impact assessments.
• Deletion or return of all personal data at the end of the engagement, with confirmation.
• Audit and information rights so you can check compliance.

Most established Indian firms serving EU and UK clients have a DPA template, and will also sign yours. Either is fine; what matters is that one exists before any personal data is shared, and that the security measures in it match what the team actually does.

Transferring personal data to India: the safeguard mechanism

GDPR restricts transfers of personal data outside the EU (and UK GDPR outside the UK) unless the destination has an adequacy decision or an appropriate safeguard is in place. India does not have an adequacy decision from either the EU or the UK, so a transfer to a processor in India needs a safeguard.

The standard tool is the standard contractual clauses (SCCs): a set of contract terms approved by the European Commission that the exporter (you) and importer (the Indian firm) sign, binding the importer to GDPR-level protections. UK controllers use the UK's international data transfer agreement or the UK addendum to the EU SCCs. Since 2020, exporters are also expected to carry out a transfer risk assessment: a short, documented look at whether local law in the destination could undermine the clauses, and what supplementary measures (encryption, pseudonymisation, access limits) address that.

Three practical points. First, "transfer" includes remote access: a developer in Rajkot viewing a production database hosted in Frankfurt is a transfer, even though the data never moved. Second, the safeguard is a contract, so it slots alongside the DPA and services agreement in the same signing round. Third, the fewer people, the less data and the shorter the access, the simpler the assessment. Your DPO or counsel should confirm which clause set and which modules apply to your situation.

Reducing the GDPR footprint by design

The framework above sounds heavy. The good news is that most of it scales with how much personal data the developers can actually see, and that is something you control at the design stage.

Data minimisation

Decide at scoping which personal data the system needs and which it does not. A booking system needs a name and a contact method; it rarely needs a date of birth. Fewer fields mean less to protect, fewer categories in the DPA and a smaller breach if something goes wrong.

Hosting in EU or UK regions under your account

Deploy to an EU (Frankfurt, Dublin, Paris, Amsterdam) or UK (London) region of the major clouds, under a cloud account in your own name. The data then lives in your jurisdiction, the developers are collaborators with revocable access, and closing the engagement is a matter of removing their users.

Anonymised or synthetic test data

Give the development team a test dataset that contains no real people: generated names, random emails, fake addresses. Most of the build and all of the automated testing then happens with no personal data in scope. This is the single most effective measure on a development project.

Access controls and logging

Production access limited to named individuals, granted for a defined task and duration, through multi-factor authentication, with logs kept. No production data on developer laptops; no copies in chat. Data migration and production debugging are the two moments where real data is unavoidable, so they are scheduled, instructed in writing and logged.

Encryption and secure development practice

Encryption in transit and at rest is standard on the major clouds and should be on by default. Secrets in a vault rather than in code; dependency updates; a review step before merging. These are good engineering regardless of GDPR and they are what the DPA's security clause should describe.

GDPR checklist for outsourcing software development to India

Item	What to do	When	Who confirms
Identify personal data	List the data the system will hold and the categories of people	Scoping	You, with the vendor
Decide processor status	Confirm whether developers will ever access real data (migration, support, debugging)	Scoping	You, DPO
Mutual NDA	Sign before any detail is shared	Before scoping	Both
Data-processing agreement	Sign a DPA with the minimum content above	Before any personal data is shared	DPO or counsel
Transfer safeguard	SCCs (EU) or IDTA / UK addendum (UK), plus a transfer risk assessment	Same signing round as the DPA	DPO or counsel
Hosting region	EU or UK cloud region, account in your name, developers as collaborators	Before first deployment	You, vendor
Test data	Anonymised or synthetic dataset for development and QA	Before development starts	Vendor
Access controls	Named users, MFA, task-based production access, logging, no local copies	Before go-live	Vendor, checked by you
Sub-processors	List the vendor's cloud, monitoring and any contractors; right to object	In the DPA	DPO
Breach process	Named contacts, notification target, what the vendor reports and when	In the DPA	DPO
Data-subject requests	Confirm the system can export, correct and delete an individual's data	Acceptance testing	You
End of engagement	Access revoked, copies deleted, written confirmation	Contract end	Vendor, confirmed by you
Records	Add the vendor to your record of processing activities	Contract start	DPO

What we have seen with EU and UK clients at JK Tech Hub

JK Tech Hub is based in Rajkot, India, and builds for clients in the UK and Europe alongside manufacturers and retailers in Gujarat. A few anonymised patterns from those projects.

A consultancy in the UK Midlands needed a client portal holding names, addresses and contract documents. Their DPO asked for a DPA and a transfer safeguard before scoping began. We signed their DPA and the UK addendum, hosted in a London region under their cloud account, and built the whole portal on a generated dataset. Real data entered the system only at migration, in a scheduled, logged session with two named people. The paperwork took about a week and did not delay the build.

A German engineering SME wanted an inventory and dispatch system with staff records. Their counsel's main concern was remote access from India to a Frankfurt database. The answer was structural: production access limited to one named engineer, granted per task through MFA and revoked afterwards, with the DPA and SCCs describing exactly that. The transfer risk assessment was short because the exposure was small.

A Dutch e-commerce brand asked whether they could skip the DPA because "developers only see test data". We agreed on the test data, and still signed the DPA, because support and debugging after launch would eventually mean seeing a real order. That is the usual pattern: the DPA exists for the exceptions, and the design keeps the exceptions rare.

How to decide and what to ask a vendor

If your system holds personal data of EU or UK residents, plan for the vendor to be a processor and put the DPA and transfer safeguard in the first signing round with the NDA and services agreement. Then reduce the footprint by design: minimise fields, host in your region under your account, build on synthetic data, and gate production access. Ask any prospective Indian vendor four questions: do you have a DPA template and will you sign ours; will you sign SCCs or the UK addendum; can you deploy to an EU or UK region under our account; and how do you give developers test data. Clear answers to all four are a good sign. Take the resulting documents to your DPO or counsel for confirmation before sharing any personal data.

Related reading and next step

• Working with JK Tech Hub from Europe: EU hosting, DPA on request, euro quotes and the overlap with Central European hours.
• Working with JK Tech Hub from the United Kingdom: UK GDPR-aware delivery, London-region hosting and GBP quotes.
• All international client pages: the US, Australia, Canada and the Gulf.
• Software requirements document template: where the personal-data inventory should live from day one.

If you want to see our DPA and transfer clause set before scoping, or want a fixed quote with EU or UK hosting included, reach us through the contact page or WhatsApp.