Every organization we migrate into GCC High already has backups running before we touch the tenant. Almost none of them have confirmed where those backups land.
That gap isn’t hypothetical. DFARS 252.204-7012 requires covered contractor information systems to implement NIST SP 800-171. Control 3.8.9 states it plainly: protect the confidentiality of backup CUI at storage locations.
What Control 3.8.9 Requires
The requirement is narrower than most people assume. It doesn’t say an organization must have a backup. It says that wherever CUI ends up once it’s backed up, that copy’s confidentiality has to be protected the same way the original is, typically through encryption and access control at the storage location itself.
That distinction matters, because most organizations already pass the easy version of this question. Yes, we have backups. The harder question is where those backups live, and whether anyone has ever checked.
Where the Backup Actually Lands
A backup vendor selected for uptime and price, often years before GCC High was even under discussion, doesn’t automatically inherit the boundary a CUI environment now sits inside.
Microsoft’s own documentation shows the parity gap directly. Azure Backup’s support matrix limits Resource Health monitoring for backup vaults to “all Azure public regions, except Sovereign clouds,” and scopes Zone-Redundant Storage to a named list of regions that includes US Gov Virginia for some workloads and not others. Azure Site Recovery’s overview documentation doesn’t address Azure Government or GCC High support at all. It has to be confirmed separately, service by service.
None of that means these tools can’t be used inside a compliance boundary. It means the fact that a backup exists, and the fact that it’s a backup built for GCC High, are two different facts. Only one of them satisfies 3.8.9.
What “Protected” Really Means Once It’s Backed Up
Confidentiality isn’t a single checkbox. Azure Backup encrypts data at rest by default using platform-managed keys, Microsoft’s own keys, held and rotated on Microsoft’s schedule, not the organization’s.
An organization can move to customer-managed keys instead, stored in Azure Key Vault or a managed HSM, with its own rotation schedule and its own access control on who can unwrap them. That’s a real control gain. It’s also a one-way door: once customer-managed keys are turned on for a vault, there’s no reverting to the platform-managed default.
NIST SP 800-171 control 3.13.11 adds a second requirement most teams don’t connect to backups at all: when cryptography protects the confidentiality of CUI, that cryptography has to be FIPS-validated. Microsoft’s own documentation on customer-managed keys for backup vaults doesn’t state a FIPS validation status either way. That’s a detail to confirm against Microsoft’s own FIPS compliance documentation, not assume from the encryption feature description alone.
The Assumption That Costs the Most
The organizations we see get this wrong aren’t the ones without backups. They’re the ones whose backup vendor was never re-evaluated after the environment around it became a CUI boundary.
A Recovery Services vault’s sovereign-cloud footnote will never win an award for compelling reading, but it’s exactly the kind of detail an assessment doesn’t forgive skipping.
Confirming where a backup lands, and whether that location was ever evaluated against a CUI boundary, is a short conversation. It’s far shorter than the one that happens after an assessor asks the same question and the answer is silence.
