Cross-Border Transfer
The legal mechanism that permits data to leave, and the architecture that respects it.
4 to work through
-
intermediate Multiple choice
An EU-based SaaS product runs entirely in Frankfurt. Its 24-hour support rota includes engineers in a country without an adequacy decision, who can view customer records to diagnose issues. Legal flags this as a cross-border transfer. Which control best addresses the finding?
3 min answer -
advanced Multiple choice
A collaboration platform must move some personal data between jurisdictions. What mechanisms exist and how does architecture support them?
1 min answer -
advanced
A platform must move personal data between jurisdictions. What does the architecture need to support, beyond the legal mechanism?
2 min answer -
advanced
Your SaaS vendor processes EU customer data in the US. Legal asks for supplementary measures. What can architecture offer?
2 min answer
4 terms in this topic
Access Geography
The recognition that viewing data from another jurisdiction is a cross-border transfer, which makes access control and the location of the people usi…
conceptCross-Border Transfer Mechanism
The legal basis required to move personal data from one jurisdiction to another, and the architectural evidence needed to support it.
conceptTransfer Mechanism
The specific legal instrument permitting personal data to leave a jurisdiction, which must exist per flow and which architecture must make identifiable.
conceptUnintentional Transfer
Personal data crossing a jurisdictional boundary through a path nobody classified as a transfer - telemetry, support access, backups, or a processor'…
Neighbouring topics
Regulatory & Data Protection Architecture
General material on designing under legal and regulatory obligation.
Privacy by Design
Data minimisation, default protection and purpose binding as structural decisions.
Lawful Basis & Purpose Limitation
Why you may hold the data, and why that forbids the second use somebody proposed.
Data Subject Rights
Access, correction, portability and erasure across systems that never planned for them.
Consent Architecture
Capturing, versioning and propagating consent to every system that acts on the data.
Data Residency
Keeping data within a jurisdiction, including backups, logs and support access.
Digital Sovereignty
Control over data, operations and the operator, beyond where the bytes physically sit.
PCI-DSS Scoping
Segmentation and tokenisation to shrink what is in scope, because scope is the cost.
Healthcare Data Protection
PHI handling, minimum necessary access, and audit expectations in clinical systems.
Financial Services Regulation
Operational resilience, payment rules and supervisory expectations as design inputs.
Records Retention & Legal Hold
Keeping what must be kept, deleting what must go, and freezing both on demand.
Erasure vs Immutability
Deletion obligations against event logs, backups and ledgers designed never to forget.
Pseudonymisation
Separating identity from record, and the re-identification risk that remains.
Privacy-Enhancing Technologies
Differential privacy, secure enclaves and federated computation, and what each buys.
Regulatory Reporting Pipelines
Submissions with fixed deadlines, fixed formats, and a regulator who audits the lineage.
Sector Cloud Rules
Regulator expectations for cloud use, exit plans and material outsourcing notification.
Exit & Concentration Risk
Being able to leave a provider, and what the regulator asks when you cannot.
Third-Party Risk
Assessing, contracting and monitoring the vendors your architecture now depends on.
Geo-Restriction & Sanctions
Blocking access by jurisdiction, and the accuracy and evasion problems that come with it.