GDPR-compliant offshore development: a practical guide for EU and UK buyers

The short answer

Hiring developers outside the EU is legal under GDPR. GDPR regulates personal data, not where your engineers live.

If your developers never see personal data, most GDPR questions fall away. If they do see it, even through remote access to an EU server, you need the right contracts and a written risk assessment.

In practice that means three things:

• A data processing agreement (DPA) under Article 28.
• The EU Standard Contractual Clauses, or the UK IDTA or Addendum for UK data.
• A transfer impact assessment, plus technical measures that cut what the vendor can see.

The setup we recommend keeps data in your EU region, gives developers synthetic data, and lets a few named engineers into production through logged sessions.

What GDPR requires when developers outside the EU touch your data

Your vendor is a processor

An agency that builds or runs software processing your customers' data, on your instructions, is your processor. Article 28 says that relationship must sit in a binding contract.

The contract has to cover, among other things:

• Processing only on your documented instructions.
• Confidentiality for everyone with access.
• Security measures.
• No sub-processors without your permission.
• Help with data subject requests.
• Deletion or return of data at the end.
• Audits and the information you need to check compliance.

Remote access counts as a transfer

Many buyers assume that if data stays on an EU server, nothing is transferred. That is wrong.

The EDPB's Guidelines 05/2021 treat making data available to an importer in a third country, including by remote access, as a transfer under Chapter V. A developer in Pakistan who can query your EU database is receiving a transfer. Data residency lowers the risk. It does not remove the paperwork.

Pakistan has no adequacy decision

The European Commission has recognised a short list of countries as adequate. It includes the UK, Switzerland, Japan, South Korea, Canada (commercial organisations) and the US under the Data Privacy Framework. Pakistan is not on it.

Without adequacy, you need an Article 46 safeguard. For a vendor relationship, that means the Standard Contractual Clauses.

Pakistan's own data protection law

Pakistan has no comprehensive data protection law in force and no data protection authority. A Personal Data Protection Bill has been in draft for years. It has completed public consultation, but when we checked in November 2026 it had not been passed by Parliament.

Sector rules and the Prevention of Electronic Crimes Act 2016 punish misuse of personal data. They are not a GDPR equivalent. Your protection comes from the contracts and the technical setup.

The documents you need

The SCCs come from Commission Implementing Decision (EU) 2021/914 of 4 June 2021. They have four modules: controller to controller, controller to processor, processor to processor, and processor to controller.

You don't rewrite the clauses. You fill in the annexes: the parties, data categories, purposes and security measures. That annex work is where most of the real thinking happens.

The transfer impact assessment

Since the Schrems II judgment in 2020, signing the SCCs is not enough on its own. You must check whether the destination country's laws or practices would stop the importer honouring them. The SCCs build this in: the exporter assesses, and the importer helps.

The EDPB's Recommendations 01/2020 set out six steps. Map the transfer, pick the tool, assess the country, add supplementary measures, complete any formalities, and re-check over time.

For Pakistan, the TIA should cover the missing general data protection law and whether public authorities could demand data from the vendor. The practical answer is to make the transfer small. The EDPB accepts strong encryption and pseudonymisation as effective measures when the exporter alone holds the keys or the re-identification data. Keep both in the EU.

How to keep personal data in the EU while building offshore

Good compliance work happens in the architecture, not the contract. These are the patterns we use.

• Production stays in your EU region. Databases, storage, backups and logs live in your own cloud account, for example in Frankfurt or Dublin.
• Developers build against synthetic data. Seed scripts generate realistic fake records. Most engineers never need a real customer row.
• Pseudonymise when real shape matters. Swap names, emails and IDs for tokens. Keep the lookup table in the EU, out of the vendor's reach.
• Minimise production access. Two or three named engineers, short-lived credentials, MFA, and every session logged. No database dumps on laptops.
• Your accounts, your keys. The vendor works inside your cloud and repositories. Encryption keys stay in your key management service. Access is revoked at handover.
• Secrets stay out of code and chat. Use a secrets manager, and rotate credentials when people leave or the project ends.
• Write it down. Your records of processing and your TIA should describe these controls. They are your supplementary measures.

We used the same idea for a Canadian registry business. All data stays in Canada's ca-central-1 region, and two businesses run from one codebase with separate databases and Stripe accounts (see the case).

Can an AI chatbot or RAG system be GDPR compliant?

Yes. The extra risk with AI is that prompts, documents and chat logs flow to a model provider you may not have thought about. Treat the model as a sub-processor and decide where it runs.

Option 1: an EU-region model API

The large providers now offer regional processing, with different scopes:

• OpenAI offers European data residency for eligible API projects. Requests are handled in-region and are not stored at rest. It has to be chosen when you create a new project.
• Azure OpenAI has an EU Data Zone deployment that processes prompts and responses within the EU Data Boundary. That boundary can include EFTA countries such as Norway and Switzerland.
• Anthropic's own API offers US-only or global inference at the time of writing, not an EU option. Claude models on Amazon Bedrock have an EU cross-region profile that routes only between European regions.

Check the details for your exact model and endpoint. Global endpoints can route requests anywhere in the world.

Option 2: a self-hosted open-weight model

For sensitive data, run an open-weight model on servers in your own EU cloud account. Nothing goes to a third-party API, so no model provider sits in the data flow.

The trade-off is hosting cost and some quality gap against the largest hosted models. For narrow tasks such as search, extraction and support answers, that gap is often small.

We built this for a US B2B distributor. Their AI shopping assistant runs on open-weight models on their own servers, so customer data never leaves their environment (see the case).

Controls that matter for any AI system

• No training on your data. Get it in writing from the vendor, and check the model provider's terms.
• Retention. Decide how long prompts, outputs and chat logs are kept. Default to short.
• Logging without hoarding. Log enough to debug and audit. Redact personal data from logs where you can.
• Permissions in retrieval. A RAG system must only return documents the user is allowed to see.
• Erasure. Plan how to delete a person's data from the vector index, not just the database.
• DPIA. Do one if the system handles personal data at scale, profiles people or touches special category data.

Our LLM and RAG development and AI security work is built around these controls.

What the EU AI Act means for buyers of AI systems

The AI Act applies in stages, and some dates moved in 2026. The AI Omnibus, Regulation (EU) 2026/1744, entered into force on 27 July 2026 and pushed back the high-risk rules.

For most buyers, the practical points are short.

• Most business chatbots and RAG tools are not high-risk. They do face the transparency rule: people must know they are dealing with an AI.
• The general-purpose AI rules mainly bind the model makers, not the business building on their models.
• High-risk uses need early planning. If your system helps decide on hiring, credit, education or similar, plan risk management, logging, human oversight and documentation now. December 2027 is not far away for a build that starts today.
• Your role matters. If you put a system into service under your own name, you are usually treated as its provider, even when an agency built it. Agree in the contract who prepares the technical documentation.

This area is still moving. Check the current text, or ask counsel, before you rely on any date.

What changes for UK data

UK GDPR works the same way in principle, with its own transfer tools. For UK personal data, the EU SCCs alone are not enough.

Use the UK International Data Transfer Agreement (IDTA), or the UK Addendum attached to the EU SCCs. Both came into force on 21 March 2022. The old SCCs stopped working for UK transfers after 21 March 2024.

The Data (Use and Access) Act 2025 changed the test. From 5 February 2026, the question is whether protection abroad is 'not materially lower' than in the UK, judged reasonably and proportionately. Existing IDTAs and Addenda remain valid. You still need a transfer risk assessment, and the ICO publishes a tool for it.

If you hold both EU and UK data, the common approach is one set of EU SCCs with the UK Addendum attached. The EU renewed its adequacy decision for the UK in December 2025, so EU-to-UK flows stay simple.

A checklist for EU and UK buyers

1. Map what personal data the project touches, and whether developers need any of it.
2. Keep production data, backups and logs in your EU or UK cloud region.
3. Give developers synthetic or pseudonymised data by default.
4. Sign an NDA, a services agreement with IP assignment, and a DPA.
5. Sign the EU SCCs (Module 2 or 3), plus the UK Addendum or IDTA for UK data.
6. Write a transfer impact assessment and list your supplementary measures.
7. Approve the sub-processor list, including any AI model provider and its region.
8. Run a DPIA if the processing is high-risk.
9. Limit production access to named people, with MFA, short-lived credentials and logging.
10. Agree retention for prompts, chat logs and test data, and confirm no training on your data.
11. Check where any AI system sits under the AI Act, and who prepares its documentation.
12. Plan offboarding: revoke access, rotate credentials, and get written confirmation that data was deleted.

How we handle GDPR at Sysvoy

We are a software studio in Lahore, Pakistan. We build AI agents, LLM and RAG systems, and SaaS for buyers in the US, UK and Europe. This is our default way of working.

• We sign a data processing agreement and the EU Standard Contractual Clauses with every client whose personal data we handle.
• NDA before you share any detail.
• We work in your cloud accounts and repositories from day one. Access is least-privilege and revoked at handover.
• Your data is never used to train models.
• For sensitive data we deploy self-hosted models, so nothing goes to a third-party API.
• You own 100% of the IP, assigned in the contract.
• Handover includes architecture docs, runbooks and rotated credentials.

We have delivered a multi-agent AI security platform for a European cybersecurity company, in fixed-price phases (see the case).

Want a second opinion on your setup, or a team that already works this way? Book a call. For rates, time zones and contracts, read our guide to offshore software development in Pakistan.