Back-to-back NDAs: securing confidentiality between end client, IT services firm and non-EU freelancer

You've identified a competent tech freelancer based outside the EU, but your end client imposes a strict NDA and refuses any supplier that's hard to contract. The topic isn't just administrative. It touches on confidentiality, subcontracting, contractual proof and your ability to honour your commitments to the end client.

The back-to-back NDA answers this difficulty: it brings the confidentiality obligations of the end-client contract down to every party in the chain, without creating a grey area.

For a firm, it's a critical point as soon as an external expert accesses sensitive information: source code, architecture, cloud accounts, business data, product documentation, roadmaps, Jira tickets, pre-production environments or commercial information.

What is a back-to-back NDA?

A back-to-back NDA is a contractual mechanism that takes, adapts and passes down the confidentiality obligations set out in the main contract.

In a typical chain:

• the end client imposes confidentiality obligations on the firm;
• the firm must ensure its subcontractors comply with equivalent obligations;
• the subcontractor must itself frame access to confidential information by the people or providers it mobilises.

The principle is simple: no one should access the end client's information without being bound by a confidentiality commitment compatible with the one required upstream.

Back-to-back doesn't always mean copy-pasting the end client's NDA. It means aligning the essential obligations: scope, duration, authorised uses, security, return, destruction, incident notification, liability and proof.

Key takeaway: a back-to-back NDA isn't an isolated document. It's a consistent contractual chain linking the end client, the firm, the supplier and the person actually doing the work.

Why the back-to-back NDA is sensitive for a firm

The firm is often the end client's direct contractual counterpart. It therefore carries a particular risk if an external freelancer receives confidential information without a sufficient framework.

The risk can be contractual, operational or commercial.

Contractual, because the client contract often provides that the firm remains responsible for the people to whom it gives access to confidential information.

Operational, because a non-EU freelancer can work from another time zone, another country, with their own tools, their own devices and sometimes their own subcontractors.

Commercial, because a confidentiality incident can weaken the relationship with the end client, even without an immediately quantifiable loss.

The topic is therefore not to "get an NDA signed" to tick a box. The topic is to be able to demonstrate that the commitments made to the end client were correctly passed down and controlled.

The situations where back-to-back becomes indispensable

The back-to-back NDA becomes particularly important when the firm brings in an external expert on a service exposed to sensitive assets.

That's the case, for example, for:

• a cybersecurity audit;
• a DevOps mission with access to cloud environments;
• work on proprietary code;
• a data service involving business datasets;
• an architecture mission on critical systems;
• level-3 support with access to tickets containing client information;
• an AI service with exposure to internal documents;
• a project takeover involving documentation, credentials or decision histories.

In these cases, the end client rarely expects a mere promise. It expects an enforceable, documented and consistent chain of confidentiality.

What a back-to-back NDA must cover

An effective back-to-back NDA must cover the same structuring points as the upstream NDA, while remaining workable in operational reality.

The definition of confidential information

The definition must be broad enough to cover information passed orally, in writing, via collaboration tools, repositories, tickets, technical environments or temporary access.

It must also avoid ambiguity.

A good alignment notably covers:

• the source code;
• technical data;
• architectures;
• credentials and secrets;
• internal documents;
• commercial information;
• information about the end client's own clients;
• intermediate deliverables;
• project exchanges;
• identified vulnerabilities.

If the end-client NDA imposes a very broad definition, the downstream clause must not narrow the scope without approval.

The authorised uses

Confidential information must be used only to perform the planned service.

That's an important point in subcontracting. The freelancer or downstream supplier must not be able to reuse the information in another context: another client, training, a demo, a portfolio, a publication, a benchmark, marketing content or a public contribution.

The clause must also frame the use of third-party tools. For example, using AI, translation, file-sharing or note-taking tools can create difficulty if confidential data is fed into them without authorisation.

The authorised people

The back-to-back NDA must specify who can access the information.

In a sound configuration, access is limited to the people who need the information to deliver the service. That's the need-to-know principle.

If the chain includes a non-EU tech freelancer, the firm must be able to demonstrate that this person is effectively bound by compatible confidentiality obligations.

If the freelancer themselves uses other people — assistants, partners or subcontractors — the topic must be explicitly framed. Failing that, access must be prohibited.

Security and minimum measures

An NDA doesn't replace a security policy, but it must provide for minimum obligations.

Depending on the context, these obligations can include:

• the use of named accounts;
• a ban on sharing credentials;
• enabling MFA;
• encryption of media;
• a ban on storing certain documents locally;
• deletion of copies at the end of the service;
• the use of tools approved by the firm or the end client;
• compliance with environment-access rules;
• prompt notification of an incident or unauthorised access.

Back-to-back must remain realistic. Passing down obligations impossible to control or perform can create an additional risk.

The duration of confidentiality

The duration must be compatible with the main contract.

Some NDAs provide for a limited duration. Others provide for confidentiality as long as the information isn't public. Trade secrets can warrant special treatment.

The key point: the downstream obligation must not expire before the upstream one if that creates a gap for the firm.

Return and destruction

At the end of the service, the end client can require the return or destruction of the confidential information.

The back-to-back NDA must therefore provide an equivalent mechanism:

• return of documents;
• deletion of local copies;
• deletion of exports;
• removal of access;
• withdrawal of credentials;
• confirmation of destruction where necessary.

In a tech service, this point must be handled practically. Information can live in Git repositories, tickets, temporary files, backups, notebooks, log exports or documentation tools.

Incident notification

The notification clause must be aligned with the main contract.

If the end client requires prompt notification of a confidentiality breach, the firm must ensure the information can flow up in time from the person actually doing the work.

You must therefore avoid a chain where the freelancer has no clear obligation to report an incident, or only a vague and late one.

Liability

The back-to-back NDA must be consistent with the liability commitments the firm has taken on.

Too great a gap between upstream and downstream liability can leave the firm exposed.

That doesn't mean all the limits must be identical. But the caps, exclusions, penalties, indemnity obligations and remedies must be re-read carefully.

Point of vigilance: back-to-back isn't only a confidentiality question. It can have a direct impact on the firm's contractual liability.

Common mistakes in a back-to-back NDA

Some mistakes come up often in subcontracting chains involving an end client, a firm and a non-EU freelancer.

Getting a generic NDA signed

A generic NDA can be insufficient if the end-client contract imposes specific obligations.

For example, a standard NDA may say nothing about:

• access from a non-EU country;
• the use of AI tools;
• destruction of copies;
• second-tier subcontracting;
• trade secrets;
• notification deadlines;
• audits;
• the end client's security rules.

In that case, the document exists, but it doesn't properly protect the firm.

Copy-pasting the end client's NDA without adaptation

The opposite mistake is passing the end client's NDA as-is to the downstream party.

That can create inconsistencies.

Some clauses are drafted for a client-supplier relationship, not for a technical subcontracting relationship. Some obligations assume direct contractual access to the end client. Others impose deadlines or formalities an independent freelancer can't honour.

Back-to-back must be faithful in substance, but adapted to each party's real place in the chain.

Forgetting the subcontracting authorisation

The NDA isn't enough if the end-client contract strictly frames subcontracting.

Some clauses impose:

• prior authorisation from the end client;
• a named list of subcontractors;
• a ban on access outside certain territories;
• an information obligation;
• a security validation;
• an obligation to have equivalent commitments signed.

Before involving a non-EU freelancer, the firm must check that the end-client contract allows this organisation.

Neglecting proof

If the end client asks questions, the firm must be able to produce evidence.

That can include:

• the NDA or the signed confidentiality clause;
• the purchase order;
• the subcontracting conditions;
• the accepted security rules;
• the effective date;
• the service scope;
• the authorised access;
• any country or tool restrictions.

Without proof, compliance remains hard to demonstrate.

Treating confidentiality separately from the GDPR

The NDA covers confidentiality. It doesn't replace the obligations linked to personal data.

If the freelancer accesses personal data, you must analyse the parties' roles, the instructions, the security measures, any transfers outside the EU and the end client's requirements.

The topic can involve a data processing agreement within the meaning of the GDPR, in addition to the NDA.

This article does not constitute personalised legal advice. The applicable clauses must be assessed against the end-client contract, the service scope, the countries involved and the data processed.

Example of a back-to-back contractual chain

A frequent configuration can look like this:

1. The end client signs a contract with the firm.
2. That contract imposes confidentiality obligations and frames subcontracting.
3. The firm contracts with a French supplier.
4. The French supplier contracts in its own name with the tech freelancer based outside the EU.
5. The confidentiality obligations are passed down into the clauses applicable to the freelancer.
6. The access, deliverables and security rules are framed by the purchase order or the project documents.

In this chain, the important point is the consistency between the commitments.

The freelancer must not be an informal link. They must enter a clear contractual relationship, with obligations compatible with those the firm must honour towards the end client.

How StelarWork fits into this chain

StelarWork steps onto the contract between the French firm and the tech freelancer based outside the EU.

Concretely, StelarWork invoices the firm as a French supplier, contracts in its own name with the freelancer, pays the freelancer and carries a compliance framework designed to reduce contracting friction.

The goal is to turn a freelancer who's hard to sign directly into a clean French supplier the firm can use — without making the freelancer an employee, without acting as the freelancer's representative in France, and without signing in the freelancer's name.

Within a back-to-back NDA, StelarWork can help structure the contractual chain around several points:

• carrying the relevant confidentiality obligations into the downstream relationship;
• documenting the commitments applicable to the freelancer;
• consistency between the firm's purchase order and the service scope;
• formalising the deliverables and the expected outcome;
• limiting access to the service's needs;
• keeping evidence useful to the firm;
• clarifying the responsibilities between the parties.

StelarWork doesn't act as a law firm and doesn't replace your advisers' contractual review. StelarWork's role is operational and contractual: making the chain cleaner, more readable and more acceptable to a French firm.

In practice: the firm keeps its relationship with the end client. StelarWork acts as the firm's contractual supplier and frames the relationship with the non-EU freelancer in a service-and-deliverables logic.

Back-to-back NDAs and the outcome-based service

The NDA must sit within a clear service relationship.

For a firm, it's preferable for the purchase order to describe:

• the service scope;
• the expected deliverables;
• the deadlines or milestones;
• the conditions of access to the environments;
• the confidentiality rules;
• the restrictions imposed by the end client;
• the terms for returning or deleting the information;
• the criteria for validating the outcome.

This approach reduces ambiguity.

It also avoids confusing the service with a mere assignment of resources. The contract must concern a service, deliverables and an outcome, not an informal secondment of a person.

Points of vigilance before bringing in a non-EU freelancer

Before giving access to the end client's information, the firm must check several points.

Does the client contract authorise subcontracting?

Some contracts prohibit any subcontracting without prior agreement.

Others allow it under conditions. For example: notification, written approval, compliance with security policies, location of access, an equivalent confidentiality commitment.

The back-to-back NDA doesn't fix unauthorised subcontracting.

Does the end client authorise access from a non-EU country?

That's a separate topic from the freelancer's nationality.

What often counts is the real place from which the information is viewed or processed.

An end client may accept a subcontractor but prohibit access from outside certain territories. It may also impose a specific security validation.

Is personal data involved?

If personal data is accessible, the NDA isn't enough.

You must look at the GDPR obligations, the end client's instructions, any transfers outside the EU and the applicable security measures.

Are the tools used compatible with the client's rules?

The freelancer may have their own habits: cloud storage, an AI assistant, a note manager, a capture tool, messaging, a personal Git repository.

Back-to-back must provide that the end client's and the firm's rules prevail over these personal habits.

Is the end of the service planned for?

The end of a service is often when the gaps appear.

You must anticipate:

• closing access;
• deleting copies;
• returning documents;
• deleting API keys;
• deactivating accounts;
• confirming destruction where required.

A quick reading table for a firm

Topic	Question to ask	Risk if not handled
Scope	Which information is confidential?	Too narrow an NDA
Subcontracting	Does the end client authorise it?	Breach of the main contract
Non-EU access	Is the access country accepted?	Contractual or security non-compliance
GDPR	Is personal data accessible?	Poorly framed processing or transfer
Tools	Are the freelancer's tools authorised?	Leak via a third-party tool
Notification	Who alerts whom in an incident?	Late notification
Duration	Does the downstream obligation last long enough?	Confidentiality gap
Proof	Are the commitments documented?	Difficulty demonstrating compliance
End of mission	Are access and copies removed?	Persistence of sensitive information

Confidentiality clause: what back-to-back must avoid

A good back-to-back NDA must not create contradictions with the main contract.

It must notably avoid:

• a weaker definition of confidential information;
• a duration shorter than the one imposed upstream;
• downstream liability inconsistent with the firm's commitments;
• an implicit authorisation of further subcontracting;
• excessive freedom in using third-party tools;
• the absence of incident notification;
• the absence of return or destruction;
• a vague reference to the end client;
• a clause that assumes the freelancer contracts directly with the end client when that isn't the case.

Back-to-back must reflect the reality of the contractual chain. Each party must know to whom it commits, on what, for which service and with which limits.

The specific case of freelancers based in Dubai, Bali or outside the EU

A freelancer based outside the EU isn't necessarily a problem. The problem appears when the contractual chain doesn't reflect the operational reality.

A sound configuration notably assumes:

• the freelancer's genuine residence in the stated country;
• a service actually delivered remotely;
• no organised presence in France to carry out the mission;
• a contract concluded in each party's own name;
• identified deliverables;
• framed client access;
• confidentiality passed down back-to-back.

Conversely, an artificial or abusive configuration must be ruled out. A shell entity, a fake residence, an undeclared organised presence in France or an arrangement designed to mask the reality of the service can create serious risks.

StelarWork does not sell tax optimisation or a tax status. If a freelancer is already a genuine non-EU tax resident, StelarWork removes an administrative and contractual friction for the firm. The principle remains reality: effective residence, work genuinely done remotely, consistent contracts and no fictitious arrangement.

This article does not constitute personalised tax or legal advice. Any cross-border situation must be analysed with competent advisers against the real facts.

Why the firm should handle the NDA before kick-off

The back-to-back NDA must be handled before access to confidential information.

Regularisation after kick-off is always more fragile.

Before launch, the firm can still:

• check the end client's requirements;
• frame the subcontracting;
• limit access;
• have the necessary clauses accepted;
• document the commitments;
• provide for the security rules;
• refuse certain uses;
• organise the end of the service.

After kick-off, the information has already circulated. The risk is no longer theoretical.

A pragmatic approach to setting up back-to-back

For a firm, a simple method is to proceed in five steps.

1. Read the end-client NDA

Identify the obligations that must be passed down.

Look in particular at:

• the definition of confidential information;
• the duration;
• the usage restrictions;
• subcontracting;
• the security obligations;
• the notification deadlines;
• the return;
• the liability;
• the territorial requirements.

2. Check the right to subcontract

Before mobilising an external freelancer, check whether the end-client contract requires authorisation, information or validation.

That's often the most sensitive point.

3. Translate the obligations into downstream clauses

The freelancer or downstream supplier must receive compatible obligations.

The document must be understandable, workable and enforceable.

4. Frame the access and the tools

Confidentiality doesn't rest on a signature alone.

It also depends on the real access, the tools used, the environments viewed and end-of-mission discipline.

5. Keep the proof

The firm must be able to demonstrate that the chain is under control.

The proof can be contractual, operational and documentary.

When to bring in StelarWork

StelarWork is relevant when your firm has identified a non-EU tech freelancer you can't or won't sign directly.

Frequent cases:

• the freelancer has no French structure;
• the end client's vendor onboarding blocks a foreign counterparty;
• the procurement department refuses a direct relationship with a non-EU independent;
• the client contract requires a better-documented subcontracting chain;
• the end-client NDA must be passed down cleanly;
• the firm wants an identified French supplier, with readable invoicing and a readable contractual framework.

StelarWork then steps in as the firm's French contractual supplier and frames the relationship with the non-EU freelancer, consistently with the purchase order, the confidentiality and the applicable subcontracting obligations.

The goal isn't to bypass the end client's requirements. The goal is to make the contractual chain clearer and more compliant.

Conclusion

The back-to-back NDA is an essential tool as soon as a firm brings an external freelancer onto a service exposed to confidential information.

Getting a standard document signed isn't enough. You must align the end client's obligations with those of the supplier and the freelancer, check the subcontracting, frame the access, document the proof and plan the end of the service.

For tech freelancers based outside the EU, the topic becomes even more sensitive. The end client may accept the expertise but refuse a vague contractual chain.

StelarWork helps firms turn this type of situation into a structured, more readable French supplier relationship, with a framework designed to pass the essential confidentiality obligations down back-to-back.

FAQ

What is a back-to-back NDA?

A back-to-back NDA is a mechanism that passes the main contract's confidentiality obligations down to the parties further along the subcontracting chain. The goal is for everyone with access to confidential information to be bound by obligations compatible with those imposed by the end client.

Must the back-to-back NDA be identical to the end client's NDA?

Not necessarily. It must be equivalent on the essential obligations, but adapted to each party's real position. A copy-paste can create inconsistencies if some clauses only apply to the relationship between the end client and the firm.

Is a generic NDA enough for a non-EU tech freelancer?

Often not. A generic NDA may not cover the end client's requirements, the subcontracting restrictions, access from a non-EU country, the tools used, incident notification or destruction of information at the end of the service.

Must the end client authorise the freelancer?

That depends on the main contract. Some contracts require prior authorisation or informing the end client for any subcontracting. The firm must check this obligation before giving access to confidential information.

Does the NDA cover personal data?

No, not on its own. The NDA covers confidentiality. If the freelancer accesses personal data, you must also analyse the GDPR obligations, the parties' roles, the instructions, the security measures and any transfers outside the EU.

Does StelarWork sign in the freelancer's name?

No. StelarWork contracts in its own name with the firm and in its own name with the freelancer. StelarWork doesn't act as the freelancer's representative in France and doesn't sign in the freelancer's name.

Is StelarWork a law firm?

No. StelarWork isn't a law firm and doesn't provide personalised legal advice. StelarWork provides a contractual and operational framework designed to make the relationship between a French firm and a non-EU tech freelancer cleaner, more documented and more usable.

Why go through a French supplier for a non-EU freelancer?

For a firm, a French supplier can simplify the contracting, the invoicing, the procurement requirements and the documentation of the subcontracting chain. It doesn't remove the need to comply with the end-client contract, but it reduces certain frictions linked to a direct relationship with a non-EU freelancer.

Does the back-to-back NDA remove all risk?

No. It aims to reduce the risks linked to confidentiality and subcontracting, but it doesn't remove all risk. Compliance also depends on the end-client contract, the real access, the tools used, the data processed and the operational execution.

When should the back-to-back NDA be put in place?

Before any access to confidential information. Setting it up after kick-off is more fragile, because the information has already circulated.