Transfer Mechanism
The specific legal instrument permitting personal data to leave a jurisdiction, which must exist per flow and which architecture must make identifiable.
Cross-border transfer of personal data is generally prohibited unless a recognised mechanism applies: an adequacy decision covering the destination, standard contractual clauses with a transfer risk assessment, binding corporate rules within a group, or a narrow derogation.
The architectural obligation is to know which flows exist. That means a data flow diagram in which every arrow crossing a border is identified, with the mechanism recorded against it and the categories of data it carries. Without it, the organisation cannot answer a regulator's question and cannot assess the impact when a mechanism is invalidated — which has happened, and produced a scramble in organisations that did not know their own flows.
Two things are consistently overlooked. Remote access is a transfer: an administrator in another country connecting to a database has transferred nothing physically and has transferred the data legally. And sub-processors: a vendor may be in an adequate jurisdiction while its own subcontractor is not, so the assessment follows the chain rather than stopping at the contract.
The design lever is minimisation at the border. Pseudonymising or aggregating before a transfer can materially reduce what is in scope, and is far cheaper than restructuring the flow later.