Why Global Data Residency Matters

Every time you upload a PDF to a cloud service, two things happen: bytes travel across the internet to a data centre, and a legal jurisdiction attaches itself to your document. Both matter more than most users realise.

Latency: the physics side

A round trip from Johannesburg to a US-east data centre is about 230 milliseconds. To a European data centre it's around 150. That adds up fast when a summarisation job makes dozens of calls. Processing regionally can cut the wall-clock time by more than half on the same model.

Jurisdiction: the legal side

Where your document is processed determines whose laws apply to it. For EU users that means GDPR. For South African users it means POPIA. If your provider only processes in one region, you inherit whatever laws that region has — often without noticing.

What PDFalot does about it

We run processing in North America and Europe, and we route your document to the region closest to you unless you tell us otherwise. Documents are processed in memory and are not retained after your session ends. You can read the specifics in our Privacy Notice.

What to ask any provider

• Where physically is my document processed?
• How long is it retained, and can I force immediate deletion?
• Is it used to train models?
• Which sub-processors touch it?

Why 'in the cloud' is not an answer to 'where'

Cloud infrastructure is marketed as placeless, but every request lands on a physical machine in a physical building in a specific country, and that fact is what data protection law actually regulates. A vague answer like 'your data is stored securely in the cloud' tells you nothing about jurisdiction. A useful answer names a region — for example 'eu-west' or 'us-east' — because the region is what determines which legal regime governs the document while it sits on that machine, and which authority has the power to compel disclosure of it.

GDPR Chapter V and international transfers

The EU's General Data Protection Regulation does not simply forbid personal data from leaving the European Economic Area — it conditions that transfer on specific legal mechanisms, set out in Chapter V of the regulation. In broad terms, a transfer of personal data to a country outside the EEA is only lawful where one of a limited set of safeguards applies: an adequacy decision from the European Commission recognising that the destination country's protections are broadly equivalent to the EU's own; Standard Contractual Clauses agreed between the exporting and importing organisations; or, for transfers within a corporate group, Binding Corporate Rules approved by a supervisory authority. This is the mechanism that made the disputes over EU-US data flows — Schrems I and Schrems II being the well-known cases — into major compliance events rather than footnotes: an adequacy arrangement was struck down, and organisations that had relied on it had to fall back to Standard Contractual Clauses with additional safeguards almost overnight. None of this is a matter of best practice; it is a binding legal requirement with real enforcement history, and it is why serious document-processing providers publish exactly which transfer mechanism applies to which region rather than leaving it implicit.

What this means in practice for document uploads

If a document containing personal data — client names, ID numbers, salary figures, medical information — is uploaded from the EU and processed on a server outside the EEA without one of these mechanisms in place, the processing itself can be unlawful even if nothing goes wrong operationally and no breach occurs. The lawfulness question is separate from the security question. This is precisely why regional routing matters as a design choice, not only as a performance optimisation: keeping EU-originated documents within the EEA, or under a validated transfer mechanism when they leave it, removes an entire category of legal exposure before it has a chance to arise.

POPIA and the South African position

South Africa's Protection of Personal Information Act takes a broadly similar structural approach to GDPR but with its own conditions for cross-border transfer, set out in section 72. In summary, personal information may only be transferred to a third party in another country where the recipient is subject to a law, binding corporate rules, or a binding agreement that provides an adequate level of protection substantially similar to POPIA's own conditions for lawful processing, or where the data subject has consented, or the transfer is necessary for the performance of a contract. In practice, most cross-border document processing relies on the contractual route: a data processing agreement between the responsible party in South Africa and the operator abroad that contractually obliges the operator to handle the data to POPIA-equivalent standards. The Information Regulator, POPIA's enforcement body, has been increasingly active in recent years, so this is not a purely theoretical requirement — organisations processing South African documents through foreign infrastructure are expected to be able to point to the specific contractual basis for that transfer if asked.

UK GDPR: a related but separate regime

Since the UK left the EU, its data protection law is technically a separate instrument — UK GDPR, sitting alongside the Data Protection Act 2018 — even though it was built by carrying the EU regulation directly into UK domestic law at the point of exit. The two regimes have already started to diverge in secondary detail, and the UK's own approach to adequacy decisions and international transfers is set independently by the UK government and the Information Commissioner's Office rather than automatically tracking whatever the European Commission decides. For a document-processing provider, this means a document uploaded from London cannot simply be assumed to fall under the same transfer rules as one uploaded from Berlin, even though the two frameworks currently look similar on paper. Providers that serve both markets need to track UK adequacy status and EU adequacy status as two separate, independently maintained lists, because they are not guaranteed to stay aligned over time.

Data processing agreements and the sub-processor chain

None of the regimes above expect an end user to personally negotiate legal terms with a document-processing provider — that's the function of the data processing agreement, a contract in which the provider, acting as processor, commits to specific obligations toward the responsible party or controller: processing only on documented instructions, maintaining defined security measures, and notifying the controller of a personal data breach without undue delay. The part of that agreement that end users most often overlook is the sub-processor list. A document uploaded to a single named provider rarely stays with only that provider — the summarisation model might run on a separate AI infrastructure vendor, the file might briefly sit in a storage bucket operated by a cloud vendor, and logging or monitoring might run through a third analytics tool. Each of these is a sub-processor, and under GDPR the controller has both a right to be informed of sub-processor changes and, in many contracts, a right to object. A provider that cannot produce a current sub-processor list, or that is vague about which regions those sub-processors operate in, has effectively made the residency question unanswerable regardless of what its own primary data centre location is.

A reasonable checklist for reviewing a sub-processor list

1. Confirm each sub-processor's role — is it handling storage, computation, logging, or something else — because the risk profile differs by function.
2. Check the region each sub-processor operates in, not just the primary provider's region; a US-based sub-processor can undermine an otherwise EU-resident setup.
3. Look for a retention period specific to each sub-processor, since a document can be deleted from the primary system while a log entry referencing it persists elsewhere.
4. Check whether the list is dated and versioned, since a static PDF published once and never updated is a sign the provider isn't actively maintaining it.

This is not legal advice, and residency is not a substitute for reading the actual notice

Everything above is general regulatory context intended to help a reader ask sharper questions, not a substitute for legal advice specific to a particular document, jurisdiction, or organisation — data protection law has enough jurisdiction-specific detail and enough case law refinement that a general article cannot responsibly tell any individual reader whether a specific transfer is lawful for their situation. What it can do is equip you to ask a provider the direct questions in the list above, read their answers against the frameworks described here, and treat vague or evasive answers about region, retention, or sub-processors as a warning sign in their own right, independent of whatever marketing language surrounds the product.