GCC High or bust? Designing an ITAR-compliant CUI enclave

Ask a room of defense contractors where their ITAR technical data lives and most will say the same two words: GCC High. It has become the reflexive answer — and for a lot of organizations it is the right one. But "GCC High or bust" skips the question that actually determines cost, risk, and effort: what does an ITAR-compliant enclave have to accomplish, and is a sovereign cloud the only way to get there?

What an enclave is, and why you want one

An enclave is a deliberately bounded environment — identities, devices, storage, applications, and network paths — that holds your controlled data and nothing else you can help. The point is to shrink the surface that has to meet the hard requirements. Instead of hardening your entire company to NIST SP 800-171 and ITAR standards, you draw a tight boundary around the CUI and ITAR technical data and concentrate the controls there.

Under ITAR, jurisdiction sits with the State Department's Directorate of Defense Trade Controls (DDTC). If your data appears on the US Munitions List as technical data, releasing it to a non-US person — including simply making it accessible — is an export. "US persons" here means US citizens, lawful permanent residents (green-card holders), and certain protected individuals. The enclave exists to make that release impossible by design.

Why GCC High became the default

Microsoft GCC High is a sovereign, US-based cloud with personnel and data-handling controls built for exactly this audience. It runs in an isolated tenant, is operated by screened US persons, and is designed to support DFARS and ITAR obligations without you having to reconstruct those assurances yourself. In practice it functions as a de facto CUI and ITAR enclave: the boundary and the US-person operations come largely pre-solved.

That convenience is real, and so is the cost. GCC High carries higher licensing, a heavier migration, and feature timing that lags commercial Microsoft 365. For an organization handling ITAR technical data at scale, that is usually a fair trade. For a small subcontractor with a narrow slice of controlled data, it can be a sledgehammer — which is where the alternative deserves a real look.

The §120.54 encryption carve-out

ITAR was amended to recognize that properly encrypted technical data is not "released" simply because it passes through infrastructure operated by non-US persons. 22 CFR §120.54 sets the conditions. When they are all met, moving or storing encrypted technical data through a cloud provider is not an export — even if that provider's staff are not US persons.

• End-to-end encryption. The data is encrypted before it leaves the sender's control and stays encrypted until the intended recipient decrypts it.
• Exclusive key control. The cryptographic keys are held solely by the data owner, not by the cloud or service provider.
• No access in the clear. At no point is unencrypted technical data accessible to non-US persons — explicitly including the cloud provider itself.

Get all three right and you can, in principle, keep ITAR technical data in commercial infrastructure without a sovereign tenant. Get any one wrong — provider-managed keys, a preview pane that decrypts server-side, an integration that touches plaintext — and the carve-out evaporates. This is an architecture decision with legal consequences, not a checkbox.

US-person access control is the real test

Whichever path you choose, the enforceable question is the same: can a non-US person reach the technical data, in the clear, at any point? That means access is scoped to verified US persons, and it holds not just for your employees but for administrators, help-desk staff, backup systems, and any managed-service provider with a key to the environment. A single non-US-person admin with standing access to plaintext is a finding regardless of how well the rest of the enclave is built.

Scoping the data boundary

Most enclave failures are scoping failures. The boundary has to account for everywhere the data actually goes.

• Where controlled data is stored, processed, and transmitted — and the systems that support those functions.
• Endpoints that render the data, including personal and mobile devices if you allow them near the enclave.
• Backups, log stores, and disaster-recovery copies — a compliant primary with an out-of-boundary backup is not compliant.
• Integrations and automations that read the data, including anything that could momentarily hold it in plaintext.

Common mistakes

• Treating the carve-out as key management alone. All three §120.54 conditions must hold together; exclusive key control without true end-to-end encryption does not qualify.
• Forgetting the provider is a non-US person. If the platform can read your plaintext to index, preview, or scan it, non-US-person access exists whether a human looks or not.
• Leaving CUI outside the enclave. ITAR technical data is CUI; a boundary drawn only for ITAR while CUI leaks into general email or file shares fails the CMMC side of the house.
• Buying GCC High and stopping there. A sovereign tenant is a foundation, not a finished enclave. Access, device, and data-handling controls still have to be configured and operated.

How Atom approaches it

We start by scoping the boundary honestly, then choose the architecture that fits the data and the budget — GCC High when a sovereign tenant is warranted, a properly built §120.54 encryption design when it is a better fit — and we operate the US-person access, device, and monitoring controls that keep it defensible over time. As always, Atom is not a C3PAO and does not certify. We design, build, and run the enclave; the certifying assessment belongs to an authorized third party.

"GCC High or bust" is a fine instinct. It is a poor substitute for knowing what your data is, where it goes, and who can reach it. Start there, and the platform question answers itself.