A collaboration platform must move some personal data between jurisdictions. What mechanisms exist and how does architecture support them?

Why encryption alone is not enough

Encryption in transit protects against interception. It does not address the question the rules are concerned with, which is whether the receiving jurisdiction provides adequate protection and whether the recipient can be compelled to disclose. A transfer is a legal event, not a network event.

What is actually required

• A transfer mechanism: an adequacy determination for the destination, contractual clauses, or binding corporate rules for intra-group transfers.
• An assessment of whether the destination's legal environment undermines that mechanism, documented, and revisited when circumstances change.
• Supplementary technical measures where the assessment identifies risk — encryption with keys held in the origin jurisdiction, pseudonymisation, or splitting data so no single location holds an identifiable set.

What architecture contributes

• Minimising what crosses. The strongest position is transferring less: aggregate before transfer, pseudonymise, or keep identifiers in-region and transfer only behavioural data keyed by pseudonym.
• Keys held in the origin jurisdiction, so the recipient holds ciphertext it cannot unilaterally read.
• A record of what data flows where, maintained and accurate. Most organisations cannot produce this, and it is the first thing an assessment requires.
• Enforcement in the routing layer, so a transfer that has not been assessed cannot happen by a configuration change.

The operational trap

Transfers that nobody classified as transfers: a support engineer accessing data from another region, telemetry flowing to a central observability platform, a backup replicated to a global bucket, a third-party processor with staff elsewhere. The unintentional flows are more common than the deliberate ones, and they are what audits find.