5. Data preparedness

The IT team has not gone home. They worked through the night, sleeping in turns, living on bad coffee and adrenaline. By morning, the situation looks finally better. Many systems respond again. 

Then people start opening applications. The ERP loads, no error. But it’s impossible not to notice it’s desperately empty. No stock. No product catalog. No orders. No history. Other systems show the same void. Interfaces are there, but the data is gone. The company cannot tell what it owns, what it has sold, or what it still owes.

The backups, at least, were done properly. The 3-2-1 rule had been followed religiously. 3 copies. 2 in different regions of the same cloud, now unreachable. 1 final copy stored offline. When the team rushed to retrieve it, there was relief: the backup was uncorrupted.

Only then did the last question surface: the backup was encrypted. Guess where the encryption keys were living ?

Failure mode

Most organizations believe they are safe because their data is “backed up somewhere else.”

In practice, this usually means:

• Backups stored with the same cloud provider ;
• Managed by the same control plane ;
• Encrypted with keys you do not own ;
• Restorable only through provider-specific tooling.

This protects against hardware failure. It does not protect against account lockout, sanctions, legal takedowns, cascading control-plane outages, or provider unavailability.

Objective

The objective of data preparedness is to ensure you retain access to your data under all circumstances. This means being able to retrieve, decrypt, and reuse its critical data without the cooperation of the original provider. This is not about minimizing downtime inside a platform. It is about guaranteeing continued existence outside of it.

Solutions

When the 3-2-1 rule is no longer enough

The 3-2-1 backup rule is often presented as the gold standard of data protection: three copies of the data, on two different media, with one copy stored offsite. It is a sound rule for a world where failures are technical (disk failures, data center incidents, etc…).

Our new geopolitical environment introduces a different class of failure. The problem is no longer where the data is stored, but who controls access to it. Two copies in different regions of the same cloud provider still depend on the same identity system, the same control plane, and often the same encryption service. When the cloud becomes unreachable, legally, politically, or operationally, those copies fail together. Even the “offline” copy can become a mirage. If it was produced by the same platform, encrypted with keys managed by the same provider, it remains logically locked. The data exists. 

In this environment, we have to extend the 3-2-1 rule: at least one copy must not only be offsite, but platform-independant: decryptable and restorable without the original provider.

Once you accept that not all copies are equal, a second question immediately follows: what is actually worth copying at this level of rigor? Not all data deserves preparedness-grade protection. Some datasets are inconvenient to lose. Others are fatal. Preparedness starts by making this distinction explicit.

Data is the asset, not the application

Applications can be rebuilt. Infrastructure can be redeployed. But data is the irreducible core of the company.

Ask yourself: 

• What data is existential (customers, transactions, contracts, identity, IP) ?
• What data defines the Minimal Survivable Service (MSS) ? 
• If you had to restart the company in a degraded mode, which datasets would you absolutely need? 

Those datasets deserve a different level of protection.

The illusion of “backup”

“Backup”, “replication” and “export” are often confused. They are not interchangeable :

A backup is a copy of your data - usually intended to be restored inside the same system that created it. In practice, it’s often stored with the same provider, restored using provider-specific tools, encrypted by the provider. Backups are good against accidental deletion, corruption or regional outages. But they are useless if the platform itself is unavailable.

A replication is a live copy of your data, mirrored somewhere else within the same provider ecosystem. It shares the same identity system, credentials, and encryption model. Replication is good at improving availability, load distribution and to enable a graceful failover with near-zero data loss. But replication does not protect against provider-wide outages.

An export is a provider-independent copy of your data designed to be used elsewhere. Data is pulled out of the platform, stored outside of the provider’s control, using documented and portable formats (hopefully), and decryptable with keys you own. Exports are slower, more manual, rarely elegant - and often ignored. Yet, they are designed for exit. 

Backups and replication are excellent information security practices - yet preparedness requires exports. 

Encryption key ownership

Encrypting data is one of the most basic information security practices. It protects against external attackers, it reduces impact in case of breach and enables the enforcement of control boundaries (ex: data from different customers being encrypted with different keys to ensure nobody can have access to both). 

In normal operations, encryption keys are very rarely touched - making this dependency invisible. For security reasons, encryption keys are often stored in a Key Management System (KMS), which often lives within the provider’s infrastructure. 

Key ownership means that you regularly export key material and that decryption is possible outside the original platform.

Conclusion

Data preparedness is not about redundancy. It is about control. Copies do not matter if you cannot reach them. Encryption does not protect you if the keys are out of reach. And a perfect backup strategy is meaningless if recovery depends on the very platform you are trying to survive.