GDPR Breaks Offshore Back Office Models

The offshore back office model was built on a simple premise: the work can be done anywhere, so do it where it costs least. For two decades that premise held, and payroll, accounts payable, reconciliations, HR administration and customer support migrated steadily to delivery centres in India, the Philippines, Egypt, Eastern Europe and elsewhere. GDPR did not outlaw any of that. What it did was make the transfer of personal data outside the European Economic Area a decision requiring a legal basis, documentation and — after subsequent case law — an assessment of the destination country's surveillance regime. The cost of the model stopped being purely commercial and became partly legal, and a set of arrangements that had evolved organically over fifteen years suddenly needed justifying one flow at a time. The redesign that followed was less about moving work back and more about discovering what "the work" actually involved.

The transfer rule that nobody had modelled

The single most important thing organisations learned was that a transfer does not require data to move. Remote access is a transfer. A support engineer in Manila logging into a system hosted in Frankfurt has caused a transfer of personal data to the Philippines, even though no file was copied and nothing was downloaded. So has an administrator in Bangalore with production access to an EU HR system. So has an offshore developer troubleshooting against a copy of production data. So has a follow-the-sun service desk where the night shift sits in a different jurisdiction. This broke the mental model almost everyone had. Data residency programmes had been built around where data is stored, and storage location had been the answer given to every customer and regulator. Access location had never been mapped, because it had never needed to be. Organisations that ran their data flow analysis honestly found that their carefully localised EU platform was routinely accessed from three or four countries by support, administration, development and analytics teams that nobody had listed. The second realisation was about layers. The delivery centre was the obvious transfer. Underneath it sat the provider's own infrastructure, their support tooling, their offshore development partners, their quality monitoring and recording platforms, and their ticketing systems — each potentially in a different country. A single outsourced process could involve personal data touching four jurisdictions before anyone had done anything unusual.

The mechanisms, and what they actually cost

Four routes were available, and their practical weight differs sharply. Adequacy is the cheapest and applies where the European Commission has recognised a destination as providing essentially equivalent protection. It covers a limited set of countries, and the offshore delivery map largely does not overlap with it — which is why adequacy solved the problem for very few back office arrangements. Standard contractual clauses became the workhorse and carried an obligation that grew heavier after later case law: the exporter must assess whether the destination's laws, particularly around government access, prevent the clauses from being effective, and must apply supplementary measures where they do not. A transfer impact assessment per destination and per flow is real analytical work, it must be repeatable, and it is uncomfortable because the honest answer for several major delivery locations is that additional technical measures are doing most of the load-bearing. Binding corporate rules work well for captive centres inside a single group, and the approval process is long and expensive enough that only large organisations pursue it. Derogations — consent, contractual necessity — are for occasional cases and cannot support systematic, repeated transfers, which is what a delivery model is. What the mechanism does not do is reduce the data. That turned out to be where the real redesign happened.

What the better organisations actually changed

The response that produced durable results was not relocation. It was re-scoping what offshore teams could see. The insight is that most back office work does not require the personal data it has always been given. An accounts payable clerk matching an invoice to a purchase order needs supplier, amount, reference and approval status; they do not need the bank details or the contact's personal information visible on screen. A payroll processor running a calculation needs employment terms and hours; they do not always need the name, the identity document number and the home address attached. A support agent triaging a ticket needs the case and the entitlement; they frequently do not need the full customer record. So the patterns that worked were minimisation at the boundary — field-level masking and role-based views so the offshore team sees the working data and not the identifying data; pseudonymisation where the processing is genuinely statistical or reconciliatory; splitting processes so the small number of steps genuinely requiring identified personal data are done onshore while the volume work is done wherever it is efficient; and virtual desktop or streamed access with no local storage and full session logging, which keeps data in the EU environment while people work on it from elsewhere. That last one reduces risk substantially and, importantly, does not eliminate the transfer — access is still access — but it changes what supplementary measures you can credibly claim. The pattern underneath all four: the constraint pushed organisations to ask what data each task actually needs, and the answer was almost always "less than it currently gets". That is a security improvement and an operational simplification that would have been worth doing anyway, and essentially nobody did it until a regulation forced the question.

Practical Guidance for Delivery Model Compliance Review

• Map access, not just storage. List every location from which personal data can be reached, including support, administration, development, analytics and the provider's own sub-contractors.
• Treat remote access as a transfer in the documentation. It is the most commonly missed flow and the hardest to explain after the fact.
• Ask what data each task genuinely requires. Minimisation at the delivery boundary reduces legal exposure and security risk simultaneously, and usually simplifies the work.
• Apply field-level masking and role-based views rather than all-or-nothing access. Full record visibility is a legacy of how systems were built, not a requirement of the process.
• Split processes at the point where identification is actually needed. A small onshore step frequently unlocks the rest of the volume being handled anywhere.
• Do transfer impact assessments as a repeatable template per destination. One-off legal memos do not survive the next delivery centre, and the assessment must be refreshable.
• Enumerate the provider's own sub-processor jurisdictions. Tooling, hosting, development and monitoring frequently sit in countries absent from the main contract.
• Instrument and log offshore access. The ability to show who accessed what, from where, is the evidence that supplementary measures are real rather than described.

The Regional Angle

For Gulf organisations this was not a European compliance story. It was a direct commercial one, in two directions. The region is a significant consumer of offshore back office services, principally from India, the Philippines and Egypt, and it is increasingly a supplier of them — shared service centres in Dubai, Riyadh, Cairo and Amman serving regional and international group entities. Both roles attract obligations. A Dubai shared service centre processing HR or finance data for a European group company is a processor handling European personal data, and its location is a third country requiring a transfer mechanism. Groups discovered this late, because an internal service centre does not feel like an offshore vendor even though the law treats the flow identically. The same logic then repeated locally as Saudi PDPL, the UAE federal framework and the separate DIFC and ADGM regimes introduced their own transfer conditions, so a single regional service centre can face several parallel transfer analyses for the same process. The employment data profile makes this sharper here than elsewhere. Regional HR records carry passport copies, residency visa documentation, Emirates ID or Iqama numbers, medical screening results, dependants' documents and end-of-service calculations. That is a concentration of identity documentation rather than of contact details, and its misuse profile is different — identity documents enable impersonation in a way an email address does not. An offshore HR administration arrangement moving that category of data is a materially higher-risk transfer than an offshore invoice-matching arrangement, and the two are routinely governed by the same contract and the same controls. The intermediary layer complicates the map further. PROs, typing centres, visa agents, medical testing centres and recruitment agencies sit between the employer and the government processes, receiving documents by email and messaging app. They are processors, they are frequently unmapped, and where they operate across borders they are also transfers. Any delivery model review that covers the outsourcing contract and stops there has documented the visible half of the flow. Two further specifics worth building into the design. Integrator-operated estates mean standing privileged access from global delivery centres into regional production systems — a transfer in every meaningful sense, usually undocumented, and the correct contractual questions are who specifically, from which country, under whose supervision, and revocable within the hour. And the regional cloud build-out changed the storage question without touching the access question: hosting in Dubai or Riyadh satisfies residency, and if administration is performed from three other countries, the residency claim is narrower than it sounds.

The objection worth taking seriously

The strongest criticism is that transfer regulation has imposed substantial cost and complexity for protection that is largely theoretical, and that it has done economic damage to exactly the countries it should not have. The practical argument is hard to dismiss. Transfer impact assessments are performed by organisations with no ability to evaluate a foreign surveillance regime, producing documents that follow a template and reach the conclusion the business requires. Supplementary measures frequently amount to encryption in transit and at rest, which the destination's authorities were never going to defeat anyway and which does nothing about lawful compelled access to a provider. Meanwhile the cost falls disproportionately on smaller service providers in developing economies, who must fund compliance infrastructure sized for their largest client, and the effect is to concentrate the market in large incumbents — which is not obviously good for data protection. There is a consistency problem too. Organisations conducting elaborate assessments of one destination frequently accept other jurisdictions with broader state access powers and less transparency without analysis, because the framework directs attention by legal category rather than by actual risk. And the observed harm profile does not match the regulatory focus: the incidents that have actually damaged people in offshore delivery have overwhelmingly been ordinary failures — excessive access rights, poor offboarding, unencrypted extracts, fraud by insiders — rather than foreign state surveillance. The defensible position is that the framework's value lies almost entirely in what it forced organisations to do incidentally. Very few knew where their data was accessed from. Very few had asked whether offshore teams needed full record visibility. Very few had enumerated the sub-processor chain. Answering those questions improved security independently of any transfer conclusion, and the organisations that treated the exercise as an operational review rather than a legal filing got value from it. The ones that treated it as a document production exercise got documents.

Common Questions

Does remote access count as a transfer if nothing is downloaded?

Yes. Making personal data available to someone in a third country is a transfer regardless of whether a copy is made, which is why access mapping matters as much as storage mapping.

Do offshore arrangements need to be brought back onshore?

Rarely. Most were solvable with a valid transfer mechanism plus genuine data minimisation at the boundary — masking, role-based views and process splitting — which is cheaper than relocation and usually improves the operation.

What is the most commonly missed flow?

The internal one. A shared service centre or group IT function in another country processing data for a European or in-scope entity is a transfer, and organisations consistently map external vendors while omitting their own subsidiaries.

How do AI services change the delivery model analysis?

They add a transfer that no contract negotiation created. When a provider enables an AI capability — call summarisation, document extraction, quality monitoring, an agent assistant — the data typically leaves for a model provider that may sit in yet another jurisdiction, and it happens through a product update rather than a change request. The derived artefacts compound it: retained prompts and completions, embeddings built from your records, and fine-tuned weights are copies in places your transfer documentation does not mention and your deletion clause cannot easily reach. Three practical additions to a delivery model review: require notification before AI features are enabled on your data, ask specifically where inference runs and what is retained for how long, and extend the minimisation discipline you applied to human access to machine access as well — the question of what data a task actually needs applies identically to a model, and it is easier to answer before the retrieval index is built than after.

---

Delivery Model Compliance Review — map access rather than storage, and minimise what the boundary exposes before choosing a transfer mechanism.