GDPR and a development team outside the EU: how to do it properly

Buyers usually ask this question the wrong way round. They ask “is it allowed to have developers in country X”, when the question that actually determines the answer is “what data does anybody in country X touch, and under what controls”.

Get the architecture right and the legal question becomes small, documentable and boring — which is exactly what you want it to be.

The two questions, separated

Where does personal data live? This is a hosting decision. You control it, and it is largely independent of where your team is.

Who can access it, from where, under what controls? This is an access decision. Also yours to control, and this is where the transfer question actually lives.

A team in Istanbul working on a system hosted in Frankfurt, using masked data in development and holding only named, logged, time-limited production access, is a very different proposition from the same team holding a copy of the production database on laptops. The first is a narrow, documentable arrangement. The second is a transfer of your entire dataset.

Most of the compliance work is choosing the first shape at design time. Retrofitting it afterwards is much harder.

The legal framework, briefly

Transfers of personal data outside the EEA need a lawful basis under Chapter V of the GDPR. Three mechanisms matter in practice:

• Adequacy decision. The Commission has determined the destination offers essentially equivalent protection. Transfer proceeds like an intra-EU one. Türkiye and India do not have one; Poland is in the EU so the question does not arise.
• Appropriate safeguards under Article 46, most commonly the Commission’s standard contractual clauses, supported by a transfer impact assessment considering the destination’s laws on government access.
• Derogations under Article 49, for occasional and limited cases. Not a basis for an ongoing development engagement.

For a supplier outside the EEA, the normal answer is standard contractual clauses plus an Article 28 processor agreement plus a transfer impact assessment. This is routine work that competent counsel completes without drama — provided you can describe the actual data flows accurately, which is why the architecture comes first.

Türkiye’s own regime

If your supplier is in Türkiye, there is a second regime in play, and it moved towards the European model recently.

The March 2024 amendments to Law No. 6698, effective from June 2024, replaced a consent-based approach with a three-tier structure of adequacy decisions, appropriate safeguards and limited occasional exceptions — deliberately closer to the GDPR’s structure. Turkish standard contractual clauses must be used exactly as published by the authority without modification, and notified within five business days of signing.

The practical significance for a European buyer is convergence: a Turkish supplier operating properly under the amended KVKK is already working inside a framework whose vocabulary and obligations map recognisably onto yours.

The architecture that avoids most of the problem

Environment	Data	Who has access	Controls
Production	Real personal data	Named individuals only, temporarily	MFA, logged sessions, time-limited, approval per grant
Staging	Masked or synthetic	Development team	Standard access control
Development	Synthetic only	Development team	Standard access control
Local machines	Never real data	—	Policy plus technical prevention
Backups	Real data	Nobody routinely	Encrypted, same region as production
Logs and errors	No personal data in payloads	Development team	Redaction at source

Five rules that make the table real:

1. Your cloud account, your region. Production infrastructure in an EU or UK region inside an account you own. The supplier gets scoped roles you can revoke in an afternoon, not credentials you would have to ask for back.
2. Masked data in non-production. Realistic in shape, not real in content. This single control removes most of the residual risk, because it means the everyday work of building software touches no personal data at all.
3. Production access is an event, not a state. Requested, approved, time-boxed, logged, revoked. If a developer has standing production access, you have not implemented this.
4. No personal data in logs. Error payloads are where personal data leaks most quietly. Redact at source, not in review.
5. Backups stay in region. Frequently overlooked, and a backup is a full copy of everything.

The contract clauses that matter

Security appendices are often long and empty. These are the provisions that do work:

• Article 28 processor terms with a documented scope of instructions. Processing outside instructions is a breach you can act on.
• Standard contractual clauses in the correct module for controller-to-processor, executed and attached.
• Sub-processor control. A named list, prior notice of changes, and a right to object. Ask specifically about the AI services in the stack.
• Breach notification within a fixed period, stated in hours, not “without undue delay”.
• Deletion or return on termination, with written confirmation and a stated timescale — including backups.
• Audit rights that are exercisable in practice: a documented control set, a right to question it, and a right to inspect on reasonable notice.
• Named access holders. A maintained list of individuals with production access, updated on joiners and leavers.

And, separately from data protection but on the same page: the repository is created in your organisation’s account before the first commit, and cloud accounts and domains are in your name. Ownership you can exercise by logging in survives every scenario that a jurisdiction clause has to be litigated in. More on that in code ownership and lock-in.

If your software includes AI

The EU AI Act adds a classification exercise, and the timeline has moved.

Transparency duties under Article 50 applied from 2 August 2026, catching chatbots and synthetic content. High-risk obligations for stand-alone Annex III systems — hiring, credit scoring, education, critical infrastructure — were deferred to 2 December 2027, and high-risk AI embedded in already-regulated products to 2 August 2028 under the Digital Omnibus package.

Two practical consequences. Classify any AI feature at design time, because if it lands in a high-risk category the documentation and testing obligations change the shape of the project. And treat the model provider as a sub-processor: if user content reaches an external model, that is a data flow requiring the same treatment as any other. We cover the architecture side on the AI process automation page.

A worked example

A German manufacturer engages a Turkish team to build a field service system. Technicians record job details, customer contacts, signatures and photographs. That is personal data, and the transfer question is live.

The wrong shape. A copy of production is restored onto developer machines “so they can test properly”. Screenshots with real customer names appear in the issue tracker. Two developers hold permanent database credentials. The supplier’s own monitoring service, in a third country, receives error payloads containing customer addresses. Every one of these is a separate transfer, most are undocumented, and nobody could produce a complete list of where the data now is.

The right shape. Production runs in Frankfurt in the customer’s own cloud account. Development and staging hold synthetic technicians, synthetic customers and synthetic jobs, generated to match the shape of the real data. Error payloads are redacted before they leave the application. When a production issue requires investigation, a named developer requests access, it is approved, granted for four hours, session-logged, and revoked automatically.

The legal work is then a processor agreement, standard contractual clauses covering that support access, and a transfer impact assessment describing an arrangement that is genuinely narrow. The same project, the same team, the same country — a completely different compliance posture, decided by architecture rather than by paperwork.

The point worth taking from this: almost all of the difference was made by decisions taken in week one at no additional cost. Retrofitting the right shape after production data has spread is expensive and never quite complete.

What to document, and keep current

If a regulator or a customer’s security team asks, these are what you should be able to produce without preparing anything:

• A data flow description. What personal data the system holds, where it is stored, where backups live, and every party who can access it.
• The record of processing activities entry for this system.
• The processor agreement and standard contractual clauses, executed and dated.
• The transfer impact assessment, with the reasoning visible rather than a completed template.
• The current list of individuals with production access, with a date it was last reviewed.
• The access log for a sample period, demonstrating that grants are time-limited in practice and not just in policy.
• The sub-processor list, including any AI or monitoring services.
• Evidence of masking in non-production environments — a description of the process, not an assertion.

Review this set at a fixed interval and on every joiner and leaver. Documentation describing an arrangement that stopped being true eight months ago is worse than none, because it converts an operational gap into a demonstrated failure of governance.

A short due diligence list

Ask a prospective supplier these, and judge the specificity of the answers as much as their content:

1. Where will production data be hosted, in whose account, in which region?
2. Will developers have production access? Named, time-limited, logged?
3. What data will exist in development environments, and how is it masked?
4. Which sub-processors are involved, including AI services?
5. Who holds credentials today, and what happens when one of them leaves?
6. What is the breach notification commitment, in hours?
7. What happens to every copy of the data on termination, and how is that confirmed?

Vague answers to concrete questions are the finding. A supplier who has thought about this answers in specifics without needing to consult anyone.

Background on how we work with European buyers is on the nearshore development page, the segments we build for on who we build for, delivery bands on the pricing page, and an engagement can be scoped through the quote form.

Frequently asked questions

Can an EU company use a development team outside the EU under GDPR?

Yes. Non-EU processing is routine and lawful when the transfer rests on an appropriate safeguard. For countries without an adequacy decision, that normally means standard contractual clauses under Article 46, supported by a transfer impact assessment. What is not acceptable is transferring personal data without deciding which mechanism applies.

Does Türkiye have an EU adequacy decision?

No. Transfers from the EU to Türkiye rely on standard contractual clauses or another Article 46 mechanism. Separately, Türkiye's own regime changed: March 2024 amendments to Law No. 6698 introduced a three-tier framework of adequacy decisions, appropriate safeguards and limited exceptions, with Turkish standard contractual clauses that must be notified to the authority within five business days of signing.

Is remote access to EU-hosted data a transfer?

Under the prevailing regulatory view, yes — remote access from a third country is treated as a transfer even when the data never leaves the EU server. That does not make it unlawful; it means it needs the same safeguard as any other transfer. The advantage is that the scope is far smaller and far easier to document and control.

What is the simplest compliant architecture?

Production data in an EU or UK cloud region inside your own account. Developers work against masked or synthetic data in non-production environments. Production access is named, time-limited, logged, and granted only for specific incidents. Personal data leaves the production environment only in aggregate or anonymised form.

What should the contract include?

An Article 28 processor agreement with a documented instruction scope, standard contractual clauses where required, sub-processor approval, breach notification within a fixed period, deletion or return on termination, audit rights, and named individuals who hold access. Vague security appendices are common and worth almost nothing.

Does the EU AI Act affect this?

It can, if the software uses AI. Transparency duties under Article 50 applied from 2 August 2026, while high-risk obligations for stand-alone Annex III systems were deferred to 2 December 2027 and embedded high-risk systems to 2 August 2028 under the Digital Omnibus package. If your build includes AI features, classify them early rather than at the end.

Related guides

• Enterprise AI assistant security: where the data actually goes
• Human-in-the-loop AI: designing the approval step
• Gulf e-invoicing: what ZATCA and the UAE mandate actually require from your systems

Service page: Custom software service