GDPR and non-EU freelancers: having a non-European provider work on European data

An excellent tech freelancer is available in Dubai, Bali or elsewhere outside the EU, but your IT services firm needs to sign a clean contract, invoiceable in France, GDPR-compatible and defensible on the end client's side.

That's often where the topic gets stuck.

The business need is clear: securing a rare, often senior skill for a specific technical service. The risk, however, is less visible: access to a client environment, handling of personal data, a transfer outside the EU, chained subcontracting, no signable European supplier, incomplete contractual clauses.

For a firm, the "GDPR and non-EU freelancer" topic is therefore not only legal. It's a matter of delivery, contractual compliance and supplier-risk management.

This article explains the points to check before contracting with a tech freelancer based outside the European Union, and how to structure the engagement to reduce friction on the firm's side and the end client's side.

This article is general information. It does not constitute personalised legal, tax or regulatory advice. Each situation must be analysed with your usual advisers, notably according to the countries involved, the data processed, the end-client contract and the real organisation of the mission.

Why a non-EU freelancer raises a specific GDPR topic for a firm

A freelancer based outside the EU can perfectly well work on a tech service for a French firm.

The sensitive point appears as soon as they access personal data.

The GDPR doesn't stop at the European Union's borders. If a person located outside the EU views, processes, extracts, hosts or maintains a system containing personal data, the firm must ask itself a simple question: is there a transfer outside the EU?

In many tech missions, the answer can be yes.

Frequent examples:

• access to a production database containing users;
• work on a CRM, an ERP or a support tool;
• maintenance of a SaaS application;
• analysis of logs containing identifiers, IP addresses or emails;
• access to a code repository containing datasets;
• level-2 or level-3 support on client incidents;
• cloud or security administration with visibility over data.

Even if the freelancer doesn't "copy" the data, mere access from a third country can be enough to characterise a transfer outside the EU under the applicable GDPR analysis.

For a firm, ignoring this point can create a gap with its own commitments to the end client.

The three questions to ask before any mission

Before contracting with a non-EU tech freelancer, the firm must clarify three elements.

1. Does the freelancer access personal data?

The GDPR doesn't only concern client files.

Personal data can be direct or indirect: name, email, user identifier, IP address, support ticket, application logs, HR data, browsing data, payment data, medical data, etc.

A development mission can seem technical, yet become sensitive if the freelancer accesses the production environment.

Conversely, an isolated mission on a test environment with anonymised data can greatly reduce the risk.

The qualification therefore depends on the operational reality, not on the mission's title.

2. Who is the controller, the processor and the sub-processor?

In a typical chain:

• the end client is often the controller;
• the firm can be the end client's processor;
• the non-EU freelancer can become a sub-processor if they process data on behalf of the firm or the end client.

This chain must be contractually consistent.

If the end-client contract prohibits unauthorised sub-processors, the firm can't bring in a non-EU freelancer without prior approval.

If the contract requires EU location of data or of the people involved, the mission must be structured differently.

The risk doesn't come from the GDPR alone. It also comes from breaching the main contract.

3. Does the freelancer's country benefit from a valid transfer mechanism?

The GDPR governs transfers of personal data to countries outside the European Economic Area.

Several situations exist:

• countries benefiting from an adequacy decision;
• transfers framed by standard contractual clauses;
• supplementary technical, organisational or contractual measures;
• specific cases provided for by the GDPR.

For many destinations popular with tech freelancers — Dubai, Bali, Thailand, non-EU islands — a specific analysis is needed.

Standard contractual clauses aren't a simple copy-paste. They must match the parties' roles, the nature of the data, the real access and the security measures in place.

GDPR and non-EU freelancers: the real risk for the firm

The main risk for the firm isn't just "having a freelancer abroad".

The risk is being unable to demonstrate that the engagement is under control.

In a client audit, a DPO review, a security questionnaire or an incident, the firm must be able to answer clearly:

• who is involved;
• from which country;
• for which service;
• with which access;
• on which data;
• under which contract;
• with which subcontracting clauses;
• under which security measures;
• with which end-client authorisation where necessary.

If these answers are scattered across emails, incomplete quotes and foreign invoices, the file becomes hard to defend.

For a decision-maker at a firm, the topic is therefore very concrete: how to keep the freelancer's agility while presenting a clean, documented supplier compatible with French B2B requirements.

The transfer outside the EU: what you need to understand

A transfer outside the EU can exist as soon as personal data is made accessible from a third country.

This can include:

• VPN access;
• a connection to a cloud tool;
• viewing tickets;
• work on a database;
• a temporary extraction;
• remote takeover of a machine;
• access to logs or backups.

The fact that the servers are in Europe isn't always enough to dismiss the topic.

If the freelancer is physically located outside the EU and can view the data, the firm must analyse that flow.

The expected approach is pragmatic: map the access, restrict what must be restricted, document the safeguards, and avoid overly broad or poorly framed engagements.

A "remote" non-EU mission with no access to personal data doesn't have the same risk profile as a production-support mission with full access to user accounts. GDPR compliance is worked out from the real access, not just the freelancer's place of residence.

Standard contractual clauses aren't always enough on their own

Standard contractual clauses, often called SCCs, are a central mechanism for framing certain transfers outside the EU.

But they don't settle everything automatically.

They must be articulated with:

• the service contract;
• the GDPR data processing agreement or DPA;
• the confidentiality commitments;
• the security measures;
• the access restrictions;
• the incident-notification obligations;
• the conditions for using sub-processors;
• the end client's requirements.

Following European case law and the authorities' recommendations, organisations must also assess the effective level of protection in the destination country, notably when the data is sensitive or the access is extensive.

That's often where firms need a more robust contractual file than a mere freelance quote.

What your end client may ask you

A structured end client can ask the firm for:

• the list of sub-processors;
• the location of the people involved;
• the countries from which access is carried out;
• the technical and organisational measures;
• the non-EU transfer clauses;
• the signed DPA;
• proof of confidentiality;
• the incident procedures;
• the access-control policy;
• justification of the need for access to the data;
• whether sensitive data exists;
• the conditions for deletion or return of the data.

These requests can arrive at kick-off, but also mid-mission.

The problem is then operational: if the non-EU freelancer was brought in without contractual structuring, the firm has to regularise in a hurry.

That's precisely what procurement departments, DPOs and CISOs want to avoid.

Structure the mission as a service, not as a secondment

For a firm, the contractual framing must not only handle the GDPR.

It must also correctly qualify the commercial relationship.

The engagement must be structured as a service: scope, objectives, deliverables, responsibilities, schedule, validation terms, confidentiality and security obligations.

The logic must remain that of a supplier delivering an outcome-based service, not an informal secondment of personnel.

This reduces several risks:

• vagueness about responsibilities;
• excessive operational dependence;
• absence of deliverables;
• difficulty documenting the subcontracting;
• confusion between technical supervision and a hierarchical relationship;
• difficulty passing the end-client commitments down back-to-back.

The right reflex is to formalise what's expected, what's delivered, what's accessible, and what's prohibited.

The operational measures that reduce GDPR risk

Compliance doesn't rest on the contract alone.

It also depends on how the mission is carried out.

Here are the most frequent measures to consider, depending on the context:

• restrict access to the strict minimum;
• prefer test or pre-production environments;
• use anonymised or pseudonymised data where possible;
• prohibit unauthorised local exports;
• frame VPN connections;
• enable strong authentication;
• log access;
• provide for revocation of rights at the end of the mission;
• document the authorisations;
• separate the development, administration and production roles;
• provide for an incident procedure;
• formalise the return or deletion of items at the end of the service.

These measures must be consistent with the risk level.

Occasional access to a code repository with no personal data doesn't call for the same level of framing as production administration on client data.

Before talking contract, list the access needed. If production access isn't essential, avoid it. If personal data isn't necessary, remove it. The best non-EU transfer is often the one that doesn't happen.

The specific difficulty of freelancers established outside the EU

Many tech freelancers established outside the European Union are competent, available and genuine tax residents in their country of actual living.

That's not a problem in itself.

But on the French firm's side, several frictions appear:

• a foreign supplier that's hard to reference;
• non-EU invoicing to verify;
• no compliance documentation;
• uncertainty over the VAT treatment;
• a freelance contract not aligned with the end-client contract;
• difficulty imposing a full DPA;
• a risk of undeclared subcontracting;
• no supplier file compatible with procurement;
• a risk of a gap between the mission's reality and the signed documents.

On the tax front, the reality principle remains essential: the situation must correspond to a genuine non-EU residence, genuine remote activity, and the absence of an organised presence in France. A sound configuration has nothing to do with a shell entity created to mask an activity carried out in France, which would be abusive and must be ruled out.

StelarWork does not sell tax avoidance and doesn't create a tax status. The case handled is that of a freelancer already established outside the EU under genuine conditions, for whom the firm needs a compliant, contractually usable French supplier.

How StelarWork fits into the contractual chain

StelarWork acts as a French company contracting in its own name with the firm.

Concretely:

• the firm contracts with a French supplier;
• StelarWork invoices the firm;
• StelarWork contracts with the non-EU freelancer;
• StelarWork pays the freelancer;
• the compliance, subcontracting, confidentiality, invoicing and documentation obligations are structured across the chain;
• the commitments are worked back-to-back with the mission's requirements.

The goal is to turn a hard-to-contract freelancer into a French supplier that's more readable for the firm, without masking the reality of the engagement or bypassing GDPR requirements.

StelarWork doesn't act as the freelancer's employer, doesn't conclude any contract in the freelancer's name and doesn't present itself as their representative in France. The relationship is structured around a B2B service, with suitable contractual obligations.

For the firm, the benefit is operational: a French contractual counterpart, a cleaner file, simpler invoicing, and a documentary chain designed to reduce friction with procurement, legal, the DPO or the end client.

What StelarWork can help clarify on the GDPR side

In a mission involving a non-EU freelancer, StelarWork can help structure the following points:

• qualification of the roles in the contractual chain;
• identification of access to personal data;
• consistency between the firm contract, the end-client contract and the freelance contract;
• confidentiality obligations;
• subcontracting clauses;
• framing of the transfer outside the EU;
• integration of standard contractual clauses where necessary;
• description of the technical and organisational measures;
• incident-notification conditions;
• deletion or return rules;
• the documentation expected on the supplier's side.

This structuring doesn't replace the analysis of the firm's DPO or legal counsel.

It aims to avoid a frequent situation: an excellent freelancer validated by the technical teams, then blocked by procurement, compliance or the end client for lack of a usable framework.

Mistakes to avoid

Some practices needlessly expose the firm.

Letting the freelancer start before the GDPR framing

This is the most frequent case.

The mission starts fast. Access is opened. The contract is finalised afterwards.

In the event of a client question or an incident, the firm then has to rebuild compliance after the fact.

That's more fragile.

Using a generic contract without a DPA

A standard service contract isn't enough if the freelancer processes personal data on behalf of the firm or the end client.

The GDPR subcontracting, the instructions, the confidentiality, the security, the incidents and the end of the mission must be framed.

Forgetting the end client's authorisation

If the firm is itself a processor for the end client, the main contract may require prior authorisation of sub-processors.

Failing to comply with this clause can create a contractual risk independent of the GDPR.

Leaving access too broad

Full administrator access "for convenience" is hard to defend if the mission doesn't require it.

The minimisation principle also applies to authorisations.

Confusing non-EU residence with an artificial arrangement

A freelancer genuinely established outside the EU, working remotely from their country of residence, isn't comparable to an artificial foreign structure used to invoice an activity carried out in France.

The first configuration can be sound if documented. The second must be ruled out.

Firm checklist before signing with a non-EU freelancer

Before launching the mission, check at a minimum:

• The real country of residence and of execution of the service is identified.
• The mission is described as a service, with objectives and deliverables.
• The accessible personal data is mapped.
• The need for production access is justified.
• Any sensitive data is identified.
• The end-client contract authorises the subcontracting concerned.
• The freelancer is declared as a sub-processor where necessary.
• A DPA or suitable GDPR clauses are provided for.
• Standard contractual clauses are considered if there's a transfer outside the EU.
• The security measures are documented.
• Access is limited and revocable.
• Confidentiality is contracted.
• The incident procedure is provided for.
• The commitments are aligned back-to-back with the client contract.
• The invoicing and the supplier chain are acceptable to procurement.

This checklist doesn't replace a full analysis, but it quickly reveals the sticking points.

Why the topic must be handled before the commercial close

For a firm, the bad scenario is well known: the end client approves the profile, the project team wants to start, but legal blocks the contracting.

The risk rises when the freelancer is outside the EU, because several topics stack up:

• GDPR compliance;
• transfer outside the EU;
• sub-processing;
• supplier procurement;
• international invoicing;
• contractual liability;
• access security;
• consistency with the client contract.

Handling these points upstream avoids negotiating under pressure.

It also lets you present the end client with a clear set-up: who delivers the service, under which framework, with which access, and which safeguards.

In large-account environments, this clarity can make the difference between an accepted mission and a blocked one.

What a firm should expect from a compliant set-up

A serious set-up doesn't promise the total absence of risk.

It should rather aim to reduce the grey areas.

For a mission with a non-EU freelancer, the firm should look for:

• an identifiable, contractually responsible supplier;
• a clear service contract;
• a documented subcontracting chain;
• a consistent GDPR framing;
• a suitable non-EU transfer mechanism;
• limited, justified access;
• usable invoicing;
• documentation presentable to internal and external stakeholders.

That's the logic StelarWork stands for: letting a firm work with a non-EU tech freelancer when the profile is relevant, without treating compliance as an end-of-journey detail.

FAQ — GDPR and non-EU freelancers

Can a freelancer based outside the EU work for a French firm?

Yes, it's possible. The key is to structure the mission correctly: contract, invoicing, subcontracting, data access, security and non-EU transfer if personal data is involved.

The freelancer's non-EU residence isn't prohibited in itself. It simply has to be consistent with the reality of the service and compatible with the firm's commitments to its end client.

Is remote access from Dubai or Bali a transfer outside the EU?

It can be, if the freelancer accesses personal data from a country outside the European Economic Area.

Even if the servers are in Europe, remote access to personal data from a third country must be analysed as a possible transfer outside the EU.

Are standard contractual clauses enough?

Not always.

Standard contractual clauses are an important tool, but they must be adapted to the parties' roles, the data processed, the country concerned, the security measures and the main contract.

They must fit into a broader set-up: DPA, confidentiality, security, access limitation and documentation.

Should the end client be informed?

Often, yes.

If the firm acts as the end client's processor, the main contract may require prior authorisation or information on sub-processors.

The end-client contract must be checked before the mission starts.

Can the transfer outside the EU be avoided?

Sometimes.

If the freelancer works only on an environment with no personal data, with anonymised data or without access to systems containing personal data, the transfer can be avoided or reduced.

This analysis depends on the mission's technical reality.

Does StelarWork replace the firm's DPO or legal counsel?

No.

StelarWork structures the contractual and operational chain on the supplier's side, but doesn't replace the firm's legal, tax or DPO advisers.

The goal is to provide a cleaner, more usable framework for working with a non-EU tech freelancer.

Does StelarWork sign in the freelancer's name?

No.

StelarWork contracts in its own name with the firm. The non-EU freelancer contracts separately with StelarWork for the delivery of the service.

This structure avoids confusion between representing the freelancer and a B2B supplier relationship.

Is StelarWork an umbrella-employment solution?

No.

StelarWork doesn't employ the freelancer, doesn't pay a salary and doesn't set up an employment contract. The model rests on a B2B service relationship, with a French supplier contracting with the firm.

Conclusion

The "GDPR and non-EU freelancer" topic must not be treated as an administrative formality.

For a firm, it directly affects the ability to sign, invoice, deliver and defend the mission's compliance before the end client.

The right reflex is to frame early: real access, personal data, subcontracting, non-EU transfer, standard contractual clauses, security, deliverables and the supplier chain.

StelarWork fits this logic: letting the firm contract with a French supplier, while structuring the relationship with the non-EU freelancer and the associated obligations.

You keep access to the talent. You reduce compliance friction. You present a more readable framework to your procurement, your legal team and your end clients.