If an external engineering team will touch your users' personal data, UK GDPR follows that data wherever it goes. This guide explains, in plain English, when a transfer becomes a restricted international transfer, what a DPA and the IDTA each do, and the safeguards to put in writing before anyone gets access.
Under UK GDPR, you remain the data controller even when an external development team processes personal data on your behalf. You need an Article 28 DPA to govern that processing, and — if the team is in a country without UK adequacy status — an IDTA (or the UK Addendum to the EU SCCs) plus a transfer risk assessment to legalise the cross-border element. If the team only works on synthetic or anonymised data, there is no restricted transfer and no IDTA is required. This is a plain-English explainer, not legal advice.
UK GDPR restricts sending personal data outside the UK to a country that the UK has not deemed to offer "adequate" protection. The phrase that matters is restricted transfer: it happens when a UK controller or processor makes personal data accessible to a receiver in a non-adequate country. Crucially, remote access counts — if an engineer abroad can read production records on your servers, that is a transfer even though no file is "sent" anywhere.
So the first thing to establish is not where the team sits, but what data they can actually see. Many builds never expose real personal data at all.
| Scenario | Restricted transfer? | Mechanism |
|---|---|---|
| Synthetic / anonymised data only | No | None |
| Pseudonymised, no re-ID access | Usually no | DPA good practice |
| Real data, adequate country | No | DPA |
| Real data, non-adequate country | Yes | DPA + IDTA + TRA |
People use "DPA" and "IDTA" loosely, but they solve different problems and you usually need both. The DPA governs how personal data is processed; the IDTA legalises moving it across the UK border to a non-adequate country.
The contract between you (controller) and the development team (processor). It binds the team to process data only on your documented instructions, keep it confidential and secure, and return or delete it at the end.
The UK's standard transfer agreement, published by the ICO. It is the cross-border safeguard you put in place when data goes to a country without UK adequacy. Alternatively, the UK Addendum bolts onto the EU SCCs.
The Transfer Risk Assessment. Before relying on an IDTA you document whether the destination's laws and practices could undermine the protection the IDTA promises — and what extra measures close any gap.
The ICO publishes the IDTA, the Addendum and a TRA tool free of charge at ico.org.uk.
Article 28 sets out the minimum a DPA must include. If a development team offers you a contract, this is the list to check it against. Anything missing is a gap you will own as the controller.
Beyond the legal minimum, the practical safeguards below are what keep an engagement clean in day-to-day work. Demand them in writing — a serious team will already operate this way.
List what personal data the build genuinely needs and at what stage. Most development never needs real production records — decide what can be synthetic or masked.
You are the controller; the team is the processor. Record that in an Article 28 DPA covering the points in the checklist above.
Establish where data will be accessible from. If that includes a non-adequate country, a restricted transfer occurs and you move to the IDTA.
Use the ICO's IDTA (or the Addendum to the EU SCCs) for the cross-border element, signed before any access is granted.
Document the transfer risk assessment and any extra technical measures — encryption, pseudonymisation, access controls — that protect the data in practice.
Grant least-privilege, named access with MFA and audit logging. Keep production data out of reach unless it is genuinely required.
We are a globally distributed team of senior, fluent-English engineers working UK hours, and we design engagements to keep personal data exposure to a minimum. In most projects our engineers build and test against synthetic or anonymised data, with production access restricted to a small, named, audited group only when there is a real need.
Where a restricted transfer is unavoidable, we sign a UK-GDPR-compliant DPA and put an IDTA in place, supported by a transfer risk assessment and the technical measures above. Repositories and cloud accounts are client-controlled from day one, and you own all code and IP under UK law. The result is a build that is straightforward to defend to your DPO or the ICO. For a fuller picture, see our UK offshore software development page and the UK market hub.
Book a free 30-minute scoping call in UK hours. We will walk through how your data would be handled, what a DPA and IDTA would cover, and how to keep personal data exposure to a minimum.
Book a free scoping call →