The moment an engineer outside the UK can see a customer record in your system, you have made an international transfer of personal data under UK GDPR, even if nothing was ever downloaded. The ICO uses almost exactly that example: a UK business that lets a supplier in India access personal information on its systems is making a restricted transfer. The good news for anyone outsourcing software development is that most builds do not need that access at all.
This guide is for UK companies using offshore, nearshore or UK-contracted teams with engineers abroad. It explains when access counts as a restricted transfer, which contracts you need, what changed with the Data (Use and Access) Act, and the engineering controls that keep personal data out of development. It is not legal advice, and it does not cover transfers from the EU under EU GDPR or sector rules such as NHS data security requirements.
What is the International Data Transfer Agreement (IDTA)?
The International Data Transfer Agreement (IDTA) is the ICO's standard contract for sending, or giving access to, UK personal data to an organisation in a country without UK adequacy regulations. The UK Addendum is the alternative that adapts EU standard contractual clauses. Both must be backed by a transfer risk assessment.
Is your outsourced team making a restricted transfer?
The ICO's three-step test decides it (ICO brief guide to international transfers, January 2026). You are making a restricted transfer if all three are true:
- UK GDPR applies to your processing of the personal data.
- You initiate sending the data, or making it accessible, to an organisation outside the UK.
- The receiving organisation is a separate legal entity from you.
Two details matter for software projects. First, "making accessible" counts; remote access to a database, admin panel, log system or support tool is enough. Second, the rules apply wherever you sit in the chain: controller, processor or sub-processor. If your UK supplier gives its overseas team access to your data, that supplier is initiating a transfer and must cover it.
Three common outsourcing setups
| Setup | Restricted transfer? | What you need |
|---|---|---|
| Offshore engineers build and test using synthetic data, with no access to production or real user data | Usually no transfer of personal data for the build itself | Contract terms that prohibit access, plus technical controls that enforce it |
| You contract with a UK company whose engineers abroad can access production for support or debugging | Yes, from the UK company to its overseas team or affiliate | An Article 28 processor agreement with the UK company, and a transfer safeguard and risk assessment held by it, which you should see |
| You contract directly with an overseas development company that can access personal data | Yes, from you | An Article 28 processor agreement, the IDTA or UK Addendum, and your own risk assessment |
Countries in the EEA are covered by UK adequacy regulations, so a Polish or Portuguese team does not need the IDTA, though you still need a processor agreement. Common offshore locations such as Pakistan and India do not have UK adequacy regulations, so an appropriate safeguard is required. We compared the delivery models more broadly in London vs offshore vs nearshore development.
The contracts you need
A processor agreement (DPA)
Any supplier that processes personal data on your behalf is a processor, and UK GDPR Article 28 requires a written contract. It must cover the subject matter, duration, nature and purpose of processing, the types of personal data and categories of people, and your rights and obligations. The processor must act only on your documented instructions, keep staff under confidentiality, apply appropriate security, use sub-processors only with your authorisation, help you meet individuals' rights and breach duties, delete or return data at the end, and allow audits. The ICO's guidance on controller-processor contracts lists the terms in full.
The IDTA or UK Addendum
Where a restricted transfer goes to a country without adequacy, the party making it needs an appropriate safeguard, most commonly the IDTA or the Addendum (ICO: the IDTA and the Addendum). Use the IDTA when the whole arrangement is UK-focused. Use the Addendum when you already rely on EU standard contractual clauses because you also transfer EU data.
A transfer risk assessment, now the "data protection test"
The Data (Use and Access) Act turned the transfer risk assessment into a statutory test from 5 February 2026: after the transfer, the level of protection must not be materially lower than under UK law, and exporters must act reasonably and proportionately when deciding (GOV.UK UK GDPR and DPA factsheet). In practice the assessment looks at the destination's laws on government access, the type and sensitivity of the data, and the technical and contractual protections in place. Strong controls that limit what engineers can see make the test much easier to pass. Our guide to the Data (Use and Access) Act for apps and SaaS covers the Act's other changes.
Engineering controls that keep personal data out of development
Contracts make a transfer lawful. Architecture decides whether you need one. These are the controls we recommend on every outsourced build.
- Synthetic or properly anonymised test data. Generate realistic fake records for development and staging. Pseudonymised data, where records can be re-linked, is still personal data.
- No standing production access for developers. Deployments run through CI/CD; engineers do not need to read the production database to ship.
- Break-glass access for incidents. Time-limited, approved by a named person in the UK, logged and reviewed afterwards.
- Masked support tooling. Admin panels and logs that hide names, emails, payment details and free-text fields by default.
- Least privilege with SSO and MFA. Separate roles for build, deploy and support, enforced through your identity provider. The same controls are required for Cyber Essentials, as covered in our Cyber Essentials guide for SaaS companies.
- UK or EEA hosting. Keep data in UK regions such as AWS London, Azure UK South or Google Cloud London where customers expect it. Hosting location does not remove a transfer if people abroad can access the data, but it limits copies.
- Deletion at the end. Remove supplier accounts, rotate credentials and get written confirmation that no copies remain.
A buyer's checklist before your team gets access
- Map the data. List every system the supplier will touch and whether it contains personal data.
- Decide whether access is necessary. Default to no production personal data for build work.
- Identify each legal entity in the chain, including affiliates and freelancers, and where their people are.
- Sign an Article 28 processor agreement that names sub-processors and their locations.
- Put the transfer safeguard in place where access to personal data from a non-adequate country is needed, and see a copy if your supplier holds it.
- Complete and file the risk assessment, recording the controls that reduce risk.
- Enforce the controls technically: roles, MFA, masking, logging and break-glass approval.
- Update your privacy notice and records to reflect processors and international transfers.
Most of these terms belong in the main development contract as well; see clauses on data, security and exit in our software development contract checklist.
Frequently asked questions
Do I need an IDTA to use offshore developers?
Only if personal data is sent to or made accessible to them in a country without UK adequacy regulations. If your offshore team builds and tests with synthetic data and has no access to real personal data, there is usually no restricted transfer for that work. If they can access production data, you or your UK supplier need the IDTA or UK Addendum and a risk assessment.
Is remote access to a UK database an international transfer?
Yes, if the person accessing it works for a separate organisation outside the UK. The ICO treats making personal data accessible as a transfer, not only sending copies. Its own example is a UK business giving a supplier in India access to customer data on the UK business's systems.
Does Pakistan or India have UK adequacy?
No. Neither country is covered by UK adequacy regulations, so access to UK personal data by organisations there needs an appropriate safeguard such as the IDTA or UK Addendum, backed by a transfer risk assessment. EEA countries are covered by UK adequacy regulations.
What is the difference between the IDTA and the UK Addendum?
The IDTA is a standalone UK transfer agreement. The Addendum is a short document that amends the EU standard contractual clauses so they also work for UK transfers. Companies transferring only UK data often use the IDTA; companies that already use EU clauses for EU data usually add the Addendum.
Does hosting data in the UK solve the transfer problem?
Not on its own. UK hosting keeps stored copies in the UK, but if engineers or support staff at a separate organisation abroad can access the data, a restricted transfer still happens. Hosting location and access controls work together.
Key takeaways
- Letting a separate organisation abroad access personal data is a restricted transfer, even without copying it.
- Build with synthetic data and no standing production access, and most outsourced development needs no transfer at all.
- Any processor needs an Article 28 agreement; non-adequate destinations such as Pakistan and India also need the IDTA or Addendum.
- Since 5 February 2026 the risk assessment is a statutory test: protection must not be materially lower than UK law.
- UK hosting helps but does not remove a transfer if people abroad can see the data.
Outsource the build, not your data
If you want offshore engineering without handing personal data to anyone abroad, tell us about your system. You contract with our UK company, with our London office at 2-7 Clerkenwell Green, EC1R 0DE, as your point of contact, and we will propose a setup where development runs on synthetic data, production access is break-glass only, and every data flow is written down for your data protection lead. Where your project genuinely needs access to real data, we will show you exactly which safeguard covers it. See our custom software development service.