This post is general information, not legal advice. We’re engineers, not solicitors. Data protection law depends on your exact setup, so check your position with a qualified adviser and read the ICO’s current guidance yourself. What we can do is explain how UK GDPR, DPA and offshore developers fit together in practice, from the side of an Indian development team.
The short version: if developers in India can see personal data of people in the UK, you probably need three things in place. A data processing agreement, a lawful mechanism for the international transfer, and a written risk assessment. Then you need engineering habits that keep the amount of data they see as small as possible.
UK GDPR, DPA and offshore developers: who is the controller?
Usually your company is the controller: you decide why and how your users’ data is processed. An outside development team that works on your systems under your instructions is a processor. If your company is itself a processor for your customers (a B2B SaaS, say), the offshore team is a sub-processor, and your customer contracts probably require you to tell them about it or get their approval first. Check those contracts before anyone gets production access.
Data that’s been properly anonymised falls outside UK GDPR. Pseudonymised data, where real names are swapped for IDs but could be linked back, is still personal data. Most “test copies” of production databases are the second kind.
What the data processing agreement has to cover
Article 28 of the UK GDPR requires a written contract between controller and processor. It must set out the subject matter and duration of the processing, its nature and purpose, the types of personal data and the categories of people involved. It also has to commit the processor to:
- process the data only on your documented instructions;
- make sure everyone with access is bound by confidentiality;
- apply appropriate security measures (the Article 32 standard);
- use sub-processors only with your authorisation, on equivalent terms;
- help you respond to people exercising their data rights;
- help you meet your security, breach notification and impact assessment obligations;
- delete or return the data when the work ends;
- give you the information you need to show compliance, and allow audits.
On breaches, the processor must tell you without undue delay. You, as controller, then have 72 hours from becoming aware to report a notifiable breach to the ICO. So your DPA should define what “without undue delay” means in hours, and who the contact is on each side.
Ask the team for their own sub-processor list too. Their email provider, password manager, CI service and any AI tools they use can all touch your data.
The international transfer: IDTA or UK Addendum
The ICO updated its international transfers guidance in January 2026 to reflect the Data (Use and Access) Act 2025. It frames the question as a three-step test: does the UK GDPR apply to the data, are you initiating a transfer to an organisation outside the UK, and is that organisation a separate legal entity from you? If all three are yes, it’s a restricted transfer.
Two points catch people out. First, the ICO treats making data accessible to a separate organisation outside the UK as a transfer, so a developer in India logging into your UK-hosted database counts even though the data never “moves”. The ICO’s own guidance uses an India example to make this point. Second, India is not covered by UK adequacy regulations at the time of writing, so you can’t rely on adequacy. Check the ICO’s current list in case that changes.
That leaves appropriate safeguards. For most companies that means one of the ICO’s standard data protection clauses:
- The International Data Transfer Agreement (IDTA), a standalone UK agreement.
- The International Data Transfer Addendum to the European Commission’s standard contractual clauses, useful if you already use the EU SCCs for EEA data. The ICO is clear that the EU SCCs on their own are not valid for restricted transfers under the UK GDPR.
Alongside either one, you complete a transfer risk assessment. The legislation now calls it a “data protection test”, though the ICO still uses the TRA name. The question is whether the standard of protection for people’s data is not materially lower after the transfer. The ICO’s guidance and tools walk through how to do it. For a typical development engagement the assessment looks at what data the team can reach, how access is controlled, and the legal environment in India. India has its own Digital Personal Data Protection Act 2023, which is relevant context but doesn’t replace any of your UK obligations.
The engineering side: keep the transfer small
Paperwork covers the transfer. Good engineering shrinks it. Most development work needs far less real personal data than teams assume:
- No production data in development. Use synthetic seed data, or anonymised extracts where you need realistic volumes.
- Separate environments with separate credentials. Most of the offshore team should never need production access at all.
- Named accounts with MFA for every person, no shared logins, access logged, and access removed the same day someone leaves the project.
- Least privilege on cloud roles. A developer who deploys functions doesn’t need to read the user table.
- Design for data rights from the start. On Crumb Count, a nutrition app we built, the offline sync engine keeps consent fields out of automatic merge entirely, so a stale device can never overwrite a user’s consent choice. GDPR Article 7(1) says you must be able to show consent was given, and that’s much easier to do when the code is built around it.
When orithLabs works with UK clients through staff augmentation, we expect to sign a DPA and an IDTA or Addendum before anyone touches personal data, and we’ll help you scope access so the risk assessment is short. One more time: this is not legal advice, so have your adviser review the documents before you rely on them.