Subcontracting each tech role outside the EU: the profile-by-profile guide

You have found the right React, DevOps, data or SAP expert, but they work from Dubai, Bali or another country outside the EU, and your end client expects the same level of security, control and quality as with a French supplier.

Subcontracting a tech profile outside the EU is not only a contractual issue. It is an execution issue.

Depending on the role, the sensitive points change: access to environments, handling of data, administration rights, exposure to secrets, dependence on internal teams, definition of deliverables and mission management.

A React front-end developer does not expose the same risks as a DevOps engineer with production access. An SAP consultant is not managed in the same way as a cybersecurity expert. A data engineer does not provide the same proof of outcome as a mobile developer.

For an IT services firm, the challenge is therefore simple: turn a non-EU skillset that is difficult to contract with into a structured, auditable service that is acceptable to procurement, security and the end client.

What non-EU subcontracting really changes for an IT services firm

Being located outside the EU does not make the service impossible. It means it must be framed more carefully.

The question is not whether the freelancer is competent. The question is whether the IT services firm can justify to its client that the mission is structured as a controlled service.

This requires four reflexes.

Limit access to what is strictly necessary

A non-EU profile can work effectively without having broad and permanent access to the entire information system.

Access must be proportionate to the role, the mission phase and the expected deliverable. Read access to a Git repository does not have the same level of criticality as administrator access to a cloud platform or a production database.

The IT services firm must be able to answer simple questions:

• which environments are accessible;
• from which country access is performed;
• with what level of authentication;
• for how long;
• with what traceability;
• under which revocation procedure.

This point becomes central as soon as the profile works from a country outside the EU, even if the relationship is technically smooth.

Describe verifiable deliverables

Role-based subcontracting works when the expected outcome is clearly stated.

A good deliverable is not just a Jira task. It is a verifiable element: a delivered component, a pipeline put in place, a validated dashboard, a documented vulnerability analysis, tested SAP configuration, or a mobile application published on a staging environment.

The right level of detail depends on the role. But the principle remains the same: the IT services firm buys a service, not undifferentiated availability.

Framing the mission through deliverables protects the IT services firm on two fronts: it makes operational management easier and reduces ambiguity between an external service and excessive integration into the end client’s teams.

For the general framework, it is preferable to deal with the foundations before going into role-specific cases: the IT services firm guide to non-EU subcontracting details the compliance points to master before going down to React, DevOps, data or cybersecurity level.

Manage the mission without creating excessive operational dependence

Mission management must remain outcome-oriented.

The IT services firm may monitor progress, organise synchronisation points, validate milestones and request corrections. However, it must avoid an organisation that makes the relationship look like daily hierarchical integration.

The signals to watch for are well known: hours imposed like those of an internal employee, holiday approval, permanent managerial reporting, disciplinary control, and the absence of autonomous deliverables.

On this point, the useful reference remains the signals that get a service reclassified as employment, particularly when the non-EU profile works within a highly integrated agile team.

Adapt security to the role, not the profile’s status

Security must not be generic. It must be calibrated according to the nature of the mission.

A React developer working on a public front office does not have the same level of exposure as a DevOps engineer handling cloud secrets or a cybersecurity consultant auditing vulnerabilities.

The right approach is to define, for each role:

• the assets exposed;
• the accessible data;
• the environments concerned;
• the authorisations required;
• the evidence expected at the end of the mission;
• the reversibility rules.

Non-EU React developer: pay attention to product access and repositories

Subcontracting a non-EU tech profile for React is often operationally straightforward. Tasks are visible, deliverables are frequent, and quality control can rely on pull requests, code review and front-end tests.

The risk comes less from the role itself than from integration into the product team’s day-to-day operating model.

Access to frame

A React developer may need:

• access to the front-end repository;
• access to product documentation;
• a development environment;
• a ticketing tool;
• sometimes a staging environment.

However, access to real user data must be questioned. For many front-end missions, anonymised or simulated datasets are enough.

Access to analytics tools, internal back offices or production environments should be reserved for cases where it is genuinely necessary.

Expected security

The usual control points are:

• strong authentication;
• systematic code review;
• control of npm dependencies;
• vulnerability scanning;
• separation between development and production environments;
• no secrets in the code.

Being located outside the EU increases the relevance of these controls. It does not replace them.

Relevant deliverables

For React, deliverables can be defined by components, user journeys or screens:

• documented front-end component;
• fix for a reproducible bug;
• integration of a validated mock-up;
• accessibility improvement;
• unit tests or end-to-end tests;
• behavioural documentation.

Proof of outcome lies in the delivered code, the associated tests and functional validation.

Operational management

Management can remain simple: backlog, short milestones, code review and regular demonstrations.

The point to avoid is substituting the profile for an internal team member without a specific scope. If the profile is absorbed into rituals, receives indistinct daily instructions and delivers no identifiable block, the relationship becomes harder to defend.

Non-EU DevOps: the critical point is access to environments

A non-EU DevOps profile can bring significant value: automation, CI/CD, infrastructure as code, observability, cloud optimisation and more reliable deployments.

But the role concentrates the most sensitive access risks.

A DevOps engineer may touch secrets, cloud rights, production pipelines, logs, backups and sometimes data. Subcontracting must therefore be stricter than for a standard application profile.

Access to frame

The basic rule is least privilege.

Access must be:

• temporary where possible;
• limited to a project or environment;
• separated between development, staging and production;
• logged;
• revoked at the end of each sensitive phase.

Shared accounts should be prohibited. Secrets must not pass through informal channels.

For a non-EU DevOps engineer, proper framing is not a blocker. It is what makes the mission acceptable to the end client’s security teams.

Expected security

Requirements must cover:

• identity and access rights management;
• logging of actions;
• secrets rotation;
• change validation;
• backups and rollback;
• segregation of duties;
• review of infrastructure scripts.

The required level must be proportionate to the scope. A read-only Terraform audit does not have the same criticality as work on a production deployment chain.

Relevant deliverables

For DevOps, deliverables are often highly objective:

• documented CI/CD pipeline;
• Terraform or Ansible module;
• deployment procedure;
• observability dashboard;
• backup strategy;
• incident runbook;
• hardening report.

These deliverables make acceptance testing and reversibility easier.

Operational management

Management must rely on tracked and validated changes.

The IT services firm must avoid informal production interventions without a ticket, without review and without evidence. This is true for any provider, but even more so when the profile works outside the EU.

Non-EU data profiles: the main issue is data exposure

Data profiles — data engineer, data analyst, analytics engineer, ML engineer — raise a specific question: what data does the provider actually see?

The skill level may be excellent. But if the mission involves personal, sensitive or strategic data, or data covered by client commitments, the framework must be strengthened.

Access to frame

Before opening access, the IT services firm must distinguish between:

• anonymised data;
• pseudonymised data;
• test data;
• aggregated data;
• production data;
• personal data;
• sensitive business data.

In many cases, a non-EU data profile can work on prepared datasets, limited extracts or compartmentalised environments.

Direct access to production must remain exceptional and justified by the deliverable.

Expected security

Useful controls include:

• compartmentalisation of workspaces;
• data encryption;
• query logging;
• export limitation;
• prohibition of uncontrolled local copies;
• deletion or return of datasets at the end of the mission;
• review of notebooks, scripts and models.

The risk is not limited to data leakage. It also concerns uncontrolled retention, exports into third-party tools or reuse of datasets for other purposes.

Relevant deliverables

Data deliverables must be concrete:

• ingestion pipeline;
• transformation model;
• schema documentation;
• dashboard;
• analysis report;
• training model;
• data quality metrics;
• recovery procedure.

The deliverable must specify the sources used, the assumptions and the limitations.

Operational management

Management must involve the business, the data owner and security when the data is sensitive.

Validation must not only focus on the visual result of a dashboard. It must also cover data quality, transformation traceability and access compliance.

Non-EU cybersecurity: a higher level of trust and traceability

Subcontracting a non-EU cybersecurity profile requires particular attention. The provider may access highly sensitive information: vulnerabilities, internal architecture, security logs, audit results and incident procedures.

The point is not to exclude this type of mission. The point is to precisely frame the scope, tools and reporting.

Access to frame

Depending on the mission, the profile may work on:

• configuration audit;
• security code review;
• controlled penetration testing;
• vulnerability analysis;
• cloud hardening;
• security documentation;
• incident response.

Each case calls for a different level of access. A penetration test must not be launched without formal authorisation, written scope, intervention windows and escalation contacts.

Expected security

Requirements must be explicit:

• authorised scope;
• permitted methods;
• tools used;
• evidence retention rules;
• reporting channel;
• management of sensitive information;
• emergency procedure in the event of a critical finding.

Traceability is essential. It protects the end client, the IT services firm and the provider.

Relevant deliverables

Cybersecurity deliverables must be usable:

• audit report;
• risk matrix;
• technical evidence;
• prioritised recommendations;
• remediation plan;
• executive summary;
• counter-verification report.

A good deliverable does not merely list flaws. It enables the IT services firm and the end client to decide, prioritise and correct.

Operational management

Management must be more formally structured than for other roles.

Synchronisation points are useful, but they must remain linked to the mission scope. Sensitive actions must be authorised, documented and closed.

For roles that are highly integrated into client teams, the useful reference remains what distinguishes genuine subcontracting from staff secondment, in order to maintain a service logic structured around an outcome.

Non-EU SAP: frame business access and functional knowledge

A non-EU SAP consultant may work on configuration, expert support, interfaces, migration, documentation or testing.

The main risk comes from proximity to the end client’s business processes: finance, procurement, logistics, HR and production.

SAP often concentrates critical data and sensitive management rules.

Access to frame

Access must be limited by module, role and environment:

• FI/CO;
• MM;
• SD;
• PP;
• HCM;
• BW;
• SuccessFactors;
• S/4HANA;
• sandbox, staging or production environments.

Production access must be treated as a sensitive case. It must be justified, logged and time-limited.

Expected security

The key points are:

• segregation of roles;
• change traceability;
• transport control;
• functional validation;
• authorisation management;
• non-disclosure of sensitive business processes;
• documentation of configuration.

Business confidentiality is as important as technical security.

Relevant deliverables

SAP deliverables may include:

• functional specification;
• documented configuration;
• validated transport;
• test scenario;
• anomaly report;
• data mapping;
• user documentation;
• migration plan.

Acceptance testing must involve the relevant functional teams. SAP configuration is not validated solely because it works technically.

Operational management

The SAP consultant may have strong interaction with business teams. That is normal.

But the IT services firm must maintain a clear framework: scope, milestones, deliverables and validation methods. The relationship must not become permanent integration with no defined outcome.

Non-EU mobile developer: control secrets, stores and devices

Non-EU mobile subcontracting often concerns iOS, Android, Flutter or React Native.

The specific risk comes from certificates, signing keys, third-party SDKs, test data and access to publication consoles.

Access to frame

The mobile developer may need:

• the code repository;
• mock-ups;
• test APIs;
• a staging environment;
• a crash reporting tool;
• sometimes limited access to Apple or Google consoles.

Signing keys and developer accounts must remain strictly controlled. Direct sharing should be avoided where alternatives exist.

Expected security

Useful controls are:

• secrets management;
• dependency review;
• validation of the permissions requested by the application;
• control of third-party SDKs;
• testing on isolated environments;
• separation of development and production builds;
• publication traceability.

Being located outside the EU also requires clarification of rules on local storage, the use of personal devices and log exports.

Relevant deliverables

Mobile deliverables may include:

• integrated feature;
• crash fix;
• staging build;
• configuration documentation;
• compatibility test;
• performance optimisation;
• release note;
• build procedure.

A mobile deliverable must be testable on defined devices and OS versions.

Operational management

Management must avoid vague validations such as “the screen is almost finished”.

Acceptance criteria should be preferred: expected behaviour, target version, error cases, performance, compatibility and regression.

Mission management: the common foundation for all roles

Whatever the role, non-EU subcontracting must remain readable for three stakeholders: the end client, procurement and security.

Management must not only aim to “move the profile forward”. It must produce evidence.

Define the purchase order by outcome

Each mission must be connected to a scope, deliverables, milestones and acceptance criteria.

The purchase order is the natural tool for this. It avoids reopening a contractual debate for every intervention and makes it possible to connect each profile to an identifiable service.

To structure this framework, the right architecture for clean subcontracting details how the general framework, purchase order and back-to-back logic fit together.

Set up simple governance

Governance does not need to be heavy. It must be clear.

It may include:

• a contact person on the IT services firm side;
• a contact person on the end client side if necessary;
• progress meetings;
• validation milestones;
• an access register;
• a revocation procedure;
• formal acceptance testing.

The aim is not to multiply documents. The aim is to be able to demonstrate that the service is under control.

Onboard the provider as a supplier

Onboarding must cover access, security, confidentiality, tools, delivery rules and escalation contacts.

It must not be treated as a simple Slack or GitHub invitation.

The procurement approach is central, particularly when the non-EU freelancer cannot be referenced directly by the IT services firm or by the end client. An IT services firm’s procurement checklist helps structure this onboarding without overlooking the usual control points.

Preserve the service logic

Non-EU subcontracting is more robust when it remains organised around a supplier, a scope, deliverables and acceptance testing.

This does not prevent agility. It simply requires documenting what is expected, delivered and validated.

Agile rituals may exist. But they do not replace deliverables. Nor should they create a direct managerial dependence between the end client and the non-EU profile.

StelarWork’s role in this type of mission

StelarWork intervenes when the IT services firm has identified a competent non-EU tech freelancer, but one who is difficult to contract with directly within a framework acceptable to its procurement team, compliance function or end client.

StelarWork contracts in its own name with the IT services firm, invoices the IT services firm, pays the freelancer and carries the operational framework needed to turn this intervention into a readable supplier service.

The aim is to reduce administrative friction and secure execution, without mixing roles.

StelarWork does not enter into a contract on behalf of the freelancer. StelarWork does not act as the freelancer’s representative in France. The relationship is structured as a service between suppliers, with deliverables and a mission framework.

For the IT services firm, the benefit is concrete: retaining access to a rare non-EU profile while presenting its client with a French supplier, a service framework and execution rules that are easier to audit.

This model is particularly useful when the profile is already a genuine resident outside the EU, genuinely works remotely and has no organised presence in France. A sound configuration is based on the reality of the situation: place of residence, actual activity, autonomy and genuine remote execution. An artificial entity or fictitious organisation designed to mask a presence in France would be an abusive configuration to rule out.

FAQ

Can a non-EU tech profile be subcontracted on a sensitive client mission?

Yes, if the scope, access, deliverables and security are adapted to the mission’s level of sensitivity.

A React profile on a staging environment does not raise the same issues as a DevOps engineer with cloud access or a cybersecurity consultant. The right approach is to reason by role, exposed data and authorisation level.

Which non-EU tech roles require the most vigilance?

The most sensitive roles are generally those involving deep access to the information system or to data: DevOps, cybersecurity, data, SAP and some backend profiles.

This does not mean they are incompatible with non-EU subcontracting. It means the framework must be more precise: limited access, traceability, formal validation, documented deliverables and reversibility.

How can you prevent a non-EU mission from looking like internal integration?

You must manage it through deliverables, milestones and acceptance criteria.

The provider may take part in coordination meetings, but the mission must remain linked to an identifiable outcome. Daily instructions, hierarchical control and the absence of a specific scope create ambiguity that should be avoided.

Can StelarWork intervene if the IT services firm has already identified the non-EU freelancer?

Yes. StelarWork is designed for cases where the IT services firm already knows the profile but cannot, or does not want to, contract directly with them outside the EU.

StelarWork fits into the contractual relationship in its own name, invoices the IT services firm, pays the freelancer and carries the supplier framework needed to execute the service under better conditions of compliance and management.

Disclaimer

This article provides general information for IT services firms. It does not constitute personalised legal, tax or employment advice.

Non-EU subcontracting situations must be assessed according to the actual facts: the provider’s effective residence, place of execution, mission organisation, access, deliverables, autonomy, presence or absence in France, and contractual framework. Where the stakes are sensitive, have your configuration validated by your usual advisers.