Offsite Backup Storage for CUI: FedRAMP, Encryption, and Boundary Logic
The Data Moved. The Compliance Obligation Didn't Stay Behind.
Moving CUI backups offsite — to a cloud bucket, a colocation facility, or a managed backup provider — does not move them out of your assessment boundary. The compliance obligations travel with the data. Here is the boundary logic that determines what your offsite backup architecture must satisfy, and the patterns that are easiest to defend.
The Central Question: What Changes When CUI Enters Backup Storage
Contractors understand — at least in principle — that production systems handling CUI are in scope for CMMC. Servers, workstations, cloud tenants, email — all clearly inside the assessment boundary. But the moment a backup job copies CUI to a storage target that lives somewhere else — a different rack, a different building, a different provider — the instinct is to treat that target as infrastructure rather than as a compliance-relevant system.
That instinct is wrong. And the reason it is wrong is straightforward.
What changes when CUI enters offsite backup storage is not the compliance obligation. What changes is the number of parties, locations, and systems that obligation applies to. The backup vendor's cloud, the colocation facility's physical security, the managed service provider's admin credentials — all of these are now part of the compliance story you must tell in your SSP and defend during assessment.
Encrypted-at-Rest Arguments and Where They Fail
The most common defense for keeping offsite backup infrastructure out of scope is encryption. The argument runs: the backup data is encrypted with AES-256 before it leaves our environment. The offsite target holds ciphertext, not CUI. The provider cannot read it. Therefore the provider's infrastructure is not storing CUI and is not in scope.
This argument has a specific, narrow condition under which it holds — and that condition is almost never met in practice.
Client-Side Encryption with Customer-Held Keys
The backup data is encrypted before it reaches the provider's infrastructure, using keys that the provider never possesses. The provider cannot decrypt the data under any circumstance — not with admin access, not with a court order, not with a support escalation. In this architecture, the provider stores ciphertext that is computationally indistinguishable from random data. The argument for excluding the provider from CUI Asset classification is defensible.
Provider-Managed Encryption
The backup vendor encrypts data using keys it generates and manages — even if the encryption is AES-256, even if the key is stored in a hardware security module. If the vendor can decrypt the data, the vendor's system stores CUI in a form that is accessible to the vendor. The vendor's infrastructure is in scope. The encryption is a control on an in-scope system, not a mechanism that moves the system out of scope.
The critical test is not whether the data is encrypted. It is who holds the decryption key. If anyone at the offsite provider — an engineer, a support technician, an automated recovery process — can access a key that decrypts the backup data, the provider's infrastructure stores CUI and is in scope. Period.
Additionally, encryption addresses confidentiality — but not the other obligations. Even if the offsite provider truly cannot decrypt the data, the provider's infrastructure still transmits CUI (encrypted or not) during the backup and restore process. The network path between your environment and the provider's storage is a transmission channel. The provider's storage platform receives, stores, and serves data that — if the key were compromised — would be CUI in the clear. These considerations may place the provider's systems in scope as Specialized Assets or Security Protection Assets, even if they are not classified as CUI Assets.
Cloud Storage Categories and How to Think About Them
Not all cloud storage is equal for CMMC purposes. The FedRAMP authorization status of the storage target determines whether it can hold CUI at all — and the authorization level determines how much of the compliance burden the provider absorbs versus how much remains on the contractor.
| Storage Category | FedRAMP Status | CUI Backup Suitability |
|---|---|---|
| AWS GovCloud (S3) | FedRAMP High | Suitable. U.S.-only regions, screened personnel, IL4/IL5 capable. Contractor must still configure encryption, access controls, and logging. |
| Azure Government (Blob Storage) | FedRAMP High | Suitable. Physically separated from commercial Azure. Aligns with GCC High architecture. Same contractor-side configuration obligations. |
| AWS Commercial (S3) | FedRAMP Moderate (some services) | Caution. FedRAMP authorization varies by service and region. Data may reside in non-U.S. data centers. Does not meet ITAR requirements. Must verify specific service authorization. |
| Azure Commercial (Blob Storage) | FedRAMP Moderate (some services) | Caution. Same limitations as AWS Commercial. Not recommended for CUI under DFARS 7012 after the December 2023 FedRAMP equivalency clarification. |
| Backblaze B2, Wasabi, etc. | No FedRAMP authorization | Not suitable for CUI. Regardless of encryption, the platform does not meet FedRAMP Moderate equivalency. Storing CUI here — even encrypted — violates DFARS 7012 if the provider can access the key. |
| Vendor-proprietary cloud (Datto, Acronis Cloud, Veeam Cloud Connect partner) | Varies — most are not FedRAMP | Not suitable unless the specific cloud instance holds FedRAMP authorization. "SOC 2 compliant" is not FedRAMP. The vendor must provide a FedRAMP authorization letter or Body of Evidence. |
Backup Vendors Versus Storage Vendors Versus Managed Backup Providers
The offsite backup chain typically involves multiple parties, each with a different role and a different scope classification. Contractors frequently conflate them — referring to "our backup vendor" without distinguishing between the software, the storage target, and the managed service. For assessment purposes, these distinctions matter.
Backup Software Vendor
The company that makes the backup product — Veeam, Commvault, Acronis, Cohesity. The software runs in your environment. The vendor provides the license and updates. Unless the vendor has remote access to your backup console or hosts a cloud component that receives your data, the software vendor is not an ESP. Their product is a tool you operate. Your configuration of that tool is assessable. The vendor's development practices generally are not — unless you use their cloud services.
Storage Infrastructure Provider
The company that provides the raw storage target — AWS, Azure, a colocation data center. They do not manage your backups. They provide the platform where your backup data lands. If the platform stores CUI (even encrypted with provider-accessible keys), the provider is part of your assessment boundary. For cloud providers, the FedRAMP authorization status determines suitability. For colocation, the facility's physical security becomes assessable under PE controls.
Managed Backup Provider (MSP/MSSP)
The company that operates the backup infrastructure on your behalf — configuring jobs, monitoring success/failure, managing retention, potentially initiating restores. This provider is an External Service Provider with direct access to CUI. Their systems, their personnel, their administrative credentials, and their monitoring infrastructure are all in scope. You must document the shared responsibility boundary and demonstrate their compliance posture to the assessor.
Recovery Workflows That Inadvertently Process CUI
The backup conversation focuses almost entirely on the outbound path — data flowing from production into storage. But the inbound path — the restore — is where scope violations most commonly occur, because recovery is almost always performed under pressure, with less planning, and with fewer controls than the original backup.
Backup Job
CUI flows from production to offsite storage. Path is planned, encrypted, documented.
Offsite Storage
CUI resides in offsite repository. Encrypted. Retained per policy. Monitored.
Restore Job
CUI flows back to a target system. That target must be in scope and hardened for CUI.
Specific recovery scenarios that create scope problems:
- Restore to a test environment — An administrator restores a CUI database to a development server to verify backup integrity. The dev server is not in the CUI boundary, has no conditional access, no DLP, no audit logging. CUI now resides on an uncontrolled system.
- Bare-metal recovery to new hardware — A failed server is replaced. The backup is restored to a new machine that has not yet been enrolled in Intune, joined to the domain, or hardened per the baseline. CUI is accessible on an unhardened endpoint during the gap.
- Provider-initiated restore — The managed backup provider restores data on your behalf using their own infrastructure. During the restore, CUI may traverse the provider's management network, land temporarily on the provider's staging systems, or be accessible through the provider's admin console. Each of these steps is CUI processing on the provider's systems.
- Granular recovery to a user's mailbox or OneDrive — A backup product restores a deleted email or file directly to a user's account. If the backup was taken from GCC High but the restore targets a Commercial mailbox — because the user has accounts in both tenants — the CUI has been spilled into a non-compliant environment.
How to Document the Architecture in the SSP
Backup architecture must appear in the SSP in the same way any other CUI-storing system appears: as a named asset with a defined role, documented data flows, identified access controls, and a clear boundary with any external parties. Assessors consistently report that backup infrastructure is the most under-documented component of the SSPs they review.
At minimum, the SSP should describe:
Patterns That Are Easier to Defend
Some offsite backup architectures create cleaner compliance stories than others. The following patterns produce the fewest assessment findings — not because they avoid scope, but because they manage scope explicitly and produce straightforward evidence.
GCC High → Azure Government Blob Storage
Backup data from a GCC High environment lands in Azure Government storage within the same sovereign cloud. Both source and target are FedRAMP High authorized. The backup path stays within the Azure Government boundary. The shared responsibility model is documented in Microsoft's CRM. Evidence is clean: a single authorization letter, a single CRM, and a single set of customer-side controls.
On-Prem → AWS GovCloud S3 (Client-Side Encrypted)
Backup software in the on-premises enclave encrypts CUI with keys held exclusively by the contractor, then writes the ciphertext to an S3 bucket in AWS GovCloud. The provider cannot decrypt the data. The GovCloud bucket is FedRAMP High authorized. Key management is documented in the SSP. The provider's scope classification is Specialized Asset (stores ciphertext, not CUI).
On-Prem → Colocation with Contractor-Owned Hardware
The contractor owns the backup server and storage hardware housed in a colocation facility. The facility provides power, cooling, and physical security. The contractor manages the systems. The colocation provider is not an ESP — they do not access, manage, or process the data. Physical security at the facility must be documented (PE controls), and the contractor must verify that the facility meets the physical protection requirements in their SSP.
Managed Backup to Non-FedRAMP Vendor Cloud
A managed backup provider operates the backup software and stores CUI in their proprietary cloud, which is not FedRAMP authorized. This is the hardest architecture to defend. The provider is an ESP with CUI access. Their cloud does not meet DFARS 7012 FedRAMP requirements. The only path to compliance is client-side encryption with exclusively contractor-held keys — and that must be proven, not assumed.
The simplest architectures keep CUI backup data within the same compliance boundary as the production data. When backup data crosses into a new provider, a new facility, or a new cloud platform, every crossing requires additional documentation, additional evidence, and additional risk — all of which the assessor will probe.
The Bottom Line
Offsite backup storage for CUI is not a gray area. The boundary logic is clear: if the storage target can hold CUI in a readable form, the target is in scope. If the provider manages the target, the provider is an ESP. If the cloud platform is not FedRAMP authorized, storing CUI there violates DFARS 7012 — regardless of encryption, unless the contractor exclusively holds the keys and the provider has zero decryption capability.
The contractors who pass assessments cleanly are the ones who choose offsite targets that match the compliance posture of their production environment — FedRAMP High cloud storage, sovereign infrastructure, or contractor-owned hardware in a physically secured facility. They document the architecture completely in the SSP, including the recovery path. And they do not rely on encryption as a scope-avoidance strategy.
Scope follows the data. When CUI leaves your building on a backup job and lands in someone else's infrastructure, the compliance obligation arrives with it. The question is not whether the offsite target is in scope. The question is whether you have chosen a target — and documented an architecture — that you can defend when the assessor traces the data flow from source to storage and back.