Where Do Your China Backups Live? Cross-Border Data Transfer Compliance for a Foreign Entity's IT

The short version: "Where do our China backups live?" looks like a technical question and usually is not. Three things get mashed together — where the data sits, where the copies go, and how fast it comes back — and answering them separately is what turns an inherited default into an arrangement you can explain. Get your own counsel for the legal call.

Why does a China backup arrangement become a cross-border data transfer compliance question?

Backups are the least glamorous part of an IT estate, which is exactly why they get configured once and then inherited. Someone sets up a job, it turns green, and for the next four years nobody has a reason to look at it. That is fine almost everywhere. In a China entity it eventually stops being fine, not because the backup breaks, but because somebody asks a question about it that has nothing to do with whether it works — a cross-border data transfer compliance question that the IT team in China was never asked to prepare for.

The question tends to arrive from outside the China office. A group IT review, a new global data-governance policy, an enterprise customer's vendor questionnaire, or a change in the group's own risk register. And the question is rarely "is the backup running." It is "where does this data go, and who decided that was acceptable."

That is a genuinely different question, and it is one that a China entity of sixty to a hundred and twenty people frequently cannot answer — not out of negligence, but because the arrangement was never a decision. It was a default. The group has a regional cloud tenant, the China office was onboarded onto the group's standard, and a backup target was pointed at it because that was the path of least resistance at the time.

Brocent (founded 2007, headquartered in Singapore) has run mainland China delivery teams since 2007 and supports foreign-invested entities across the country. This pattern — an operationally sound backup that nobody can explain in governance terms — is one of the more common things we find when we take over a China environment.

One thing to establish immediately, because it shapes everything below: whether a specific data flow out of China is permitted, and under what mechanism, is a legal determination. It depends on what the data is, who it concerns, the volumes involved, and rules that have changed repeatedly and will change again. This article is about the operational shape of the problem and the practices that make it answerable. It is not legal advice, and your own counsel — not your IT provider — should make the compliance call.

The review that raised the question: a composite scenario

What follows is illustrative — a composite drawn from how foreign telecom and equipment vendors' China entities actually operate, not a named client.

A European telecom-infrastructure vendor with a China entity of about ninety people. The entity does not manufacture; it holds the regional spares inventory, runs field-service scheduling for engineers who go to carrier and enterprise customer sites across the country, and keeps engineering documentation, site survey records, and configuration files for the equipment deployed at those sites. There is a local file server, a handful of application servers, and roughly a hundred and ten endpoints.

The IT footprint locally is one person, who is genuinely capable and completely oversubscribed. The backup was configured five years ago by an engineer who has since left the company. It backs up the file server and the field-service database nightly to the group's regional cloud tenant, which is hosted in Singapore. It has never failed in a way anyone noticed. It has also never been restored from, other than one file-level recovery in 2023 that worked.

Then group IT circulates a revised data-governance standard, and one of its requirements is that each entity document where its operational data is stored and replicated, and identify any cross-border flows. The China IT lead reads it and realises he cannot fill in the form honestly. He knows the backup goes to Singapore. He does not know what is actually inside it beyond "the file server" — nobody has ever inventoried the contents. He does not know whether the customer site records and engineer scheduling data in there are the kind of thing the standard is worried about. And he does not know who at the company decided this was acceptable, because as far as he can tell nobody ever did.

He also, when he starts looking, finds two things he was not looking for. The nightly job has been silently skipping one of the application servers since a hostname change eleven months ago. And on the group's side, the restore path would run over the same cross-border link that is congested at exactly the times a real incident would occur.

What does an undocumented data path actually cost?

Note that only one of these is a compliance cost. The rest are ordinary operational risk that the same inattention produces.

There is no answer for group compliance, and the honest answer sounds worse than the reality. "We back up to Singapore and I am not sure what is in it" is a truthful statement that reads, to a governance reviewer, as an unmanaged risk. The gap between the actual risk and how the answer sounds is often large, and closing it is mostly documentation work rather than re-architecture.

Nobody has verified the backup restores. A backup job reporting success proves that data was written. It does not prove the data can be read back, that the application it belongs to will start against it, or that anyone knows the procedure. Silent failures are common and specifically hard to detect: the job that quietly stopped covering a server after a rename, the retention policy that aged out the only copy of something, the database backed up hot without the right consistency handling. None of these announce themselves.

The restore path depends on the worst-case network. If your only copy of a hundred-plus gigabytes of operational data is in another country, your recovery time is a function of the cross-border link on the day of the incident. That link is not at its best during a regional outage, and it is not at its best at the end of a quarter. A recovery time objective that was never actually calculated tends to be discovered, painfully, during the event it was supposed to cover.

In-China cloud behaves differently from what the team knows. This surprises people repeatedly. The major international clouds operate in mainland China only through mandatory licensed local operators — Azure China is operated by 21Vianet (VNET), AWS China regions by Sinnet and NWCD — as legally and technically separate environments from their global counterparts, with separate accounts, separate service catalogues and separate feature timelines. Hosting also brings the ICP filing requirement into scope for anything internet-facing. A group standard written against global Azure or global AWS does not transfer to China unchanged, and an engineer who assumes it does will build something that does not work the way the documentation says.

Nobody owns the question. The China office assumes group IT set the standard. Group IT assumes the China office knows local requirements. This is the most common failure mode of all, and it persists because both assumptions are individually reasonable.

Our view: separate the three questions people are mashing together

When this lands on our desk, the useful first move is not to redesign anything. It is to split one confused question into three clear ones, because they have different answers, different owners, and different urgency.

Where does the data live? This is about the primary copy — the file server, the application database, the systems people work in every day. For most China entities this is straightforwardly in China, and is not the part anyone is worried about.

Where do the copies go? This is the backup and replication question, and it is the one that turned into a governance issue in the scenario above. It has two halves that people conflate: what is being copied (which requires an actual inventory, not an assumption) and where each copy lands.

How fast does it come back? This is the recovery question, and it is purely operational — no legal dimension at all. It is also the one most likely to hurt you in practice, because it is the one an incident tests.

Answering these separately usually simplifies the problem rather than complicating it. In our experience, once a China entity actually inventories what is in the backup, the set of data that genuinely needs to leave the country turns out to be much smaller than the set that was leaving by default. A local backup with a tested restore, plus a narrow and documented set of what crosses the border and why, is both operationally better and considerably easier to defend than an undocumented "everything goes to the group tenant."

Three ways a China entity handles this

• Back up straight to the group's overseas tenant. Simple, consistent with the global standard, and requires no local decisions. But the contents are typically un-inventoried, the cross-border flow is a default rather than a documented decision, and the recovery time depends on an international link on the worst possible day. Defensible only if someone has actually looked at what is in it and can explain why that is appropriate.
• Local backup only, nothing leaves. Compliant-shaped and simple to explain, and it fixes the recovery-time problem entirely. Its weakness is real, though: a single site with no geographic separation is not a disaster recovery position. A fire, a flood or a ransomware event that reaches the backup target takes both copies. This is a common over-correction by entities that got frightened by the compliance question and solved it by removing the second site.
• In-China backup with a tested restore, plus a documented transfer set. The primary backup target sits in China with an RTO and RPO agreed with the business rather than inherited. Recovery drills produce dated evidence that restores actually work. Geographic separation is achieved within China. And a narrow, explicitly listed set of data crosses the border for genuine group purposes, with a written rationale someone signed. More work up front, and the only one of the three that answers both the compliance question and the recovery question.

What does a defensible China backup practice actually include?

The specifics matter more than the architecture diagram. Here is what we think has to be present.

An RTO and RPO agreed with the business, not inherited. Recovery time objective and recovery point objective are the two numbers everything else follows from, and in most inherited setups nobody can tell you what they are. They should not be chosen by IT alone — the question "how long can field-service scheduling be down before it costs us customer commitments" is a business question, and the answer differs sharply between the file server and the spares system. Brocent's cloud managed backup starts here rather than with tooling, because the local and cloud retention policies, the target selection and the architecture are all downstream of those two numbers.

Monitoring, so a silent failure surfaces the same week. The eleven-month gap in the scenario above is the normal outcome of unmonitored backup jobs, not an unusual one. Backup job monitoring needs to be someone's actual responsibility with alerting on failure, not a dashboard that a busy person is expected to remember to open. On a managed plan this runs 24×7 through our service control and network operations teams with immediate alerting when a job fails, which is the difference between discovering a gap in a week and discovering it during a recovery.

A recovery drill that produces a dated result. This is the practice most commonly skipped, and it is the only one that actually proves anything. A periodic recovery drill restores real data into an authorised test environment, verifies that it is intact and usable, and produces a drill report documenting what recovered successfully and what did not. The report is the point. It converts "we have backups" from a belief into an artifact, which is exactly what both a group governance reviewer and your own management want to see. Drills also surface the unglamorous failures that monitoring misses: the application that will not start against a restored database, the missing service account, the undocumented step that only the departed engineer knew.

Knowing which China cloud you are actually on, and who operates it. If you are hosting in mainland China, be precise about what you are hosting on. The international clouds run through licensed local operators as separate environments — Azure China via 21Vianet/VNET, AWS China via Sinnet/NWCD — alongside domestic providers and carrier-neutral operators. Contracts, support paths, available services and feature parity all differ from the global versions. Managed cloud services for a China entity means knowing these differences before you design against them, not discovering them during implementation. It also means the ICP filing question gets asked at design time rather than at launch.

An inventory of what is replicated where. The document that ends the governance conversation is not an architecture diagram. It is a list: these datasets, from these systems, are copied to these targets, on this schedule, retained for this long, for this reason. Producing it is tedious and usually takes a couple of days. It is also the single highest-value artifact in this whole exercise, because it is what lets somebody make an informed decision about the cross-border set instead of leaving it as a default. Where the datasets include material with security or confidentiality obligations, that inventory feeds directly into how those controls are applied — which is where managed IT security services and the backup design stop being separate conversations.

Where does this sit next to your group's global standard?

The instinct at group level is usually to apply one standard everywhere, and that instinct is correct in spirit. The mistake is applying it as one implementation everywhere.

A workable pattern is to keep the standard at the level of outcomes — every entity has a documented RTO and RPO, monitored jobs, a tested restore, and an inventory of replicated data — while allowing the implementation to differ where the local environment genuinely differs. China is the clearest case of this, but it is not unique; the same logic applies wherever a local hosting or regulatory reality diverges from headquarters' assumptions.

That framing also resolves the ownership question. Group IT owns the standard and the outcomes. The China entity owns the implementation and the evidence. Neither of them owns the legal determination about cross-border transfer — that belongs to counsel, informed by the inventory the IT side produced. Brocent has supported telecom-sector clients including a global telecom infrastructure provider across sixty-eight countries, and in multi-country arrangements this division of responsibility is consistently the one that works: a common standard, locally correct implementations, and a legal call made by people qualified to make it.

Frequently asked questions

Is backing up a China office to an overseas cloud automatically a problem?

No, and anyone telling you it is automatically fine or automatically prohibited is oversimplifying. Whether a particular flow is permitted, and under what mechanism, depends on what the data is, whom it concerns, the volumes, and rules that have changed repeatedly. That is a determination for your own legal counsel, not for your IT provider. What we can tell you is that the practical prerequisite for getting a real answer is an inventory of what is actually in the backup — most entities cannot get a legal opinion because they cannot describe the data.

What is the difference between backup and disaster recovery here?

Backup is copies of data. Disaster recovery is the ability to run the business again within an agreed time. You can have excellent backups and no disaster recovery position — that is exactly what a single local backup target with no second site gives you, and it is also what an overseas-only copy with a slow cross-border restore path gives you. The bridging concepts are the recovery time and recovery point objectives, plus a business contingency plan that documents the actual sequence someone would follow. Backups without that plan are data, not recovery.

How often should a restore actually be tested?

At least annually as a floor, and after any material change — a new application, a server migration, a change of backup target, or a change of the person who runs it. The test needs to be a real restore into an authorised environment, not a verification that the backup file opens. And it needs to produce a dated report, because an untested claim and an undocumented test are worth about the same to a reviewer.

Which cloud providers can legally host this data in China?

The available options include the domestic providers, carrier-neutral operators, and the international clouds through their mandatory licensed local operators — Azure China through 21Vianet/VNET, AWS China through Sinnet and NWCD. Which of these is appropriate for your particular data is a question that combines your legal position with technical requirements, and the legal half is not ours to answer. What we would flag operationally is that these environments are genuinely separate from their global counterparts in accounts, service catalogue and feature timing, so a design validated against global Azure or AWS needs re-validating rather than porting.

What happens to our China data if we close the entity?

Plan this before you need it, because entity closure has a data dimension that is easy to leave until last and difficult to fix late. The practical questions are: what has to be retained and for how long, where it can be retained, what has to be destroyed and with what evidence, and who holds the credentials to whatever survives. On a managed plan, environment documentation and credentials belong to the customer, which matters more at exit than at any other point in the relationship. The retention and destruction obligations themselves are, again, a legal question.

Who owns this question — the China office or group IT?

Split it. Group IT should own the standard and the required outcomes. The China entity should own the implementation and produce the evidence. Legal or compliance should own the determination about what may cross the border, informed by the inventory. The failure mode we see most often is neither side owning it because each assumes the other has, and the fix is administrative rather than technical: write down who owns which of the three, and give the inventory a due date.

We are a small China team. Is a proper backup practice realistic for us?

Yes, and the size argument usually cuts the other way. A ninety-person entity with one IT person is precisely the situation where monitoring, drills and documentation do not happen without help, because that person's week is fully consumed by things that are on fire. The practical route is to make the recurring parts — job monitoring, the drill, the annual documentation refresh — someone's contracted responsibility rather than an intention. That is what managed IT support is for at this size: not replacing your IT lead, but taking the work that reliably gets deferred. The homepage quote tool prices the Cloud Backup per-device add-on alongside the per-user plan for a mainland China office, so you can see what those recurring parts cost before you talk to anyone.

Next steps

If you cannot currently say what is inside your China backup or when it was last restored, that is a solvable problem and a good place to start. Get in touch and we will help you produce the inventory and a tested restore — and be clear about where our part ends and your counsel's begins.