GDPR outsourcing software development comes down to three questions: who is the controller, what may an outside engineer see, and where the regulation's text actually bites. The short answers are these. Access should follow the task. Non-production environments should run on data that isn't personal. And a transfer happens when a separate controller or processor outside the EEA receives the data or can access it, remote access included; outside an adequacy decision, it then needs a safeguard.
The wider contract and compliance picture is in EU engineering hiring compliance: contracts, IP and GDPR. This page covers only the engineer-level questions, and it's information, not legal advice.
Is the outside engineer a processor, a sub-processor, or part of your team?
It depends on whose systems and whose instructions the engineer works under. The EDPB's Guidelines 07/2020 on controllers and processors treat both roles as "functional concepts" that allocate responsibilities "according to the actual roles of the parties". A contract label doesn't settle it.
Two setups sit at opposite ends. An engineer who works inside your repos, your cloud account and your ticketing, taking instructions from your team, is usually not a separate processor. That matches HighCircl's own answer on when a DPA is required for nearshore developers, which also holds the Art 28(3) minimum terms, so they aren't repeated here. An agency that runs its own environments, decides how the work is done and handles your users' data inside them is a processor. If it starts deciding purposes and means itself, Art 28(10) of the GDPR text on EUR-Lex treats it as a controller for that processing.
Many engagements sit somewhere between the two. A freelancer on their own laptop using your staging database isn't obviously either. Work out the facts first, then name the role in the contract.
Sub-processors come in once the agency brings in its own freelancers or a partner firm. Under Art 28(2) a processor can't engage another processor without your prior specific or general written authorisation, and under general authorisation it has to tell you about intended changes. Art 28(4) makes the sub-processor take on the same obligations and leaves the first processor fully liable. The EDPB's Opinion 22/2024 on processors and sub-processors adds a practical test for the controller: have the identity of all processors and sub-processors (name, address, contact person) readily available at all times, regardless of the risk. How deep your verification of their guarantees goes can vary with risk. Whether you hold the list can't.
What goes in the contract
Where an outside company is a processor, five of the Art 28(3) points matter most to engineering. Persons authorised to process are bound to confidentiality (b). The processor takes the Art 32 security measures (c). Sub-processors come in only on the conditions in (d). Data is deleted or returned at the end (g). You get information and audits (h). For wording, see the clauses a development agreement needs.
Which access does an outside engineer actually need?
Art 32 doesn't use the phrase "least privilege", and it doesn't talk about environments. It lists measures including pseudonymisation and encryption in 32(1)(a), ongoing confidentiality, integrity, availability and resilience in (b), and regular testing in (d). Paragraph 4 says anyone acting under your authority who has access to personal data processes it only on your instructions.
The access-limiting duty comes from Article 25(2). By default only the personal data necessary for each purpose is processed, which covers the amount, the extent, the storage period and accessibility. In particular, data shouldn't be accessible to an indefinite number of people without intervention. "Least privilege" is the engineering name for meeting that, and it's a good one, but it's practice you choose, not text you can quote.
The table below maps the usual access tiers to the provisions that apply. The controls column is practice, not legal requirement.
| Access tier | Personal data it can expose | Provision | Control (practice) |
|---|---|---|---|
| Repo only | Usually none, unless someone committed a dump or a log file | Art 25(2), Art 32(1) | Secret scanning, review before merge, no data files in the repo |
| CI and secrets | Indirectly everything, through the credentials the pipeline holds | Art 32(1), Art 32(4) | Engineer triggers a pipeline but can't read production secrets |
| Staging | Real data if it was copied from production | Art 25(2), Art 5(1)(c) | Masked or synthetic seeds only |
| Production read | Whatever the engineer queries or sees in logs | Art 25(2), Art 32(4) | Separate named accounts, time-boxed grants, access logged |
| Production write or admin | All of it, with the ability to change or delete it | Art 32(1), Art 28(3)(c) | Approval per session, a named reviewer, offboarding checked |
The two middle rows are the ones teams tend to overlook. Nobody thinks of CI as a data store until a pipeline variable turns out to hold a production database URL.
The supplier-risk side of this, including how repo, CI and production access fit a security schedule, is in NIS2 supplier requirements for outsourced developers. That page is NIS2-framed and says plainly that its access practices aren't a legal requirement. The GDPR hooks above are the ones that apply to personal data.
Can outsourced developers use production data in dev and test?
Regulators in two member states say to avoid it, and neither treats a test environment as exempt.
The French regulator's guidance on securing software development, dated 14 March 2024, says development and tests should use fictional datasets as far as possible. Real data may go into a pre-production environment only when tests on fictional data prove insufficient, and then that environment has to be configured and secured like production. The Spanish regulator's post on breaches in development and pre-production environments, from 18 April 2022, says Art 32 applies equally to development, pre-production and production. It cites the EDPS advice to avoid sampling real data, to prefer synthetic data, and where real data is unavoidable to keep a documented analysis and limit access to those who need it. It also notes that development often involves additional processors, which can raise the risk.
The GDPR text gives those positions their footing. Art 5(1)(c) requires data minimisation, Art 25 puts data protection into design and default, and pseudonymisation is named in Art 32(1)(a).
In practice that means masked or synthetic seed data as the default for every environment an outside engineer can reach, and a written exception path for the day someone has to reproduce a bug that only shows up on real records. The exception should say who approved it, which data, for how long, and where it's deleted. A contractor who "just takes a copy of production to debug" is the failure both regulators describe.
When does giving an engineer access count as a transfer?
Chapter V starts with Art 44, which allows transfers only if its conditions are met, onward transfers included. The question is when an engineer's access is a transfer at all.
The EDPB's Guidelines 05/2021 on the interplay between Article 3 and Chapter V set three cumulative criteria for a transfer. They also say remote access from a third country is a transfer, "even if it takes place only by means of displaying personal data on a screen". Opinion 22/2024, at paragraph 75, repeats that remote access from a third country is a transfer when those criteria are met. So data doesn't have to be copied or shipped anywhere. A separate controller or processor outside the EEA seeing it is enough.
Two of the Guidelines' examples show where the line falls. In Example 8, an employee of an EU controller who accesses data from a third country on a business trip isn't a transfer, because the employee is "an integral part of the controller". In Example 11, a processor in a third country that remotely accesses EU data is a transfer.
Whether the engineer is part of your organisation or part of someone else's decides which example you're in. An engineer on a separate vendor's payroll, working from the vendor's country, looks like Example 11 if that country is outside the EEA. How a freelancer engaged directly fits is a question for counsel. And it's the same functional question as the role test earlier, which is why contract structure matters before the first login.
What about Serbia?
Serbia isn't an EU member state, and as of 2 October 2026 it isn't on the Commission's list of adequacy decisions. That list covers Andorra, Argentina, Brazil, Canada (commercial organisations), the Faroe Islands, Guernsey, Israel, the Isle of Man, Japan, Jersey, New Zealand, the Republic of Korea, Switzerland, the UK, the US (under the Data Privacy Framework, for certified companies), Uruguay and the European Patent Organisation.
For an EU company where an engineer in Serbia is a separate importer, such as a Serbian agency's staff using that agency's systems, Chapter V needs an Art 46 safeguard. Standard contractual clauses under Art 46(2)(c) are the usual one, along with a transfer impact assessment (Opinion 22/2024, para 90). Which mechanism applies, and how the UK side differs, is in which transfer mechanism applies. HighCircl's answer page treats a Serbia placement as a Chapter V transfer that needs SCCs and a transfer assessment. Only your own employee on a trip falls under Example 8; for anyone else, check the structure with counsel.
Anyone who tells you that keeping a build in Eastern Europe removes the transfer problem is generalising. Six of the seven European countries HighCircl hires in (Poland, Hungary, Slovakia, Slovenia, Romania and Spain) are EU member states. Serbia isn't.
Checklist before an outside engineer gets access
- Decide the role: processor, sub-processor, or part of your own team, using the functional test.
- Hold the list of every processor and sub-processor, with name, address and contact person.
- Sign the Art 28 contract where a separate processor is involved.
- Map each engineer to one access tier, and write down what that tier can expose.
- Put non-production environments on masked or synthetic data, with a documented exception path.
- Record the transfer basis for any engineer or vendor outside the EEA.
- Plan offboarding: accounts closed, secrets rotated, data deleted or returned.
FAQ
Does an outsourced developer in Poland need SCCs?
No. Poland is an EU member state, so sending data there isn't a Chapter V transfer. A separate agency still needs Art 28 terms if it acts as your processor. Sub-processors outside the EEA bring the transfer question back in.
Can a contractor use a copy of production data to debug?
Only as a documented exception. The French and Spanish regulators both point to fictional or synthetic data first. If real data is unavoidable, the Spanish regulator asks for a documented analysis and need-to-know access, and Art 32 applies to the debugging environment as it does to production.
Do I need to list every sub-processor?
You need to have them readily available. Opinion 22/2024 says a controller should have the identity of all processors and sub-processors at hand at all times, regardless of the risk. The depth of your checks on their guarantees can scale with risk, but holding the list doesn't.
Is Serbia covered by an adequacy decision?
No. As of 2 October 2026 it isn't on the Commission's adequacy list. A transfer from the EU to a Serbian importer needs an Art 46 safeguard such as SCCs.
Does remote access from outside the EEA count as a transfer?
Yes, if the transfer criteria are met. The EDPB says remote access from a third country is a transfer, even if it only displays personal data on a screen. An EU controller's own employee accessing data from abroad isn't a transfer, but a separate third-country processor doing the same is.