Offshoring Personal Data: Who Carries the Liability?

By late 2007, a European bank could have its customer records keyed in Bangalore, its statements printed in Manila and its complaint calls answered in Cape Town, and still describe itself, accurately, as the sole controller of that data. The work had moved. The legal responsibility had not moved an inch. That asymmetry was written into European law more than a decade earlier and is still the most misunderstood principle in outsourcing. The 1995 Data Protection Directive required the controller to choose a processor providing sufficient guarantees over technical security and organisational measures, to bind that processor by a written contract, and to ensure the processor acted only on the controller's instructions. Nothing in the framework allowed the obligation to travel with the work. What made 2007 the year this became a live commercial issue rather than a legal footnote was volume. Offshore processing had reached a scale where the number of people outside Europe handling European personal data ran into the hundreds of thousands — and the incidents had started.

The Incidents That Changed the Conversation

The mid-2000s produced a sequence of stories that outsourcing buyers found difficult to explain to their boards: undercover reporters offered customer records by call centre staff; a bank employee at an offshore site implicated in defrauding accounts of a sum reported in the hundreds of thousands of pounds; data protection authorities receiving complaints they had no practical ability to investigate because the processing sat outside their jurisdiction. The individual cases mattered less than what they exposed. Nearly every affected buyer discovered the same three things during the subsequent review:

• The contract contained a generic confidentiality clause and no specific security obligations.
• Nobody had audited the site. Assurance consisted of the provider's own certification claims.
• The provider had subcontracted parts of the work, and the buyer could not produce a list of who held the data. Those findings recur, almost word for word, in vendor reviews conducted today.

Why Offshore Processing Is Legally Harder

Three distinct obligations get collapsed into one in most procurement processes, and each fails differently. Accountability does not transfer. You remain answerable for what your processor does. In the current framework this is explicit: controllers must use only processors providing sufficient guarantees, and must impose specific contractual terms covering instructions, confidentiality, security, sub-processing, assistance and deletion. A signed vendor NDA satisfies none of it. Transfer needs a separate legal basis. Moving personal data to a country without an adequacy finding requires its own mechanism — standard contractual clauses, binding corporate rules, or a derogation. In 2007 this meant model clauses; today it also means an assessment of whether local law in the destination country undermines those clauses in practice, and supplementary measures where it does. The chain keeps extending. Your processor engages sub-processors: an in-country payroll partner, a cloud platform, a support team in a third region, and now, increasingly, an AI service that processes content on behalf of the vendor. Each addition is a new place your data sits and a new jurisdiction that might compel access to it. Contracts that require notice of sub-processor changes exist so you can track this. Most buyers never read the notices.

The Practical Gap Between Contract and Reality

The legal architecture is stronger than it was in 2007. The operational assurance behind it frequently is not. A data processing agreement is a statement of what should happen. It is worth precisely as much as your ability to verify that it does. The questions that separate the two:

• Can the provider produce a current list of every location and legal entity where your data is processed, stored, backed up and accessed from? Including support access, which is the most commonly omitted category.
• Which individuals at the site can see unmasked personal data, and why do their roles require it?
• Is production data used in testing and training environments? This is the most frequent breach of the instruction-only principle, and it is almost never disclosed.
• What technical controls prevent bulk extraction — clipboard restrictions, device controls, download monitoring, print controls at the processing site?
• Has anyone from your organization, or an independent auditor acting for you, actually visited or examined the site in the last two years?
• Can local authorities in the destination country compel disclosure of your data, and what is the provider obliged to tell you if they do?
• On termination, what is deleted, when, from which systems and backups, and who certifies it?

What to Do About It

• Map the chain to its end. Not your vendor — every entity behind your vendor. Refresh it annually and after every sub-processor notice.
• Contract specifics, not principles. Named locations, named categories of sub-processor, defined access controls, breach notification within a stated number of hours, audit rights that include physical sites, and deletion certification.
• Assess the destination jurisdiction, not just the vendor. Local disclosure law is part of your risk whether or not it appears in the contract.
• Minimise what you send. The cheapest way to reduce offshore processing risk is to transfer fewer fields. Masking, tokenisation and reference identifiers remove most of the exposure without touching the operating model.
• Treat AI sub-processors as a category. Vendors are adding model providers to their processing chains, often through a general sub-processor clause signed years ago. Ask directly.
• Rehearse a breach at the offshore site. Who calls whom, in which time zone, and who is on the regulatory notification clock? The answer to the last question is always you.

The Principle Has Outlasted Every Framework

The legal instruments have all changed since 2007. The Directive became the GDPR. The original model clauses were replaced. Safe Harbor was struck down, and its successor has been challenged. India, the UAE, Saudi Arabia and most major processing destinations have introduced their own data protection statutes, which is a genuine improvement in the underlying environment. Through all of it, one rule has not moved: the organization that decides why and how personal data is processed carries the responsibility, wherever the keyboard is. Work can be sent anywhere. Accountability stays at the desk that signed the contract.

Common Questions

Who is liable when an offshore processor causes a data breach?

The controller remains accountable to regulators and data subjects for the processing it directs. Processors carry their own direct obligations under modern law, but that does not relieve the controller of its responsibility for selection, instruction and oversight.

What must a data processing agreement actually contain?

Processing only on documented instructions, confidentiality commitments, specified security measures, rules for engaging sub-processors, assistance with data subject rights and breach notification, audit rights, and deletion or return at the end of the engagement.

Can we offshore personal data to any country?

Only with a valid transfer mechanism, and increasingly only after assessing whether local law would undermine that mechanism. Some categories of data are also subject to localisation requirements that no contract can override.

How do we verify a processor rather than trust them?

Request the full processing location and sub-processor list, review access controls and test-data practices, examine independent audit reports rather than certification logos, and exercise audit rights at least once during the contract term.

---

Processor Liability Review — Outpace maps your full processing chain to its final sub-processor, tests your contracts against the obligations you actually carry, and closes the gap between what your data processing agreements promise and what your vendors do.