Short answer: Two things need to be handled before a non-EU development partner touches your systems. First, data protection: your vendor is normally a processor, which requires a written data processing agreement, and any transfer outside the EEA to a country without an adequacy decision needs an Article 46 safeguard, in practice Standard Contractual Clauses plus a transfer impact assessment. Second, intellectual property: ownership does not transfer automatically in every jurisdiction, so the contract must assign it explicitly and require source code delivery.
This article is general information, not legal advice. Have your own counsel review your specific arrangement.
Is your vendor a controller or a processor?
In almost all outsourced development you are the controller and the vendor is the processor: they handle personal data on your instructions, for your purposes. That classification triggers a specific obligation, namely a written data processing agreement covering the subject matter, duration, nature and purpose of processing, the categories of data and data subjects, and the vendor's obligations.
Two situations change the picture. If the vendor uses a cloud host, an error-tracking service or a subcontractor, those are sub-processors and need your authorisation, so ask for the current list and for notice before it changes. And if the vendor only ever sees synthetic or properly anonymised data, most of this falls away, which is the cleanest option and worth designing for.
The transfer question
If your vendor is outside the EEA, transferring personal data to them requires a lawful basis for that transfer, separate from your basis for processing. There is a hierarchy.
- Adequacy decision. If the European Commission has decided the country provides adequate protection, no additional safeguard is needed. Adequacy status changes over time, so verify the current position rather than relying on a blog post, including this one.
- Article 46 safeguards. Where there is no adequacy decision, the standard route is Standard Contractual Clauses accompanied by a transfer impact assessment considering the destination country's laws and any supplementary measures needed.
- Derogations. Article 49 exceptions exist but are narrow and not a basis for routine, ongoing transfers.
On Turkey specifically: Turkey does not hold an EU adequacy decision, so transfers of EU personal data to a Turkish processor generally rely on Standard Contractual Clauses plus a transfer impact assessment. Turkey has its own data protection law, the KVKK, which is structurally similar to European data protection law, so vendors working on domestic enterprise projects are typically familiar with the concepts. UK transfers use the UK's own International Data Transfer Agreement or the Addendum to the EU clauses.
The simplest way to reduce transfer risk
Rather than solving the transfer problem, remove it. Three practical patterns:
| Pattern | How it works | Trade-off |
|---|---|---|
| EU-hosted production | Live system runs in your region, vendor develops remotely | Vendor needs access for support, so scope it |
| Synthetic development data | Developers never see real records | Requires effort to generate realistic test data |
| Anonymised extracts | Production data is stripped before it leaves | Anonymisation must be genuine, not pseudonymisation |
Note the distinction in the third row. Pseudonymised data is still personal data under GDPR. Only genuinely anonymised data falls outside scope, and that bar is higher than most teams assume.
Access control and support
Even with production data hosted in the EU, someone eventually needs to debug a live issue. Handle it deliberately:
- Named individuals with named accounts, no shared credentials
- Time-boxed, approved access rather than standing access
- Access logging you can review
- Multi-factor authentication as a contractual requirement
- A defined offboarding process when someone leaves the vendor's team
Write these into the data processing agreement rather than assuming them.
Intellectual property: what the contract must say
IP does not always transfer automatically to the party that paid for the work. The rules differ by jurisdiction and the safe assumption is that nothing transfers unless the contract says so. Five clauses to require:
- Assignment of all IP rights in the deliverables to the client, effective on creation or on payment
- Source code delivery, including repository access during the engagement rather than only at the end
- Third-party and open-source inventory, a written list of components and their licences updated at each release
- Warranty of originality, meaning the vendor warrants the work is theirs to assign
- Moral rights waiver where the applicable law recognises them
Also specify what happens to any pre-existing vendor tooling or framework used in your project. If they are reusing an internal library you need a perpetual licence to it, otherwise you own a system you cannot legally run.
Exit and continuity
This is the clause nobody negotiates until it is too late. Require, in writing:
- Complete source code and repository history
- Deployment and build instructions sufficient for a third party to run the system
- Database schema and migration scripts
- Credentials and infrastructure account transfer
- A defined transition support period after termination
- Return or deletion of personal data with written confirmation
[To fill before publishing: which of these are standard in Codefacture contracts. DPA offered as standard, SCC-based transfers supported, EU hosting available, IP assignment included, source code delivered, exit documentation as a deliverable. Add the date the page was last reviewed.]
Pre-signature checklist
- Data processing agreement in place
- Transfer mechanism identified and documented
- Transfer impact assessment completed where required
- Sub-processor list received and approved
- Hosting location confirmed in writing
- Access control and logging requirements agreed
- IP assignment clause reviewed by counsel
- Source code delivery obligation specified
- Open-source licence inventory required
- Exit and handover obligations defined
Frequently asked questions
Can we outsource development to a company outside the EU under GDPR?
Yes. You need a data processing agreement with the vendor and a lawful transfer mechanism. Where the destination country has no adequacy decision that generally means Standard Contractual Clauses plus a transfer impact assessment. Many buyers reduce the burden by keeping production data hosted inside the EU.
Does Turkey have an EU adequacy decision?
No. Transfers of EU personal data to Turkish processors generally rely on Standard Contractual Clauses with a transfer impact assessment. Turkey has its own data protection law, the KVKK, which is structurally similar to European data protection law. Verify the current adequacy position before signing, as these decisions change.
Who owns software developed by an outsourced team?
Whoever the contract says owns it. Ownership does not transfer automatically in all jurisdictions, so the agreement must include an explicit assignment of IP rights, a source code delivery obligation, and a warranty that the work is original.
What is the difference between anonymised and pseudonymised data?
Pseudonymised data can still be linked back to an individual with additional information and remains personal data under GDPR. Anonymised data cannot be re-identified by any reasonably likely means and falls outside GDPR. Only genuine anonymisation removes the transfer question.
What should be in a data processing agreement?
Subject matter, duration, nature and purpose of processing, categories of personal data and data subjects, the processor's obligations, security measures, sub-processor rules, breach notification timelines, audit rights, and what happens to data on termination.
Next steps
We can walk your legal and procurement teams through our standard terms. Related reading: software development in Turkey.