Data Sovereignty and Residency: Moving Your CDE Data Where Compliance Requires
For a growing number of infrastructure projects, you no longer get to store project data wherever the platform happened to default to. A government client, a defence contract, or a critical infrastructure obligation says the 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 answers where the data physically sits. It is satisfied by a data centre in the required country.
Data sovereignty answers whose laws apply and who can compel access. It is satisfied by the ownership, control and legal reach of the provider, not by location alone.
Data localisation answers whether the data is allowed to leave. It is satisfied by a prohibition on transfer that covers every copy.
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. This is precisely the distinction the Commonwealth drew when it built sovereignty requirements around ownership and control rather than geography alone.
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, and they extend to your supply chain, not just your own systems.
The Hosting Certification Framework governs how Australian Government data, including PROTECTED, can be hosted. It has applied to new contracts and contract extensions since 30 June 2022, and functional responsibility now sits with the Department of Home Affairs. Its two certification tiers turn on ownership and control, not location: Certified Strategic is only available to providers that let government specify ownership and control conditions, while Certified Assured provides safeguards against changes to ownership or operations. Providers relying on offshore remote-in support have historically struggled to qualify for either.
Defence and whole-of-government contracts routinely carry geographic restrictions right down to the nominated data centre.
APRA's CPS 234 and CPS 230. CPS 234 has required regulated entities to secure information assets managed by third parties since 2019. CPS 230 came into force on 1 July 2025 and goes further, requiring entities to identify material service providers, understand their supply chains, and maintain continuity across them. Transitional relief for some pre-existing service provider arrangements ran to 1 July 2026, so that grace period has now closed.
State policy. New South Wales, Victoria and Queensland each have policies that keep sensitive government data inside the state or the country.
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 for health and government records. 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. The usual culprits:
Content delivery networks caching content at edge nodes offshore
Cross-region disaster recovery and backup replication
Vendor support staff accessing tenant data from an offshore service desk
AI and analytics pipelines processing content in a different region to where it is stored
Third-party integrations and connectors that route data through their own infrastructure
Sandbox, staging and demonstration environments cloned from production
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.
Two things make this hard to unwind:
Region is set at creation, not in settings. On most platforms the hub, instance or datasource region is fixed when the container is created. There is no toggle. Correcting it means creating a new container in the right region and moving the data across.
The supply chain multiplies the problem. A joint venture with three design consultants and a head contractor may be running four CDEs across three regions. The onshore obligation applies to all of them, not just yours. If you are already syncing between those platforms, every endpoint in the chain needs to be in a compliant 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, and it will surface on their next audit rather than yours.
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.
It also matters that metadata survives the move in a form your standard recognises. An ISO 19650 information container that arrives in the new region without its status codes, revision codes or suitability is not a compliant record, whichever jurisdiction it now sits in.
Native platform tooling rarely clears this bar. Autodesk's own utilities, for example, do not carry version history across hubs, which is a problem when the history is the thing the regulator wants to see. And a migration is only finished when you can prove the record came across, not when the files appear in the destination.
Seven questions to ask across your data supply chain
Before you sign off on a residency position, get written answers to these. Not all of them are vendor questions, which is part of the point.
Which region is each hub, instance or datasource actually provisioned in, and can you evidence it? Ask whoever owns the tenancy, which may not be you.
Where do backups and disaster recovery replicas live?
Can support personnel access tenant data from outside the required jurisdiction?
Is the provider subject to foreign legal process that could compel disclosure?
Where does any AI or analytics processing of project content occur, including any vendor-native AI features?
Which integrations and connectors touch the data, and where does each one process it? Every integration provider answers this separately.
Where will the data sit after handover, and who owns the tenancy then? This one sits in your contract, not with your CDE vendor.
If nobody in the chain can answer all seven, you do not yet have a sovereignty position. You have a residency setting.
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.
Where platforms need to stay live in different regions during transition, CDE Sync keeps them aligned without creating a persistent copy anywhere it should not be. The platform does not retain your project files. It streams data between environments rather than storing it, so the migration itself does not leave another copy sitting in the wrong place.
Utopia Digital is SOC 2 Type II certified across Security, Availability and Confidentiality. You can see where our infrastructure runs on the Global Data Region Map, and review our controls, sub-processors and certifications in the Security Trust Portal.
If you are still weighing options, our comparison of CDE integration approaches sets out how the available tools handle security certification, platform coverage and domain logic.
Need your project data moved onshore, or into a specific region, without losing the record? Talk to us or email info@utopiadigital.io.
