Cross-border data flows: why a booking in Bali touches five jurisdictions

5. The destination country (Indonesia). Indonesia's Personal Data Protection Law (UU PDP, passed 2022, enforcement phased through 2024) and sector-specific tourism data rules from the Ministry of Tourism govern data collected on Indonesian soil, including guest ID scans required at check-in under local hospitality regulation.

Five jurisdictions. One reservation. Zero centralized owner of the compliance question.

Why this isn't just a legal curiosity

For a data or operations professional, this matters for three concrete reasons.

Contradictory obligations can collide. GDPR requires a documented legal basis to transfer EU-linked personal data outside the European Economic Area (EEA), typically via Standard Contractual Clauses (SCCs) or an adequacy decision. Indonesia's UU PDP has its own cross-border transfer conditions. If the GDS in Singapore replicates guest data to a backup server in a sixth country, someone needs to have pre-cleared that transfer under both regimes, not just one.

Liability follows the weakest link, not the strongest brand. If Amadeus (GDS) suffers a breach exposing guest passport numbers, the French hotel group and the US OTA both face exposure, because GDPR and CCPA hold data controllers, not just processors, accountable for vendor failures. A 2023 case pattern seen across the EU: hotel groups have received regulatory inquiries for breaches that technically occurred at a third-party booking engine (see the European Data Protection Board's guidance on controller/processor liability).

Tourism-specific rules add a layer generic privacy law does not cover. Indonesia, Thailand, and several other destinations require hotels to log guest passport or ID data for police and immigration reporting. That is a mandatory local data collection duty sitting on top of, and sometimes in tension with, GDPR's data minimization principle (collect only what is strictly necessary).

Mapping the chain: a practical framework

Before a booking flow launches or a GDS contract renews, run a jurisdiction map. Four questions, one row per data-touching party:

| Party | Where is it incorporated? | Where is data stored/processed? | Which law attaches? |

|---|---|---|---|

| OTA | US / NL | US, EU, or regional cloud | CCPA, GDPR (if EU users) |

| GDS | Singapore | Singapore, possible mirrors | PDPA |

| Hotel parent | France | EU headquarters systems | GDPR (extraterritorial) |

| Property | Indonesia | Local PMS (property management system) | UU PDP, tourism ministry rules |

| Payment processor | Varies | PCI DSS scope, often multi-region | PCI DSS (industry standard, not law) plus local financial data rules |

This is not an academic exercise. It is the actual worksheet a Data Protection Officer (DPO) or compliance lead should complete for any new distribution partnership.

A simplified data flowdata flowAn automated sequence of steps that moves data from source to destination: ingestion, transformation, validation, and loading, so it arrives clean and ready to use.View full definition → check, in pseudocode

For teams building or auditing booking pipelines, the logic is close to this:

The point of formalizing this, even loosely, is that "we didn't know the GDS mirrored to a US server" is not a defense regulators accept.

Checks and audits worth running quarterly

A governance framework is only as good as the checks behind it. For hospitality data teams, four recurring audits matter most:

1. Vendor data map refresh. GDS providers and channel managers change server regions without always notifying clients. Re-confirm data residency annually in vendor contracts, not just at signing.

2. Retention audit against the strictest applicable rule. If GDPR says delete after contract purpose ends (typically interpreted as a defined retention schedule, often 3 to 7 years for financial records) but Indonesian immigration rules require ID retention for a fixed local period, the system needs field-level retention logic, not a single blanket policy.

3. Consent and legal basis trace. For EU-linked guests, confirm the booking flow captured a valid legal basis (contract necessity, not just "consent" buried in terms) as required under GDPR Article 6, per guidance from the European Data Protection Board.

4. Cross-border transfer documentation. Confirm SCCs or equivalent mechanisms exist for every processor step that crosses a border, and that the paperwork is retrievable, not just referenced in a master services agreement no one has re-read since signing.

None of these require a large legal team. They require a named owner, a recurring calendar entry, and a shared jurisdiction mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → that gets updated when vendors change infrastructure.

Key Takeaways

• A single booking can trigger multiple, sometimes conflicting, data laws (GDPR, PDPA, CCPA, local tourism rules) based on the traveler's residence, the OTA's base, the GDS processing location, the hotel parent's HQ, and the destination country.
• GDPR's extraterritorial reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition → means an EU-headquartered hotel group can be liable for data practices at a resort located entirely outside the EU.
• Liability typically follows the data controller (often the hotel brand or OTA), not just the processor (GDS, PMS vendor) where a breach technically occurs.
• Build and maintain a jurisdiction mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition →: for each vendor in the booking chain, document incorporation location, data storage location, and the specific law that attaches, then re-verify it at least annually.