Data Localisation Requirements: What a Foreign-Owned Entity Actually Has to Do

Whether a given data flow triggers a localisation or cross-border transfer obligation depends on classification questions most entities have not actually worked through: what category the data falls into, what volume threshold applies, and whether the entity's own processing counts as the kind of activity the rules are aimed at. None of those questions can be answered in the abstract — each depends on what the entity's own systems actually do, not on a general description of the regulatory area.

Classification comes before compliance, not alongside it

A localisation or cross-border transfer obligation is triggered by the nature and volume of specific data, not by the fact that an entity is foreign-owned or that it operates internationally. Two entities with similar headcounts and similar revenue can sit on opposite sides of an obligation depending entirely on what categories of data they actually hold and how much of it moves across a border in a given period. Treating "we are a foreign-owned entity, so this probably applies to us" as the starting analysis skips the step that actually determines the answer, which is a data-level classification exercise, not an entity-level one.

Where entities usually discover a gap

In practice, the gap rarely shows up in a formal audit. It surfaces when a routine vendor relationship — a cloud analytics tool, a customer support platform headquartered abroad, a payroll processor whose servers sit in a different jurisdiction than anyone assumed — turns out to route data in a way nobody had mapped, because the relationship predates any deliberate compliance review. The vendor was selected for its product, not audited for its data architecture, and the question of where the data actually goes was never asked at onboarding because nobody thought to ask it.

Building the inventory: what it actually involves

A data flow inventory is less a legal exercise than an operational one at the outset — it starts with a systematic list of every system, vendor, and integration that touches the entity's data, and for each one, where that data is actually processed and stored, not where the vendor's marketing materials say it is. In practice this means pulling together IT, HR, finance, and any customer-facing systems into one conversation, since data localisation questions rarely respect departmental boundaries — a customer support platform chosen by one team and a payroll system chosen by another can each independently create an obligation nobody has looked at together.

Volume and category, not intent, drive the obligation

An entity that never intended to move sensitive data across a border can still trigger an obligation simply because the categories of data it holds and the volume it processes happen to cross the relevant thresholds — intent is not a defence, and "we didn't realise" is a description of the gap, not an exception to it. This is why the inventory step above has to be genuinely comprehensive rather than focused only on the data flows an entity assumes are sensitive; the categories that actually matter are defined by the regulatory framework, not by the entity's own instinct about what feels sensitive.

Who should own the inventory once it exists

An inventory that is built once and then filed away loses most of its value within a year, since new vendors and systems are added continuously and each one is a potential new data flow. The entities that keep this genuinely current are the ones that assign clear ownership — someone whose job includes asking the data-flow question whenever a new vendor contract is signed, rather than leaving it to whichever team happens to remember. Where that ownership sits will vary by entity size, but the failure mode is consistent: an inventory with no owner drifts out of date exactly as fast as the entity's vendor relationships change.

A practical sequence for getting ahead of the question

• Inventory every system and vendor that touches the entity's data, including ones chosen by teams outside compliance or IT.
• For each one, establish where the data is actually processed and stored, not where the vendor's marketing describes it as being.
• Classify the data categories involved against the entity's actual regulatory exposure, rather than assuming foreign ownership alone determines it.
• Flag any vendor relationship where the answer is unclear, and treat that uncertainty as a priority to resolve rather than a detail to revisit later.
• Revisit the inventory when a new vendor or system is introduced, rather than treating it as a one-time exercise.

A practical starting point is a data flow inventory conducted before a specific transfer becomes urgent, not after. This is general commentary on a developing regulatory area and does not constitute legal advice; specific classification questions should go to counsel familiar with the entity's actual systems.