China's Cybersecurity Law: Localization Becomes Mandatory

China's Cybersecurity Law was adopted on 7 November 2016 and took effect the following June. For multinationals with operations in the country, it marked the point at which data localisation stopped being a European policy debate and became an operating constraint with a compliance deadline. The law's most consequential provision required operators of critical information infrastructure to store personal information and important data collected in China within China, and to pass a security assessment before transferring it abroad. Around that sat network security obligations, real-name registration requirements, incident reporting duties, and a multi-level protection scheme that graded systems by sensitivity and attached controls accordingly. What made it genuinely difficult was not the localisation requirement itself — that is an engineering problem with a known cost. It was the deliberate imprecision of the definitions. "Critical information infrastructure" was described by sector and by consequence rather than enumerated, and "important data" was left to be specified later, sector by sector. Companies had to decide whether they were in scope without a definitive answer, and the cautious reading and the commercially convenient reading were very far apart. That ambiguity has narrowed since — subsequent legislation on data security and personal information protection, formal transfer mechanisms, and sectoral catalogues of important data have filled much of the gap — but the architectural decisions forced in that period are the ones that still shape how multinationals operate there.

The architecture problem

The standard multinational technology model is a single global instance of each major system. One ERP, one CRM, one HR platform, one data warehouse, one identity provider, consolidated reporting from a single source. That model is cheaper, more consistent and easier to govern — and it is incompatible with a strict localisation requirement. Organisations faced three options, each with real consequences. A separate in-country instance. A China deployment of the core systems, hosted domestically, operated locally, with defined and assessed interfaces to the global estate. This satisfies the requirement most cleanly and is by far the most expensive: duplicated licences, duplicated infrastructure, duplicated administration, and a permanent divergence in configuration as the two instances drift apart over years of independent change. A hybrid split. Operational and personal data stays local; aggregated, anonymised or non-personal information flows out for group reporting. Cheaper, but it requires genuine discipline about what is personal and what is aggregated, and the boundary is harder to police than it looks — a detailed enough aggregate can be personal data again. Operational restructuring. Reducing what the China entity does, using a local partner or distributor, or accepting a lower degree of integration with the group. This came up more often than vendors like to acknowledge, and for some businesses it was the rational answer. Whichever path, the entity that thought it was running a branch of a global system discovered it was running a separate business with its own technology stack, its own support model and its own audit trail.

The wider lesson

China was early and strict, not unique. The decade since has produced localisation, residency or transfer-restriction requirements across Russia, India, Indonesia, Vietnam, Saudi Arabia, the UAE, Brazil and the European Union, each with different scope, different mechanisms and different triggers. The number of jurisdictions imposing conditions on where data sits and how it moves has grown steadily, and the direction is not reversing. The practical consequence for system architecture is that jurisdictional boundaries are now a first-class design constraint, on the same footing as availability and performance. A global system designed on the assumption that data can move freely is a system that will need re-architecting every time a market changes its rules. A system designed so that a country's data can be isolated, hosted locally and operated separately without rebuilding the application is a system that can absorb regulatory change at manageable cost. That capability — partitionability — is cheap to design in and extremely expensive to retrofit. It is the single most useful thing a technology leader can take from the localisation decade.

Practical Guidance for China Compliance Assessment

• Establish scope with local counsel before designing anything. Whether you are a critical information infrastructure operator, and what counts as important data in your sector, determine the entire cost of compliance.
• Map data flows at field level, not system level. "The CRM syncs to the group warehouse" is not an answer; which fields, how often, and under which lawful basis is.
• Use the formal transfer mechanisms rather than assuming exemptions. Security assessment, standard contract filing and certification routes exist and have defined thresholds; an undocumented transfer is the exposure.
• Cost the full duplication before committing to a local instance. Licences, infrastructure, local administration, separate support, separate testing, and the permanent divergence cost that nobody budgets.
• Decide who administers the local environment. Remote administration from outside the country can itself constitute access to localised data, which surprises organisations that thought hosting location was the only issue.
• Separate the HR and employee data question from the customer data question. Employee personal information frequently triggers obligations earlier and is easier to overlook because it sits in a global HR platform.
• Design for partitionability across the whole estate, not just China. The next requirement will come from another market, and the capability transfers.
• Re-assess on a schedule. Definitions, catalogues and thresholds in this area have changed repeatedly, and a compliance position from three years ago is probably out of date.

The Regional Dimension

Gulf organisations sit on both sides of this question, which is an unusual and useful position. As subjects of localisation, the region has moved in a broadly similar direction with a different emphasis. Saudi Arabia's personal data protection regime and its cloud computing regulatory framework, UAE federal data protection legislation alongside sector rules from financial and health regulators, and the separate regimes operating in DIFC and ADGM together create a layered environment where the applicable rule depends on the emirate, the free zone and the sector. Government, financial services, healthcare and telecommunications carry the strictest expectations. A regional group therefore faces its own internal version of the multinational problem: the same system may be subject to different residency rules in different entities of the same organisation, and the DIFC or ADGM entity may operate under a framework closer to European practice than to the mainland regime next door. As originators of cross-border data flows, regional groups increasingly consolidate finance, HR and IT shared services into Dubai, Riyadh or Cairo, serving entities across the Gulf, the Levant, Africa and South Asia. Every one of those service relationships is a cross-border transfer with its own legal basis, and the shared service model — which is economically compelling — quietly creates a transfer map that few groups have ever documented. The China experience is directly relevant here: the moment one served country imposes a localisation requirement, the centralised model breaks unless the architecture can partition that country's data. Three specific points for regional groups trading with China. First, the flow is substantial and growing, and it is not only about customer data: joint ventures, engineering partnerships, construction supply chains and energy trading all generate data with a Chinese nexus. Second, technology procurement from Chinese vendors is common across the region in telecommunications, surveillance, smart city infrastructure and increasingly cloud and AI services, which puts the same questions in reverse — where does the data from those systems go, who can access it, and under which jurisdiction's law. Third, groups operating across Gulf, European and Chinese jurisdictions simultaneously are subject to several transfer regimes that do not align with each other, and the workable approach is to design to the strictest applicable constraint rather than to attempt a per-jurisdiction optimisation that nobody can maintain.

The objection worth taking seriously

The substantive criticism of localisation, made consistently by economists and trade bodies, is that it imposes large costs while delivering questionable security benefits. Data stored locally is not inherently more secure. It is secure if it is well protected, and a poorly run domestic data centre is worse than a well-run foreign one. Meanwhile the costs are real and measurable: duplicated infrastructure, fragmented analytics, higher prices from a constrained supplier market, delayed access to new capabilities, and a compliance function that grows with each jurisdiction. Those costs fall disproportionately on smaller companies, which is why localisation tends to entrench incumbents — a multinational can afford a China instance, and a mid-sized exporter often cannot, so the rule functions as a market access barrier whatever its stated purpose. There is also a candid point about motivation. Localisation requirements serve several goals at once: genuine security and privacy protection, domestic industry development, and state access to data held within the jurisdiction. These are not the same objective, and a requirement justified on privacy grounds may principally deliver the third. Organisations should understand which of these they are complying with, because it affects what their compliance actually protects — keeping data local may satisfy a regulator while increasing, not decreasing, its accessibility to that regulator. The balanced position: treat localisation as a market access cost to be engineered efficiently rather than a security control to be celebrated, build the partitioning capability once so that each new jurisdiction is incremental, and be honest internally about which requirements protect your customers and which protect somebody else's interests.

Common Questions

Does the requirement apply to every company operating in China?

No. The strictest localisation obligations attach to critical information infrastructure operators, with broader personal information rules applying more generally under later legislation. Scope determination is the first and most consequential piece of work, and it requires local legal advice rather than a policy reading.

Can we keep a single global system and just restrict access?

Usually not, where localisation applies. If the data is stored outside the country, access controls do not cure the storage location. Where the obligation is a transfer restriction rather than a storage requirement, a documented transfer mechanism may permit it — which is why distinguishing the two is essential.

What is the most commonly missed exposure?

Employee data in global HR, payroll and collaboration platforms, and administrative access from outside the country to locally hosted systems. Both are invisible in a data map drawn around customer-facing applications.

How does AI complicate localisation?

Significantly, because it creates copies that traditional data maps do not track. Content sent to a model endpoint may be processed and logged in another jurisdiction; embeddings and vector indexes are derived representations of the source data and live wherever the index lives; fine-tuned weights encode training data in a form that cannot be selectively deleted. A company that carefully localised its database and then enabled an AI feature that calls a foreign endpoint has moved the data it spent a programme keeping local. Several jurisdictions now regulate cross-border AI processing explicitly, and the questions to put to any vendor are specific: where does inference run, what is retained and for how long, where do embeddings sit, is customer content used for training, and which legal entity operates the endpoint. Add model and index location to the data map, because the regulators already have.

---

China Compliance Assessment — scope first, then architecture; design systems so any one country's data can be partitioned, because the next requirement will come from somewhere else.