Contracting with a non-EU freelancer: the complete legal architecture

You have identified the right non-EU tech freelancer, but your IT services firm cannot afford to sign a subcontracting arrangement with an incomplete contract chain, an unclear assignment of rights or a poorly framed data transfer.

A non-EU freelance subcontracting agreement is not limited to a quote, an NDA and a purchase order. It must reproduce the end client’s constraints, qualify the service correctly, organise the deliverables, secure intellectual property, frame GDPR matters and allocate liabilities.

The issue is simple: avoiding a situation where an apparently operational engagement leaves a legal grey area at the point when the end client requests an audit, challenges a deliverable, claims ownership of the code or questions access to data.

The main risk: a contract chain that does not align

In a typical IT services firm engagement, the document chain often includes three levels:

1. the agreement between the end client and the IT services firm;
2. the agreement between the IT services firm and its subcontractor;
3. the operational documents describing the service: purchase order, statement of work, specifications, security schedules, project rules.

The problem arises when these levels are not aligned.

The end client imposes strict confidentiality, but the NDA signed with the freelancer is minimal. The client agreement requires a full assignment of intellectual property, but the agreement with the freelancer only covers a right of use. The client prohibits non-EU subcontracting without written consent, but the purchase order does not mention it. The client DPA requires GDPR safeguards, but no document covers access to data from a non-EU country.

The risk is not only having a bad contract. The risk is having several documents that are acceptable in isolation, but inconsistent with each other.

This is precisely the role of back-to-back drafting: passing down the obligations of the client agreement into the subcontracting agreement, without creating obligations that are impossible to perform. To explore this logic further, you can refer to back-to-back contracts explained for aligning the end client and subcontracting.

The foundation: qualifying the relationship as a service provision

A non-EU freelance subcontracting agreement must first qualify the relationship correctly.

The IT services firm must not document a relationship that looks like the mere supply of man-days. It must frame a service, with a scope, deliverables, acceptance procedures and responsibility for performance.

This distinction is structural.

It helps show that the supplier is acting to produce a defined result, within a controlled contractual framework, without confusion with an employment relationship. It also reduces ambiguity in the event of an internal client review, a dispute or a legal review.

Points to formalise

The agreement or purchase order should specify:

• the purpose of the service;
• the expected deliverables;
• the relevant technologies;
• milestones and acceptance criteria;
• prerequisites provided by the IT services firm or the end client;
• procedures for correcting defects;
• scope limits;
• scope-change rules;
• the associated confidentiality, security and compliance obligations.

The engagement must be described as a framed technical contribution, not as an informal assignment to a client team.

The more sensitive the engagement, the more precise the purchase order must be. A robust framework agreement does not compensate for a vague operational scope.

The recommended document architecture

A clean contract architecture rarely relies on a single document. It combines several building blocks, each with a specific function.

The NDA

The NDA comes before or alongside the framework agreement.

It covers pre-contractual exchanges, technical information, access rights, project documentation, trade secrets, architecture elements, client data and commercial information.

It must be consistent with the NDA or confidentiality clause signed between the end client and the IT services firm.

Points to check:

• broad definition of confidential information;
• appropriate confidentiality period;
• prohibition on disclosure to unauthorised third parties;
• obligation to protect access rights;
• return or deletion of information at the end of the engagement;
• usual exceptions: information already public, lawfully received from a third party, legal requirement.

The framework agreement

The framework agreement organises the relationship over time.

It must cover the general terms applicable to all services: liability, confidentiality, intellectual property, subcontracting, security, compliance, governing law, disputes, termination, document audit and insurance.

It avoids renegotiating the same clauses for every engagement.

To structure this relationship with consistent purchase orders, the approach detailed in the right framework agreement and purchase order architecture for clean subcontracting provides the right document base.

The purchase order or statement of work

The purchase order describes the specific engagement.

It must not stop at a job title or a day rate. It must link the price to an identified service, deliverables or a technical scope.

It may provide for:

• the project context;
• the functional or technical scope;
• the deliverables;
• dates or milestones;
• acceptance procedures;
• project contacts;
• applicable end-client constraints;
• security or GDPR schedules;
• procedures for changing the scope.

The purchase order is also the right place to integrate the end client’s specific constraints: closed environment, code repository rules, prohibition on unapproved tools, documentation requirements, data-access restrictions.

Specialised schedules

Some clauses should not be buried in a general agreement.

For sensitive engagements, add dedicated schedules:

• security schedule;
• GDPR schedule or data processing agreement;
• intellectual property schedule;
• insurance and liability schedule;
• reversibility or return schedule;
• supplier compliance schedule.

These schedules make each obligation verifiable.

Alignment with the end-client agreement

The end-client agreement is the starting document. The subcontracting agreement must be built from it.

The IT services firm must identify the obligations that must flow down to the subcontractor.

Clauses to flow down

The most common clauses concern:

• confidentiality;
• IT security;
• personal data protection;
• intellectual property;
• subcontracting restrictions;
• audit rules;
• intervention or correction deadlines;
• compliance with client policies;
• continuity or reversibility;
• liability in the event of fault, leakage, infringement or breach of contract.

The aim is not to mechanically copy the client agreement. Some obligations cannot be transposed as they stand to a non-EU freelancer. They must be adapted, while preserving their useful effect.

Clauses to monitor in the client agreement

Before signing with a non-EU freelancer, the IT services firm must reread certain clauses of the client agreement:

• does the client authorise subcontracting?
• does it require prior written authorisation?
• does it prohibit certain countries or geographical areas?
• does it require the services to be performed from within the European Union?
• does it impose data localisation?
• does it require a named list of contributors?
• does it provide for an audit right?
• does it require a full assignment of rights?
• does it limit access to certain environments?

These points must be addressed before the start date, not during a compliance audit.

Undeclared non-EU subcontracting can become a major contractual issue, even if the technical engagement is running properly.

Intellectual property: locking down ownership of the deliverables

Intellectual property is one of the most underestimated risks in a non-EU freelance engagement.

In software development, the IT services firm must be able to demonstrate that it has the rights needed to deliver to the end client. The end client, in turn, often expects full ownership or very broad exploitation rights over the code, documentation and created elements.

A vague clause such as “the deliverables belong to the client” may be insufficient.

What the clause must cover

The intellectual property clause must specify:

• the deliverables concerned;
• the rights assigned;
• the territory;
• the duration;
• the methods of exploitation;
• the right to modify, maintain, adapt and integrate the deliverables;
• treatment of pre-existing components;
• any use of open-source libraries;
• non-infringement warranties;
• obligations in the event of a third-party claim.

Three categories must also be distinguished:

1. elements created specifically for the engagement;
2. the provider’s pre-existing tools, frameworks, scripts or building blocks;
3. open-source or third-party components.

This distinction avoids promising the end client an assignment that the IT services firm cannot obtain.

For a deeper look at this point, particularly where code is produced from a non-EU country, see securing the assignment of intellectual property in code delivered by a non-EU freelancer.

GDPR: addressing data access from a non-EU country

As soon as a non-EU freelancer accesses European personal data, the GDPR issue must be addressed explicitly.

It is not enough to add a confidentiality clause. Remote access from a third country may constitute a data transfer within the meaning of the GDPR. The roles must therefore be identified, the flows documented and the appropriate contractual safeguards provided for.

Questions to document

The IT services firm must clarify:

• which data is accessible;
• whether personal data is involved;
• who is the controller;
• who acts as processor;
• whether the freelancer acts as a sub-processor;
• from which country access takes place;
• which environments are used;
• which security measures are required;
• which obligations apply in the event of an incident;
• which mechanisms govern any transfer outside the EU.

The GDPR schedule must be consistent with the DPA entered into between the end client and the IT services firm.

Operational measures to include contractually

The contract may impose:

• named and limited access;
• strong authentication;
• prohibition on copying data locally;
• exclusive use of approved environments;
• access logging;
• prohibition on using unvalidated tools;
• prompt notification of any incident;
• deletion or return of data at the end of the engagement;
• cooperation in the event of an audit or client request.

These measures must be proportionate to the project. An engagement with no access to personal data does not require the same safeguards as an engagement on a production system containing user data.

For dedicated treatment of this topic, refer to having a non-European provider work on European data under the GDPR.

Liability and professional liability insurance: avoiding coverage gaps

Contractual liability must follow the reality of the chain.

The end client will seek recourse against the IT services firm. The IT services firm must therefore be able to seek recourse against its subcontractor where the damage comes from the outsourced service. But this logic only works if the clauses are consistent, enforceable and insurable.

Points to frame

The contract must specify:

• best endeavours or outcome-based obligations depending on the deliverables;
• cases where the supplier is liable;
• exclusions;
• any caps;
• liability in the event of a confidentiality breach;
• liability in the event of intellectual property infringement;
• liability in the event of a security incident;
• insurance obligations;
• supporting documents to be provided;
• claim-management procedures.

The non-EU freelancer’s professional liability insurance must be analysed carefully. Some policies do not cover French clients, services performed for Europe, cyber risks, intellectual property disputes or the amounts expected by an IT services firm.

An insurance clause only has value if it matches the real risk of the engagement and if the supporting documents can be verified.

The allocation of risks between the end client, the IT services firm, any intermediary and the provider is detailed in who covers what in a non-EU subcontracting chain from a professional liability insurance and liability perspective.

Essential clauses in a non-EU freelance subcontracting agreement

A non-EU freelance subcontracting agreement must be readable, but complete. The following clauses form the protection baseline.

Identification of the parties and capacity to contract

The agreement must clearly identify the parties, their legal form, address, authorised representative and capacity to provide the service.

For a non-EU provider, identification documents must be consistent with the country of establishment, rather than being limited to a contact address or professional profile.

Purpose of the service

The purpose must be precise.

It must avoid overly generic titles such as “backend developer” or “team reinforcement”. Prefer a service description: module development, defect correction, API integration, code audit, test automation, technical documentation.

Deliverables and acceptance

The acceptance clause must provide for:

• expected deliverables;
• acceptance criteria;
• review periods;
• possible reservations;
• expected corrections;
• the point at which the deliverable is deemed accepted.

Without acceptance procedures, it becomes difficult to prove whether the service is complete, compliant or open to challenge.

Confidentiality

Confidentiality must cover information belonging to the end client, the IT services firm and the project.

It must survive the end of the contract. It must also provide for the return or deletion of confidential materials.

IT security

The security clause must be adapted to the project.

It may provide for the use of a VPN, a prohibition on shared devices, encryption, strong authentication, tool restrictions, secrets management, commit rules and a prohibition on transferring code to unauthorised repositories.

Intellectual property

The clause must organise the assignment or licensing of rights in the deliverables, depending on the requirements of the client agreement.

It must also address pre-existing components, open-source building blocks and the provider’s warranties.

Personal data

If personal data is involved, a GDPR schedule must specify the roles, processing operations, security measures, sub-processors and conditions for transfer outside the EU.

Further subcontracting

The freelancer must not be able to delegate all or part of the service without prior written consent, especially if the end client strictly governs the subcontracting chain.

This clause prevents an unidentified contributor from appearing in the chain.

Audit and cooperation

The audit must remain proportionate, but possible.

The IT services firm must be able to obtain the necessary supporting documents in the event of a client request: insurance certificate, proof of data deletion, confirmation of non-disclosure, security documentation, traceability elements.

Termination

The termination clause must cover:

• breach of contract;
• confidentiality breach;
• security incident;
• impossibility of continuing the engagement;
• loss of client authorisation;
• non-compliance with GDPR constraints;
• failure to deliver or refusal to correct.

It must also provide for the effects of termination: return, deletion, document transfer, delivery of work in progress and survival of certain obligations.

Governing law and dispute resolution

The choice of governing law and dispute-resolution mechanism must be consistent with the client chain.

An agreement governed by a distant law, not aligned with the client agreement, may make performance of the obligations more complicated. Conversely, imposing French law on a non-EU provider is not enough if the clauses are not workable in practice.

The issue is to choose an architecture that is realistic, defensible and consistent with the level of risk.

The role of a French supplier inserted into the chain

Some IT services firms cannot sign a non-EU freelancer directly.

The reasons are often internal: procurement policy, compliance requirements, inability to onboard a non-European supplier, refusal to contract in a foreign jurisdiction, difficulty obtaining the expected documents, or a legal risk considered too high.

In this case, an actor such as StelarWork is contractually inserted between the French IT services firm and the non-EU tech provider.

StelarWork contracts in its own name with the IT services firm, then organises the contractual relationship with the provider. The aim is to turn subcontracting that is difficult to sign directly into a structured French supplier relationship, with documentation that is more readable for the IT services firm.

This does not remove the need to frame the service. On the contrary, the document architecture remains central:

• supplier agreement with the IT services firm;
• purchase order per engagement;
• adapted back-to-back clauses;
• confidentiality undertakings;
• intellectual property treatment;
• security and GDPR schedules where necessary;
• liability and insurance consistent with the engagement.

StelarWork should not be understood as a substitute for contractual framing. Its value lies in clean contractual interposition, reducing administrative friction and structuring a chain that is more usable for a French IT services firm.

Common mistakes to avoid

Signing a simple quote

A quote is not enough for a sensitive tech engagement.

It does not properly address intellectual property, confidentiality, GDPR, liability, security or the obligations of the end client.

Copying and pasting the client agreement without adaptation

Back-to-back does not mean mechanical reproduction.

Some obligations must be adapted to the supplier’s role, the country of performance, the actual access rights and the scope of the service.

Forgetting subcontracting authorisation

Many client agreements require prior authorisation.

If the IT services firm engages a non-EU freelancer without checking this clause, it creates a contractual risk that is independent of the quality of the service.

Addressing GDPR too late

GDPR must be addressed before access to environments is opened.

Once access is opened, the processing relationship already exists. The documentation must therefore precede the effective start of the engagement.

Neglecting open-source components

Delivered code may incorporate dependencies, libraries or snippets subject to licences.

The intellectual property clause must require the provider to declare these components and comply with the applicable licences.

Accepting unverified insurance

A generic certificate may be insufficient.

The territorial scope, covered risks, exclusions and consistency with the engagement must be checked.

A review grid before signing

Before signing a non-EU freelance subcontracting agreement, the IT services firm can ask itself the following questions:

• Does the client agreement authorise this subcontracting?
• Are the client obligations reflected in the supplier agreement?
• Does the purchase order describe a service with deliverables?
• Are the acceptance criteria written down?
• Does confidentiality cover the end client’s information?
• Is the intellectual property assignment complete and consistent?
• Are pre-existing and open-source components addressed?
• Does the freelancer access personal data?
• Is the country of data access identified?
• Are the security measures written down?
• Is liability aligned with the project risk?
• Has relevant professional liability insurance been verified?
• Is further subcontracting prohibited or framed?
• Does the end of the engagement provide for return, deletion and reversibility?
• Are the documents consistent with each other?

This grid does not replace a legal review, but it helps quickly identify grey areas.

FAQ

Is an NDA enough to start with a non-EU freelancer?

No. An NDA protects confidential information, but it does not cover the whole relationship.

It is not enough to frame deliverables, intellectual property, liability, GDPR, security, acceptance or the obligations arising from the end-client agreement. It may be signed before exchanges begin, but it must be supplemented by a framework agreement, a purchase order and the necessary schedules.

Must the subcontracting agreement reproduce the client agreement exactly?

Not exactly.

It must reproduce the obligations that genuinely concern the subcontractor, in a back-to-back logic. Some clauses of the client agreement must be adapted so that they can be performed by the provider. The aim is to avoid gaps in protection, without creating unrealistic clauses or clauses that are impossible to apply.

What should be done if the non-EU freelancer accesses European personal data?

This access must be documented before the start of the engagement.

The IT services firm must identify the GDPR roles, the data concerned, the access country, the security measures and the safeguards applicable to the transfer outside the EU. A confidentiality clause is not enough. A GDPR schedule or data processing agreement may be necessary depending on the configuration.

Does the non-EU freelancer’s professional liability insurance automatically protect the IT services firm?

No.

The scope of the policy must be checked: covered territory, nature of the services, exclusions, cyber risk, intellectual property, amounts, foreign clients, claims handling. Local insurance may be relevant in the freelancer’s country, but insufficient to cover an engagement performed for a French IT services firm and a European end client.

Disclaimer

This article is provided for general information purposes to help IT services firms structure their contractual thinking around non-EU freelance subcontracting. It does not constitute personalised legal, tax, employment or insurance advice. Any contractual decision must be validated with your usual advisers, taking into account your client agreement, the country concerned, the nature of the engagement, the data processed and your internal compliance policy.