Hiring developers in Europe means engaging engineers who live in another EU state or country, as direct contractors, through an employer of record (EOR) or through a vendor. The legal requirements come down to five questions: who owns the code (copyright), whether the person is a contractor or an employee (employment-status rules), how personal data is handled (GDPR), what your security reviewers will ask (NIS2) and, if you build AI, who the "provider" is (the AI Act). Two dated deadlines sit on top: 2 December 2026 for the EU Platform Work Directive and 1 January 2027 for the end of the Dutch soft landing on bogus self-employment.
This page is a map. Each section gives the short answer, names the primary source and links to the deeper guide for that question. It's general information, not legal advice, so check your own case with counsel in the country you hire from.
What's on this page
- Who owns the code a European contractor writes?
- Contractor or employee: how classification risk differs by country
- Direct contractor, EOR or staff augmentation: who carries the risk
- The EU Platform Work Directive and developer marketplaces
- The contracts you need before the first commit
- GDPR when contractors touch production data
- Data transfers, adequacy and Serbia
- Security and NIS2 supplier requirements (and DORA for fintech)
- The EU AI Act when an outsourced team builds your AI system
- What this means for your hiring decision
- All EU hiring compliance guides
- FAQ
Who owns the code a European contractor writes?
Not you, unless a document says so. Paying the invoice doesn't transfer copyright, and the EU software rule that hands ownership to a business automatically covers employees only. Directive 2009/24/EC on the legal protection of computer programs says in Article 2(3) that where a program is created by an employee in the execution of their duties, the employer exclusively holds the economic rights unless the contract says otherwise. Our reading is that this default doesn't reach a contractor, which means a written assignment has to do the job.
National law then adds formalities. Poland is the example we've checked against the statute. Poland's Copyright Act requires a contract transferring economic rights to be in writing under pain of nullity (Article 53) and to name the fields of exploitation expressly (Article 41(2)). That's the WIPO Lex English text, so check the current Polish text. Article 74(3) gives the employer the economic rights in programs written by employees. We haven't checked the copyright statutes of Hungary, Slovakia, Slovenia, Romania or Spain, so don't assume Poland's rules apply there.
The practical sequence matters as much as the clause, because an assignment signed after the code exists has to cover work already done, and an engineer who's already shipped has less reason to sign quickly. The assignment and the NDA should be signed before the engineer gets repository access, not after the first pull request. Our guide to what an IP assignment agreement needs for EU contractors covers the clause list and the Polish formalities in depth. The first 14 days of onboarding a contract developer puts the signing order into a plan, including offboarding on day one. The IP clause also belongs in the master agreement, which the section on contracts below covers.
Serbia isn't an EU member state, so Directive 2009/24/EC doesn't bind it. A Serbian engagement needs its own analysis from a local adviser.
Contractor or employee: how classification risk differs by country
The test is the same in spirit everywhere: practice beats the label. A developer who invoices as a freelancer but joins your standups, takes tickets from your engineering manager and works fixed hours on one product for a year looks like a team member, whatever the contract says. What changes by country is who gets billed when a tax authority or court disagrees, and when.
Netherlands
The Wet DBA is the Dutch law against bogus self-employment. KVK's Wet DBA guidance says client and contractor are jointly responsible, and that a client who treats an employee as a freelancer owes payroll taxes and pension contributions. The enforcement moratorium ended on 1 January 2025. The Belastingdienst's enforcement page says back-tax assessments generally don't reach before that date but can go back up to five years where misclassification was knowing or an instruction was ignored. Fines for intent or gross negligence are possible in 2026, and according to the Dutch cabinet's letter to parliament of 19 December 2025 the remaining soft-landing elements of Dutch enforcement end on 1 January 2027. KVK reports a planned Zelfstandigenwet from 1 January 2028. Our walkthrough of Wet DBA risk for companies with Dutch freelance developers sets out the dates and the four ways to engage.
UK buyer, EU engineer
IR35 (the UK off-payroll rules) applies only where a UK tax or NICs liability arises, which a non-UK-resident engineer working wholly outside the UK is unlikely to have. HMRC's employment status manual on international cases is the starting point, and our guide to whether IR35 applies to EU contractors walks through a five-step check for a UK client with an EU-resident engineer.
Poland
Poland has already changed the law. The Polish act amending the labour inspectorate law, an act of 11 March 2026 amending the State Labour Inspectorate Act (Dz.U. 2026 poz. 473), took effect on 8 July 2026 and lets a district labour inspector decide, by administrative decision, that a civil-law contract is employment (new Article 33a), once an earlier inspector's instruction has been ignored. We haven't checked the penalty provisions, so this page gives no figures. If you have Polish B2B developers who work like employees, take it to a Polish employment lawyer now.
Germany
The German pension insurer (Deutsche Rentenversicherung Bund) runs an optional procedure, described on the German pension insurer's status determination procedure page, that decides whether someone is employed or self-employed. We don't have a source on what back-contributions a client can face, so we won't state one. A German adviser can tell you how the status procedure applies to your setup.
The finance angle
Many CFOs ask whether contractors count against headcount in a hiring freeze. That's company policy, not law, and we cover what to agree with finance in whether contractors count against headcount.
Direct contractor, EOR or staff augmentation: who carries the risk
You have three ways to engage a developer abroad, and they split the risk differently.
A direct contractor is the simplest paper trail and leaves most of the classification risk with you. An EOR is designed to become the legal employer, so payroll and employment-law compliance sit with it. Staff augmentation or a nearshore vendor places an engineer from the vendor's team with yours, and the contract with the vendor carries the obligations.
What stays with you in every model is day-to-day direction of the work. The Dutch government's own FAQ on bogus self-employment says an intermediary doesn't remove the hiring party's duty to check, and the hiring party can be liable for unpaid payroll tax. If you manage an EOR's employee like a member of your own team, you keep the operational control that classification tests look at.
How a given country's authorities treat an EOR or a staff-augmentation vendor is a gap we can't close with a vendor-neutral source. We'd rather say that than repeat a vendor's marketing claim. Treat any provider's assurance about liability as something to verify with counsel, and ask for it in writing. In our judgment, the useful questions are concrete ones. Who decides what the engineer works on each day? Who can end the engagement, and on what notice? Who pays if a tax authority reclassifies the person afterwards? A provider that answers all three in the contract has done more for you than one that offers a reassuring brochure, and the answers tell you which of the three models you've really bought.
For the commercial side of the choice, our guide to hiring EU developers from the UK compares contractor, EOR and nearshore partner on tax status, VAT reverse charge, UK GDPR and visas. The broader staff augmentation vs agency vs in-house comparison shows when each fits, and the best countries in Europe to hire software developers covers geography.
The EU Platform Work Directive and developer marketplaces
Directive (EU) 2024/2831 has to be transposed into national law by 2 December 2026 (Article 29). It's aimed at digital labour platforms, but the definition is broad enough that buyers of outsourced engineers should check whether a vendor falls inside it.
Article 2 sets four cumulative criteria for a digital labour platform: the service is provided at a distance by electronic means, at the request of the recipient, organising the work is a necessary and essential part, and the platform uses automated monitoring or decision-making. If a vendor meets all four, it is a digital labour platform. Article 5 then presumes that its contractual relationship with a person performing platform work is employment where facts indicating control and direction are found, and the platform bears the burden of rebutting it. Articles 10 and 11 add human oversight and review of automated decisions, and Article 7 limits data processing. Article 3 extends the protection to workers engaged through intermediaries. The directive also excludes platforms that only provide the means to reach end users.
Whether a B2B staff-augmentation vendor is in scope is our judgment call, not regulator guidance, because there isn't any yet. Our analysis in the guide to the EU Platform Work Directive for buyers is that a vendor which just introduces engineers looks different from one whose software assigns, monitors and rates the work. Ask the vendor which side it sits on.
National laws will decide the details. Poland published a draft implementing law (project UC160) on 4 August 2026. For Slovakia, Slovenia, Romania, Hungary and Spain we haven't verified a transposition step, so check the labour ministry of any country you hire from. Serbia isn't an EU member state, so the directive doesn't apply there.
The contracts you need before the first commit
A complete set for a typical engagement looks like this.
| Document | What it settles | Detail in |
|---|---|---|
| Software development agreement | Scope, IP clause, data protection terms, termination, non-solicit and buyout, governing law | This section |
| IP assignment | Written transfer of economic rights, with fields of exploitation where local law needs them | Section on code ownership |
| Data processing agreement | Roles, instructions, sub-processors, security measures | Section on GDPR |
| Maintenance and SLA terms | What the warranty covers, paid support tiers, exit and handover | This section |
| NDA and onboarding pack | Confidentiality and access, signed before repo access | Section on code ownership |
| AI supplier terms | Who is the provider of record, what each side delivers | Section on the AI Act |
The master document is the software development agreement. Our guide to software development agreement clauses for EU hiring lists seven clauses, among them IP, the Article 28 data processing terms, termination, and non-solicit and buyout, and it covers governing law and the role of standard contractual clauses. The IP clause in it shouldn't replace a standalone assignment where local formalities apply, and a checklist for writing a contractor IP assignment shows what that document has to contain.
Launch isn't the end of the paperwork. A warranty covers defects against the original spec, and ongoing fixes, updates and uptime need a paid arrangement. What to put in a software maintenance contract covers warranty versus maintenance, SLA tiers, exit and handover.
Who signs matters as much as what's signed. In our judgment, legal, the engineering lead and finance belong in the same review before the first commit, because each of them owns a different row of the table. Legal owns the IP and data terms, engineering owns the access and handover mechanics, and finance owns the termination and buyout numbers. When one function reviews alone, the gaps show up later as a renegotiation, usually with the engineer already inside your codebase.
GDPR when contractors touch production data
If an outside engineer can see personal data, GDPR applies whether the engineer sits in Warsaw or Madrid. The first question is the engineer's role. The EDPB's guidelines on controllers and processors treat both as functional concepts, allocated by the actual roles in practice, not by what the contract calls them. If the engineer works inside your repos, cloud accounts and tickets under your instructions, you are usually the sole controller and the engineer is part of your team. If a vendor runs its own environment and handles your personal data in it, the vendor is a processor and Article 28 requires a data processing agreement.
That makes GDPR Article 28 the clause source. Article 28(3) lists the minimum terms for the processing agreement. Article 28(2) requires prior specific or general written authorisation for sub-processors, with notice of changes for general authorisation, and Article 28(4) pushes the same obligations down to them. A processor that decides its own purposes becomes a controller under Article 28(10). The EDPB's Opinion 22/2024 adds that you need the identities of processors and sub-processors readily available at all times, so a vendor who can't list its sub-processors on request is a flag.
Production data in development and test environments is where teams slip. The French CNIL and the Spanish AEPD both warn against copying live data into non-production systems, and Articles 25(2) and 32 point the same way. Give contractors masked or synthetic data by default and treat access to the real thing as an exception you log.
Two short pages answer the questions we hear first. Whether a nearshore developer needs a DPA comes down to this: a DPA is required whenever a processor handles your data, wherever it sits, and within the EU it needs no SCCs or adequacy assessment. Who is controller and who is processor in staff augmentation walks through the role test. For the full treatment of access, sub-processors and test data, read GDPR for outsourced software development.
Data transfers, adequacy and Serbia
Remote access can be a transfer. The EDPB's Guidelines 05/2021 on the interplay between Article 3 and Chapter V say a transfer can occur "even if it takes place only by means of displaying personal data on a screen". The guidelines separate an employee who looks at data while travelling (Example 8, not a transfer) from a processor in a third country accessing it remotely (Example 11, a transfer). So where the engineer sits, and under what relationship, decides it.
Inside the EU, no transfer mechanism is needed. Giving a developer in Poland, Hungary, Slovakia, Slovenia, Romania or Spain access to data isn't a Chapter V transfer, because those six are EU member states.
Serbia is the exception among HighCircl's countries. It isn't an EU member state and, as of 10 October 2026, it isn't on the European Commission's list of adequacy decisions. Check that list again on the day you sign, because it changes. An EU exporter sending data to a Serbian importer usually relies on an Article 46 safeguard. In practice that means SCCs under Article 46(2)(c) and a transfer impact assessment.
SCC drafting for engineering teams and Serbian data protection practice need a data protection adviser for your setup. The closest guide is IDTA vs EU SCCs for international data transfers, which also covers UK and EU adequacy in both directions and the transfer risk assessment. The GDPR outsourcing guide linked above covers the Serbia-specific access and transfer questions.
Security and NIS2 supplier requirements (and DORA for fintech)
When a security reviewer asks about outside developers, they're usually reading NIS2. Directive (EU) 2022/2555 requires essential and important entities to take risk-management measures (Article 21(1)) and makes management bodies approve them and answer for them (Article 20(1)). Your outside developers aren't automatically regulated. Our reading is that a supplier doing delivery-only build work usually falls outside the managed service provider definition in Article 6, and that a maintenance retainer is a closer call. So the contract often does the work: if you're in scope, your supply-chain policy has to reach the supplier.
Implementing Regulation (EU) 2024/2690 gets specific for the entities it covers. Point 5.1 asks for a supply chain security policy, and point 5.1.2(a) puts suppliers' secure development procedures among the selection criteria. Point 6.2.1 applies secure development rules when development is outsourced. Expect questions about code review, secrets handling, environment separation and access removal at the end of an engagement.
Transposition is uneven. The deadline was 17 October 2024, many member states missed it, and the Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice on 8 July 2026. Re-check the status on the day you rely on it. Which version of the national law applies to you depends on where your company is established, so check it per country. Treat NIS2 and your own information security policy as the baseline for what you ask.
Fintech adds DORA, Regulation (EU) 2022/2554, which has applied since 17 January 2025. Its obligations sit on the financial entity, not the developer, and Article 30 sets contract terms in two tiers. NIS2 (recital 28 and Article 4) leaves DORA to govern risk-management and incident-reporting duties for financial entities in its scope. The details of Articles 2, 3, 28 and 30, the register of information and PSD2 are in our guide to hiring fintech developers under DORA and GDPR. For the supplier side of NIS2, see NIS2 requirements for outsourced developers.
The EU AI Act when an outsourced team builds your AI system
If an outside team builds the system, the party that puts it on the market under its own name is usually the provider, and the provider carries most of the obligations. Article 3(3) of the AI Act in the official text defines a provider to include a party that has an AI system developed and places it on the market or puts it into service under its own name. Commissioning the build doesn't make that obligation go away. Article 25 deals with the provider and supplier relationship, including who must supply what to whom.
The practical point is that the statement of work has to name the provider of record and allocate duties explicitly, because the default allocation depends on facts like whose name is on the product. Our AI Act guide below sets out ten contract steps, and not every system needs all of them. Our judgment is that this belongs in the SOW, not in a side email.
Dates have moved. Per the Commission's AI page, the AI Act has been applicable from 2 August 2026, with exceptions, and the digital omnibus entered into force on 27 July 2026. Annex III high-risk rules now apply from 2 December 2027, and Annex I product rules from 2 August 2028. Re-check these on the day you rely on them. For high-risk systems, serious incident reporting under Article 73 also needs an owner on the contract.
Our guide to AI Act compliance when an outsourced team builds your AI system covers the provider test and the contract allocations in depth. If your product shows AI-generated content to users, the transparency duties for engineering teams are in a separate guide listed in the index below.
What this means for your hiring decision
The decision is who signs off on how a European developer is engaged, and what paperwork must exist before access. Here's what we'd do, in order.
Before any developer gets repo access, have the IP assignment signed and the DPA roles decided. If an embedded contractor in the Netherlands works like a team member, consider comparing an employment route with a Dutch adviser, and don't treat 2027 as the start of risk. For Poland, get local advice first. These steps are our judgment, informed by the rules above.
Two more steps. Ask any vendor in writing how it tests worker status, who holds the sub-processor list, and whether the Platform Work Directive's Article 2 test applies to it. If you build AI, name the provider of record in the SOW.
HighCircl hires in six EU member states (Poland, Hungary, Slovakia, Slovenia, Romania and Spain) and in Serbia, which is outside the EU, and you can see how hiring through HighCircl works. If you only do one thing this week, start with the DPA question: do you need a DPA for a nearshore developer, and what must it say.
All EU hiring compliance guides
Guides not linked in the sections above, grouped by the same topics.
Index of every guide in this theme
Code ownership and contracts
AI Act
FAQ
Who owns code written by a contractor in the EU?
Under Polish law, the contractor, as author, holds the economic rights until a written transfer. The EU software directive's employer default covers employees only, in our reading. We haven't checked the other countries' statutes, so confirm locally.
Does GDPR apply to developers hired in another EU country?
Yes, if they can access personal data you control. A developer embedded in your own systems under your instructions is usually part of your team. Where a separate vendor processes your data on its own systems, Article 28 requires a data processing agreement. The role follows what each side does in practice, not what the contract calls it. Within the EU you need no standard contractual clauses.
Can a UK company hire developers in the EU without an entity?
Often, yes, through a contractor, an EOR or a nearshore partner, but each route has its own tax status, VAT and visa questions. IR35 applies only where a UK tax or NICs liability arises, and UK GDPR transfers to the EU are covered by UK adequacy regulations. Our UK setup guide compares the three routes. A local adviser should confirm the position in the developer's country.
Does the EU Platform Work Directive apply to developer marketplaces and staff augmentation?
It applies to digital labour platforms that meet four cumulative criteria in Article 2, and national laws are due by 2 December 2026. Whether a B2B staff-augmentation vendor meets them is our reading, not regulator guidance. A marketplace whose software organises, monitors and rates the work is closer to the definition than one that only introduces engineers.
Do I need standard contractual clauses for a developer in Serbia?
Probably, if the developer accesses personal data from Serbia. Serbia isn't an EU member state and, as of 10 October 2026, isn't on the Commission's adequacy list, so an EU exporter usually relies on an Article 46 safeguard. In practice that means SCCs under Article 46(2)(c) and a transfer impact assessment. Confirm with a data protection adviser.
Does NIS2 make my outsourced developers a regulated entity?
Usually not. Our reading is that delivery-only build work is typically outside the managed service provider definition, and a maintenance retainer is a closer call. NIS2 can still reach you through your own supply-chain duties, which makes the supplier contract the place where security requirements get written down.