GDPR Outsourcing Requirements for Software Development Outside the EU

Yes, you can outsource software development to a team outside the EU under the GDPR. The regulation doesn't ban offshore teams.

It regulates personal data: who may touch it, on whose instructions, and from where.

That last part catches buyers out. If a vendor's engineers in Kathmandu can open your EU customer data, even only on screen, that's a transfer out of the EU. That's the view of the European Data Protection Board (EDPB, 2023), set out in guidelines quoted below. The requirements therefore turn on one question: can your developers reach personal data?

Below: the GDPR outsourcing requirements to meet before access starts, how to keep most work away from personal data, and a checklist.

GDPR outsourcing requirements at a glance

GDPR outsourcing requirements come down to six things you put in place before an outside team can reach personal data. Personal data means any information about an identifiable person, such as a customer's name, email address or order history.

1. Know the roles. You're the controller; your vendor is a processor acting on your instructions.
2. Sign a data processing agreement (DPA) with the terms Article 28 of the GDPR requires.
3. Pick a transfer tool for access from a country without an EU adequacy decision, usually standard contractual clauses.
4. Write a transfer impact assessment if you rely on those clauses: can the vendor keep its promises under local law?
5. Minimize and secure. Keep personal data out of development and protect the rest (Articles 25 and 32).
6. Control sub-processors and breach notice. Approve every tool that touches the data, and agree how fast you hear about a breach.

If you can't point to each of the six, signed or written down, don't hand over credentials yet.

Three numbers set the stakes:

Controller and processor roles in outsourcing

When you outsource development, you stay the controller and the vendor becomes your processor. The controller is whoever decides why and how personal data is used. The processor is the company that handles it only on the controller's documented instructions.

Think of a renovation. You own the house, and the contractor gets a key plus a written list of rooms they may enter. If they read your mail in the study, you still answer for who got the key.

Say you run a Berlin SaaS company with a development team in Kathmandu. The team may process your customers' data only for the work you've commissioned, in the ways your contract allows.

A processor outside the EU that isn't itself subject to the GDPR is bound indirectly, through that Article 28 contract (EDPB Guidelines 3/2018, 2019). Supervision stays at home: a German company answers to its own state's data protection authority, and a Dutch one to the Autoriteit Persoonsgegevens. More on each market in offshore development for German companies and offshore development for Dutch companies.

Does GDPR apply to companies outside the EU?

Yes, directly, when a company outside the EU has an EU establishment, offers goods or services to people in the EU, or monitors their behavior there (GDPR Article 3, 2016). A development vendor working for you usually does none of these, so the GDPR reaches it another way.

It reaches the vendor through you. Your data processing agreement imposes GDPR obligations on it. Where you use them, the standard contractual clauses also give the people whose data it is rights they can enforce. You remain accountable for what the vendor does with anything you let it reach.

So when you're vetting an offshore development partner, treat "the GDPR doesn't apply to us" as a warning sign. The contract is exactly how it applies.

Singapore's PDPA works the same way for customer data from Singapore: the overseas vendor sits outside the Act, so your contract carries the obligations (see the PDPA overseas transfer rules for offshore teams).

Australia's Privacy Act takes the same route: APP 8 needs a contract with the overseas vendor, and section 16C keeps you accountable for it (see APP 8 rules for offshore software teams).

Data processing agreement requirements

Article 28(3) of the GDPR says the contract must describe the processing and commit the vendor to eight obligations. The description covers the subject matter, duration, nature and purpose, the types of personal data, and whose data it is (GDPR Article 28, 2016).

Test row (g) with a scenario. When the engagement ends, where do copies sit: laptops, a staging database, CI logs, a backup bucket? The agreement should name them and set a deletion deadline, with written confirmation.

The DPA sits in the same contract stack as your IP assignment clause, and it makes sense to negotiate them together. For the ownership side, see who owns the code your vendor writes.

Serving Californians too? A GDPR DPA alone usually falls short of the CCPA, so add a California section; see what a CCPA service provider contract needs.

Transferring personal data outside the EU

A transfer happens whenever a separate company outside the EU (strictly, the EEA), such as your vendor, can reach your personal data. You don't have to send it a file. The EDPB counts remote access from a third country "even if it takes place only by means of displaying personal data on a screen" (EDPB Guidelines 05/2021, 2023).

Its own example reads like offshore development. A processor outside the EU remotely accesses its EU clients' data for support. The verdict: that's a transfer, and Chapter V of the GDPR applies.

Chapter V gives you three routes, checked in order:

1. 1

   An adequacy decision

   The European Commission has 17 adequacy decisions in force, the latest for Brazil in January 2026 (European Commission, 2026). Nepal, India, Vietnam, the Philippines and Ukraine aren't among them. The US counts only for companies certified under the Data Privacy Framework.

2. 2

   Standard contractual clauses (SCCs)

   The EU's 2021 clauses have modules: Module 2 (controller to processor) for your vendor, Module 3 for its own sub-processors (European Commission, 2021). You can't change their wording, but you choose the options, fill in the annexes and may add safeguards that don't contradict them.

3. 3

   A derogation

   Explicit consent is one example. Derogations are narrow exceptions that must not become the rule, and a vendor's regular, direct access to your database isn't occasional use (EDPB Guidelines 2/2018, 2018).

Signing SCCs isn't the end. In its 2020 Schrems II ruling, the EU's top court added a duty: check whether the destination's laws let the vendor keep its promises (CJEU, C-311/18, 2020). Where they don't, you add supplementary measures, such as encryption the vendor can't undo, which only works when the vendor never needs to read the data. That check is the transfer impact assessment, or TIA (EDPB Recommendations 01/2020, 2021).

A TIA records what data the team can reach and how, and the destination's laws and practice on government access. It also notes any past requests the vendor has received, and the measures that close the gap. You own it; the vendor supplies the facts about its local law. Review it at set intervals.

Regulators treat transfer failures as serious. Meta used SCCs without measures that worked (Irish Data Protection Commission, 2023). Uber moved drivers' data to the US for over two years with no transfer tool at all (EDPB, 2024).

TikTok's case is the one to remember. It concerned "remote access to personal data stored in Singapore and the United States by personnel based in China" (Irish DPC, 2025). No data had to be copied to China; staff there only had to be able to open it. The other €45 million was for not telling users clearly about those transfers (Article 13).

Now a worked example of the fine caps. Transfer failures fall under Article 83(5): up to €20 million or 4% of worldwide annual turnover, whichever is higher. At €15 million turnover, 4% is €600,000, so your cap is €20 million. Article 28 and 32 failures carry €10 million or 2%: for you, €10 million, not €300,000 (GDPR Article 83, 2016). These are maximums, not typical fines, but a small turnover doesn't lower the cap.

Before the first credential is issued, have the signed SCC module and your written TIA in hand, with the vendor's input on local law.

GDPR-compliant software development practices

The most effective GDPR requirement is the one you design out. If your developers can't reach personal data, nothing is transferred, and the transfer rules don't touch their work.

Most development tasks don't need real customer data: building features, writing tests, reviewing code, running CI (the automated build-and-test pipeline). These practices keep it that way:

• Synthetic test data. Generate realistic fake records from seed scripts kept in the repository.
• No "masked" production copies. Pseudonymized data, with names swapped for codes you can trace back, is still personal data in your hands (GDPR Recital 26, 2016). Synthetic or truly anonymous data isn't.
• No standing production access. Grant "break-glass" (one-off, emergency-style) access per task: approved, time-limited, logged and reviewed.
• EU hosting for data and backups, so you can revoke access in one step.
• Clean logs and tickets. Keep personal data out of logs, error trackers and pasted screenshots.
• Secrets in a vault, with named accounts and multi-factor authentication (MFA) for everyone.

Back to the Berlin company. It splits its roadmap into code-only tasks on synthetic data and a short list of data-touching ones, such as production debugging. Only that list goes through break-glass access under the SCCs. The SCCs and TIA then cover a few logged sessions, not the whole team every day.

Count the roadmap items that truly need real customer data. For most products, it's a short list.

Planning a build with a team outside the EU? A free 30-minute scoping call can map which work runs on synthetic data and which needs personal-data access.

Sub-processors in your vendor's toolchain

Every tool your vendor uses to hold or process your personal data is a sub-processor: code hosting, issue tracking, chat, error monitoring, cloud hosting.

Article 28(2) requires your written authorization before the vendor adds one: specific, or general with advance notice of changes and a right to object. Article 28(4) passes the same obligations down and leaves the vendor fully liable if its sub-processor fails (GDPR Article 28, 2016).

Sub-processors outside the EU need a transfer tool too: Module 3 SCCs, or the Data Privacy Framework for certified US providers. The EU General Court upheld that framework in September 2025 (General Court, T-553/23, 2025), and an appeal to the Court of Justice was lodged that October (C-703/25 P, 2025).

The risk is real: Verizon found a third party involved in 48% of breaches in its 2026 report, up from 30% in its 2025 report (Verizon, 2025). Get the sub-processor list as a DPA annex, and keep personal data out of tickets and chat.

Breach notification across time zones

Your vendor must report a breach to you "without undue delay" (GDPR Article 33, 2016). Unless the breach is unlikely to put people at risk, you notify your regulator within 72 hours of becoming aware, or explain the delay. In principle, you're aware once the vendor tells you (EDPB Guidelines 9/2022, 2023). So the contract decides how fast that is.

Here's a worked example on an illustrative Thursday in January. Kathmandu is 4 hours 45 minutes ahead of Berlin in winter, 3 hours 45 minutes in summer.

At 16:00 in Kathmandu (11:15 in Berlin), a vendor engineer finds real customer records exposed in staging. That will usually meet the risk bar.

Three contract terms close the gap. Set a notice deadline in hours, not "promptly". Name an out-of-hours contact on both sides. And ask for phased reporting, as the EDPB recommends: what the vendor knows now, then the details.

When offshore development is the wrong choice

Offshore development is the wrong choice when the work needs routine access to sensitive personal data that your TIA can't show is protected. No contract fixes that.

It's likely in four situations:

• Daily work on health or other special-category data (Article 9), such as debugging a clinical records system against real records.
• Customer contracts that require EU-only processing.
• Roles where production access is the job, such as support engineering or data operations.
• A TIA that finds government access no measure can offset, the heart of the Meta and TikTok decisions.

Then keep the data-touching roles in the EU and send only code-only work offshore, or don't outsource that part.

GDPR outsourcing compliance checklist

Run this before the first credential is issued. If a box stays empty, the access can wait.

• To do: A data map of what the team will touch
• To do: A signed DPA covering every Article 28(3) term, annexes filled in
• To do: Where no adequacy decision applies: SCCs signed (Module 2 with the vendor; Module 3 or DPF certification down the chain)
• To do: A written TIA for each SCC transfer, plus the supplementary measures it calls for
• To do: An approved sub-processor list
• To do: Privacy notice and records of processing updated to name the transfer and its safeguard (Articles 13, 14 and 30)
• To do: Synthetic test data in every non-production environment
• To do: Break-glass production access with time limits, logging and MFA
• To do: A breach notice deadline in hours, with named contacts
• To do: Deletion at exit, confirmed in writing
• To do: A date to review the TIA and sub-processors

GDPR outsourcing FAQ

GDPR outsourcing requirements in order

GDPR outsourcing requirements are a sequence: roles, DPA, transfer tool and TIA, data designed out of development, sub-processors, breach clock. The less personal data your team can reach, the less risk and paperwork you carry.

This is general information, not legal advice.