Cross-border data transfer record / inventory

Description

A cross-border data transfer record is the operational inventory that sits underneath the mechanism program. The mechanism program (the companion control `cross-border-transfer-mechanism`) answers the legal question per flow: which approved path covers this transfer. The transfer record answers the operational question: what flows actually exist. The pair is genuinely inseparable. A flow without a mechanism is the supervisory-authority finding; a mechanism asserted against a flow that nobody can produce is the suspicious answer to a regulator inquiry. The inventory itself carries six fields per row that supervisory authorities have converged on asking for. Source jurisdiction and recipient jurisdiction (which together establish whether the transfer is even cross-border under the relevant regulation). The recipient organization, by legal entity, because intra-group transfers under Binding Corporate Rules are treated differently from third-party transfers under SCCs. The category of personal data (customer identifiers, employee records, special-category data, payment data) because the safeguard expectation scales with sensitivity. The data subjects affected (customers in Region X, employees, end-users). Retention applied at the recipient, because the supervisory authority cares about onward processing, not just initial transfer. And the executed transfer mechanism with its supporting documentation attached. The Records of Processing Activities duty under GDPR Article 30 (and UK GDPR Article 30 retained, and the equivalent in LGPD Article 37) is where the inventory becomes regulator-facing. EDPB, ICO, CNIL, and ANPD have all referenced ROPA records directly in inquiries. The practical pattern is to maintain the transfer inventory as a subset of the broader ROPA system rather than as a parallel spreadsheet, so the auto-discovery vendors (OneTrust Data Mapping, Transcend Inventory, Osano vendor monitoring) populate both surfaces from the same SaaS-integration scan. The hard part is not building the inventory; it is keeping it current as procurement adds new processors faster than privacy operations can document them.

Required by (3 regulations)

• GDPR

  Article 30 — records of processing activities must capture transfers to third countries including documentation of suitable safeguards under Articles 46 or 49.

  GDPR Art. 30

• UK GDPR

  Article 30 (UK GDPR retained) — equivalent records-of-processing duty for UK controllers; ICO inquiries reference these directly.

  UK GDPR Art. 30

• China CIIPA

  China CIIPA and related rules require security assessment and recordkeeping for cross-border transfers of important data.

  Regulations on the Security Protection of Critical Information Infrastructure (State Council Order No. 745); implementing Cybersecurity Law Articles 31-39

  Source →

Fulfilled by (4)

• onetrust · full · medium effort · $$$
  OneTrust Data Mapping module auto-discovers third-party data flows + generates Article 30 records.
• osano · partial · low effort · $$
  Osano vendor monitoring + data flow assessment; pair with manual SCC tracking for full coverage.
• transcend · partial · medium effort · $$$
  Transcend Inventory module — automated data flow discovery + per-system data subject category mapping.
• In-house build · high effort
  Maintain in a vendor-management system or spreadsheet; pair with Records of Processing Activities (ROPA) workflow under GDPR Art 30.

Magist does not accept payment from vendors. Methodology.

Evidence formats

• transfer inventory spreadsheet / system
• Records of Processing Activities (GDPR Art 30) export
• processor risk-assessment per recipient
• retention schedule per data category