07. CDE Backup: Holding an Independent Copy of Your Project Record
A CDE backup is a maintained second copy of a live project record, held outside the Common Data Environment (CDE) that produces it and inside storage the owning organisation controls. It carries the files, the folder structure, the version history, the metadata and the audit trail, so the copy can be read and interrogated the way the live environment can.
Most projects do not hold one. The delivery team relies on the platform vendor's own resilience. That resilience is built to keep the vendor's service running for all of its customers.
This article covers:
What a CDE backup is and how it differs from vendor resilience
The failure modes that remove a project's access to its own record
What a backup of a CDE has to contain to be usable
Where the second copy should be held
A continuous copy maintained inside a client's own environment
How CDE backup and CDE archive divide the work
What is a CDE backup?
A CDE backup is a copy of the project record as it currently stands, written continuously while delivery is under way and read rarely. It is sized for restoration speed, because it is usually needed at the moment work has stopped.
Custody separates a backup from a duplicate. The copy sits in a platform, a storage account or a server the organisation holds in its own name, so it can be opened without a third party's permission and without any commercial arrangement remaining in place. A copy held inside the same tenancy is exposed to the same events as the original.
A typical large infrastructure project moves between 50 and several thousand models and documents a week between environments. A copy refreshed monthly sits a month behind the record it is meant to protect.
Vendor platform resilience and the copy your organisation holds
The major CDE vendors run replicated storage, tested failover and security teams with real depth. That infrastructure protects the platform against hardware failure, data centre loss and most availability events.
Platform resilience covers a narrower set of risks than a project record needs covered. It keeps the vendor's service available. It does not place a readable copy of one project's information in the hands of the organisation obliged to hold that information for years after handover.
The number of places needing cover has grown. Deloitte and Autodesk found in their 2025 State of Digital Adoption research that construction businesses across Asia Pacific use a median of 11 separate data environments. Each of those carries its own retention settings, its own recycle bin window and its own commercial term.
Failure modes a CDE backup protects against
Five situations account for most cases where an organisation loses working access to a record it still needs.
Ransomware reaching a synchronised local estate. Encryption usually begins on a workstation rather than in the platform. A desktop client mirrors the encrypted files back to the CDE as new revisions and the platform accepts them. Version history helps only where the retention window is long enough and somebody notices in time.
Bulk deletion or overwrite by someone with legitimate permissions. A folder tree gets restructured, a bulk upload is pointed at the wrong location, or a set is superseded that should have stayed live. No security control intervenes, because nothing improper has happened.
Licence or account lapse at the end of a commercial relationship. A joint venture dissolves, a subcontract completes, or a licence is not renewed. The record still exists inside the platform, and the party contractually obliged to hold it can no longer reach it.
Regional outage. Cloud regions fail occasionally and usually recover quickly. A short outage still stops a submission due that morning.
A dispute in which the party holding the platform is the counterparty. Arcadis put the average construction dispute value at US$52.6 million globally in its Global Construction Disputes Report series for 2022 to 2024, with sums in dispute trending toward 32.3 per cent of project CAPEX. An organisation in that position needs its own copy of the transmittals, the issued revisions and the correspondence.
What a backup of a CDE has to contain
Copying the latest revision of every file produces a folder of documents with no history attached. Questions raised in an audit or a claim are rarely about the current revision, so that folder will not answer them.
Four things have to come across with the files:
Every revision. Most of what a backup is asked for concerns what was issued at a given date, not what the file says today.
Folder structure. Where a document sits in the work breakdown tells a reader what it belongs to. A flattened export loses that.
Metadata. Suitability codes, revision states, discipline, originator and approval attributes are what make the copy queryable rather than browsable.
Audit trail. Evidence of who issued what, when, and against which revision.
Rebuilding that lineage after the fact takes weeks of manual work across platforms that never shared a version history. The method for proving a record arrived intact is set out in how to validate a CDE migration.
Where the second copy should live
The copy has to be able to fail separately from the original. A second folder inside the same tenancy does not meet that test.
Three destinations cover most requirements. A different vendor platform suits organisations already licensed across two ecosystems that want the copy to remain a working CDE. Azure Blob storage in the organisation's own subscription is the cheapest per terabyte and sits under the organisation's own identity and access controls. An on-premises network server is reached through a lightweight outbound-only Sync Agent. That agent needs no inbound firewall rules and no public endpoints, so the arrangement suits SOCI Act regulated and classified environments.
Residency obligations apply to the copy as well as to the original. The global data region map sets out the Azure regions available for the destination. The wider obligation is covered in Data Sovereignty and Residency.
CDE Backup™ runs on the CDE Sync™ engine and is configured through the same wizard. The service streams data between source and destination and does not store project files, keeping only encrypted credentials and synchronisation logs. The controls behind that are published on the Security and Trust Portal.
A continuous copy held in the client's own environment
Some organisations run the arrangement from the other end. The delivery team maintains a continuous copy of the project record inside the client's own tenancy, so the asset owner holds the information throughout delivery instead of receiving it as a package at handover.
That changes what each party carries. An owner holding the record throughout delivery does not depend on a contractor's platform for information it will keep for the life of the asset, and no single party is left as sole custodian of the evidence. Hwang and colleagues found in 2014 that every A$1 invested in documentation quality management returns A$7.40 across infrastructure projects.
CDE backup and CDE archive
Backup and archive often appear as a single line in an information management plan. They cover different states of the record and are sized for different things.
A backup protects a record that changes daily and has to be current within hours. An archive holds a closed record that will not change again and has to stay readable and affordable for the length of the retention obligation. The closed side of the pair is dealt with in the companion article CDE Archive: Keeping the Project Record After the Project Closes.
Is a CDE backup different from what my CDE vendor already provides?
Yes. A vendor protects its own platform against infrastructure failure and generally does that well. An independent copy sits in a location your organisation controls. That copy is what covers deletion by a permitted user, ransomware arriving through a synchronised local drive, account lockout, and loss of access when a commercial relationship ends.
Does a CDE backup have to include version history and metadata?
Yes. Files on their own cannot show what was issued, when, at what suitability and by whom. A copy worth maintaining preserves every revision, the folder structure, the metadata and the audit trail, so it can be queried the way the live environment can. A flat export of current revisions will not support an audit or a claim.
Can the backup sit on our own servers rather than in the cloud?
It can. An on-premises network server is a supported destination and connects through an outbound-only agent, so no inbound firewall rules or public endpoints are needed. Organisations working under SOCI Act obligations or in classified environments commonly choose this option, sometimes alongside a cloud copy held in a second region.
CDE Backup maintains a second copy of a live project record in a platform, a region or a server of your choosing, with folder structure, version history, metadata and audit trail intact. It runs on the CDE Sync engine and under the same security controls. Get in touch to work out where your copy should sit and what it needs to carry.