Data Sovereignty and Residency: Moving Your CDE Data Where Compliance Requires
For a growing number of infrastructure projects, you no longer get to store your data wherever the platform happens to default to. A government client, a defence contract, or a critical infrastructure obligation says the project data has to be held in-country and under local control. More often than not, the CDE it currently sits in was set up in a region nobody checked against those rules.
That leaves you with a problem that is part compliance and part migration at the same time. The data is in the wrong place, and getting it to the right place without breaking it is harder than it looks.
Residency, sovereignty and localisation are not the same thing
These three terms get used interchangeably, and the difference matters the moment a client asks you to prove compliance.
Data residency is about where your data physically sits. A residency rule says the data must be held in a particular country.
Data sovereignty is about which laws your data is subject to because of where it sits, and who can compel access to it. Data can be resident in Australia and still fall under a foreign jurisdiction if the provider is foreign-owned.
Data localisation is the requirement that the data stay put.
The trap is assuming that picking an "Australian region" satisfies sovereignty. On its own, it does not. If a foreign-owned provider can still be compelled to hand the data over, residency alone has not solved the problem.
Why this is now a requirement, not a preference
If you deliver infrastructure for the public sector or a regulated industry, you will hit at least one of these:
The Security of Critical Infrastructure (SOCI) Act covers eleven critical sectors, and data storage and processing is itself one of them. Its risk-management obligations are widely read as requiring data to be held and controlled onshore.
The Hosting Certification Framework governs how Australian Government data, up to PROTECTED, can be hosted, with explicit requirements on sovereignty, ownership and supply chain.
Defence and whole-of-government contracts routinely carry geographic restrictions right down to the data centre.
APRA's CPS 234 and CPS 230 require regulated entities to control where their data lives across the whole supply chain, including the cloud.
New South Wales, Victoria and Queensland each have policies that keep sensitive government data inside the state.
The same pattern holds in the other markets infrastructure work spans. The UK has its own rules for government data, the EU and UK control cross-border transfer under GDPR, and several Canadian provinces have public-sector residency laws. The specifics differ. The direction of travel does not.
"In-region" does not mean "compliant"
Even once your CDE is set to the right region, the data can still leave it without anyone noticing. Content delivery networks, cross-region disaster recovery, backups and AI pipelines can all move copies offshore. So can a CDE that replicates across regions by default.
Compliance cares about every copy, not just the primary one. You have to know where the data and all of its copies actually live, which is exactly the kind of thing that gets missed when a platform was set up years ago without the question being asked.
Where CDEs trip you up
Your project data almost always lives in a vendor CDE: an Autodesk hub, an Aconex instance, a ProjectWise datasource, a SharePoint site. Each of those is tied to a region chosen at setup, often the vendor's default, and very often that default is offshore. The decision was usually made before anyone checked the compliance position, because at the time it was just where the project happened to start.
Then a critical infrastructure client or a regulator requires the data onshore, and you find you cannot simply change a setting. The data has to be migrated to a hub or instance in the correct region.
It is worse at handover. When a project closes, the asset owner inherits whatever region you left the data in. If that is the wrong jurisdiction, you have handed a regulated owner a compliance problem attached to the permanent record of their asset.
Moving regions without breaking the record
A residency migration is still a migration, and the same rule applies: moving the files is easy, moving the record is the hard part. Version history, metadata and the audit trail have to come across intact.
That is doubly true here, because an auditable, traceable, access-controlled record is itself part of what the sovereignty rules require. A residency migration that drops the history fails twice over. It loses the record, and it leaves you short of the very compliance you were trying to meet.
How CDE Migrate handles it
CDE Migrate moves project data into the region compliance requires, across Autodesk, Aconex, ProjectWise and SharePoint, with version history, metadata and the audit trail preserved. Every migration is scoped, audited before it runs, executed to the correct region, then validated against the agreed scope with a completion report and audit trail you can put in front of a client or an assessor.
It also helps that the platform does not retain your project files. CDE Sync streams data between environments rather than storing it, so the migration itself does not leave another copy sitting in the wrong place.
Need your project data moved onshore, or into a specific region, without losing the record? Talk to us at info@utopiadigital.io.
