ITAR and EAR export-controlled data: encryption and cloud rules

Does storing ITAR or EAR export-controlled data in the cloud count as an export?

Storing export-controlled CUI in a cloud service is not an export only when the data is protected by end-to-end encryption and is not kept in a restricted country. Under ITAR 22 CFR 120.54(a)(5), sending, taking or storing unclassified technical data is not an export if it is secured with end-to-end encryption using FIPS 140-2 (or successor) compliant modules, or other means of at least AES-128 strength, and it is not intentionally stored in a country proscribed under 22 CFR 126.1. The EAR reaches the same result under 15 CFR 734.18(a)(5) for technology and software, using FIPS 140-2 (or successor) compliant modules or equally effective means and avoiding storage in a Country Group D:5 country. The eCFR text for 22 CFR 120.54 and the eCFR text for 15 CFR 734.18 define the conditions exactly, and a contractor should work from those texts rather than from summaries.

The organization owns this determination. A cloud provider does not certify ITAR compliance for you, and AWS states that as a cloud provider it is not an exporter of customer data. Its role is to restrict access to the AWS GovCloud (US) network to US citizens, which supports your compliance but does not replace it. The answer depends on three things you control: the data, the encryption design and who can reach the keys. For end-to-end encryption to hold, data must never be unencrypted between the in-country security boundaries of the originator and the intended recipient, and decryption means must not be given to any third party. A key held by a provider's staff, a foreign administrator with console access, or a key management service in an unapproved region can each take the arrangement outside the carve-out. Confirm with counsel and your export compliance officer which technical data you hold, where each key lives, and which administrators can reach it before you treat cloud storage as non-exporting.

Which US-person cloud environments serve export-controlled CUI

Export-controlled technical data that is also CUI needs a cloud environment that fits both the export rules and the contract. The two environments below are the ones most often considered, and each shifts different responsibilities onto the organization, so the checks differ.

AWS GovCloud (US) regions

AWS GovCloud (US) is a separate AWS network that AWS restricts to US citizens for access. AWS states that it is not an exporter of customer data and that it offers no formal ITAR certification, so the customer still owns its export compliance. Confirm that the workloads, backups and logs stay in the GovCloud (US) regions, and that no replication, support tooling or analytics service sends data outside them.

AWS personnel access restrictions

AWS says it supports customer ITAR compliance by restricting access to the GovCloud (US) network it controls to US citizens. Ask AWS to describe in writing which support, engineering and account personnel can reach the environment, and whether any access comes from outside the United States. Your own administrators and contractors also need documented citizenship checks, because AWS's restriction does not cover your team.

Microsoft 365 GCC High environment

Microsoft offers Office 365 GCC High for the US Department of Defense and for contractors that hold DoD CUI or are subject to ITAR. Licenses are sold through Volume Licensing after an eligibility validation process, and trials are not available, so plan procurement time before any data moves. Confirm that the tenant, Exchange, SharePoint, Teams and OneDrive data all sit in the GCC High service, not in commercial Microsoft 365.

Microsoft DoD environment eligibility

The Microsoft DoD environment is a separate offering from GCC High, and it is intended for the US Department of Defense. Confirm with Microsoft which environment your contracts and eligibility support, because the choice affects tenant setup, administrator access and the support staff who can reach your data. Ask for the eligibility validation requirements in writing before budgeting the project.

Customer-held encryption keys

Under the ITAR and EAR end-to-end encryption carve-outs, data stays protected only if the means of decryption are not given to a third party. A cloud provider's default key management therefore may not meet the test on its own. Confirm who creates, stores and rotates the keys, whether the keys are held in a FIPS 140 validated module, and whether the provider can ever access plaintext.

Your own encryption design

The cloud environment does not decide whether a transfer or storage is an export. Your encryption design does, so document where plaintext exists, which in-country boundaries apply, and which cryptographic modules are validated under FIPS 140. Confirm that encryption covers backups, logs, collaboration sync and remote access, and that the design is reviewed by your export counsel before export-controlled data is stored in the environment.

Choosing a storage design for export-controlled CUI

A US-person government cloud environment, such as AWS GovCloud (US) or Microsoft's Office 365 GCC High and DoD environments, places storage in a region that the provider operates for US government and defense customers. AWS states that it is not an exporter of customer data and that it supports customer ITAR compliance by restricting access to the GovCloud (US) network it controls to US citizens. Microsoft sells GCC High and DoD environments through Volume Licensing after an eligibility validation process. The organization still owns its key decisions, its user population and its encryption configuration.

Key control: Ask whether customer-managed keys are available, where they are generated and who at the provider can reach key material.
What the assessor examines: Shared responsibility documentation, the provider's compliance evidence for the specific region, customer access lists and the FIPS 140 validation status of the cryptographic modules you configure.
What the partner prepares: Account and tenant configuration, identity and access settings, encryption configuration and the evidence package that maps the provider's responsibilities to your controls.
What you must confirm: Your eligibility for the environment, whether every administrator and support path meets your US-person requirement, and whether any data leaves the environment through backups, logs or collaboration tools.

Confirm these points with the provider in writing before you commit to a design.

How to verify the design before storing data

This sequence turns the design into a record an assessor can test: what the data is, where it can go, who can reach it, and whether the encryption and hosting terms hold up in writing. Each step closes with an artifact that goes into the decision file.

Classify the technical data with counsel
Before any system is chosen, the organization decides which of its technical data is ITAR or EAR controlled, and which items are CUI as well. Export counsel or the contracting officer makes the call, using the contract's classification details, the relevant export control jurisdiction and classification records, and any distribution statements. The output is a signed data classification record that names each data set, its controlling regime, and the owner who approved it. Without this record, every later decision rests on an assumption.
Map every location and person with access
Build a data flow map that lists every place the controlled data will be created, transmitted, stored, backed up or processed, including laptops, collaboration tools, build systems, ticketing systems, logs and backup copies. For each location, record who or what can reach the data, including administrators, the cloud provider's personnel, support staff and any subcontractors. The output is a data flow diagram and an access register that an assessor can trace from the originator to the last place the data sits.
Confirm FIPS 140 validation for each module
For every component that encrypts controlled data, confirm that the cryptographic module holds a current FIPS 140 validation certificate, and that the validated module is the one actually enabled in the configuration, not just a platform that claims FIPS-compliant operation. Check the certificate number, the validated version, and the operating mode required for the setting. The output is a cryptographic module inventory with the certificate reference for each module and a note on how each is enabled. Confirm the current status of each certificate with the issuing body before you rely on it.
Document key custody and decryption boundaries
Establish who generates, holds, rotates and destroys the encryption keys, and where decryption happens. The design must show that data stays encrypted between the originator's and the recipient's in-country security boundaries, and that no third party receives the means of decryption. Record whether keys are customer-managed, held in a hardware security module within the boundary, or held by a provider, and test whether the provider can ever decrypt the data. The output is a key custody record signed by the data owner and the security lead.
Confirm provider regional and personnel terms in writing
Ask the cloud or SaaS provider to confirm, in its contract or service terms, the region in which data will be stored and processed, the citizenship or personnel restrictions on staff who can access the environment, and whether the environment is sold through a government-only offering. Confirm eligibility requirements, onboarding steps and whether trial environments are available, because these affect the schedule. Where a provider says it is not an exporter of customer data or offers no formal ITAR certification, record that statement and do not treat it as a compliance determination. The output is a written provider response, reviewed by counsel, filed with the decision record.
Confirm the DFARS cloud requirement if it applies
If the controlled data is also covered defense information and a cloud service provider stores, processes or transmits it, confirm that the provider meets requirements equivalent to the FedRAMP Moderate baseline and the incident reporting and forensic support terms in DFARS 252.204-7012. Obtain the provider's written evidence of this equivalence and check that the contract flows the reporting duties down. The output is a provider compliance file that lists the evidence reviewed and the date it was checked. Confirm the current contract language with the contracting officer, as the clause version in force can change.
Record the decision and its evidence
Assemble a single decision record that links the classification record, the data flow map, the access register, the cryptographic module inventory, the key custody record and the provider files. State the design chosen, the residual risks, and the owner who accepted them. An independent assessor will test whether each claim is supported by the evidence, so each item should point to its source and its date. An implementation partner can help prepare this file, but the organization owns the decision, and only an independent assessor or auditor issues any report or conclusion on compliance.

What usually breaks an export-controlled storage design

Most ITAR and EAR storage designs fail at a small number of points: the cryptography, who holds the keys, where copies live, how data moves between tools, and how the data is classified in the first place. Each card names one failure and the check that catches it before an assessor or an export authority does.

Approved algorithm without validation

Teams often confirm that AES is used and stop there. The CMMC Assessment Guide Level 2 is explicit that an approved algorithm is not enough: the cryptographic module must be validated under FIPS 140, and the ITAR and EAR safe harbors refer to FIPS 140-2 (or successor) compliant modules. Check the module's validation certificate number, its validated mode of operation, and whether every path that carries technical data uses it.

Keys held by the provider

The ITAR end-to-end encryption definition requires that the means of decryption are not provided to any third party. A provider-managed key store, or a support process that can unwrap customer keys, can take the design outside that carve-out. Keep key custody inside the US boundary, document who can administer the key service, and confirm in writing whether provider staff can reach key material.

Backups and logs in other regions

Technical data often leaks through copies the design team did not model: snapshots, disaster recovery replicas, search indexes, telemetry and log archives. The EAR safe harbor excludes storage in Country Group D:5 countries, and ITAR excludes storage in proscribed countries under 22 CFR 126.1. Inventory every replication target, confirm region placement for each, and make sure log content does not carry technical data unencrypted.

Collaboration tools and email transit

Files shared through chat, email, file sync or collaboration platforms can cross the boundary in transit and sit on infrastructure outside the enclave. Under the EAR, data in transit over the internet is not deemed stored, so the protection has to hold on the wire and at rest in the tool. Confirm which tenant, region and administrator group serve each collaboration service, and block personal or non-enclave accounts from receiving controlled files.

Unclear classification of controlled data

A storage design cannot protect data the organization has not classified. Technical drawings, software, and engineering notes may be ITAR or EAR controlled, CUI, both, or neither, depending on the jurisdiction and the classification decision. Ask the export compliance officer to produce a written classification for each data set, record the USML category or ECCN, and tie each label to a storage rule so that new repositories inherit the correct boundary.

Questions buyers ask about export-controlled storage

Is storing export-controlled technical data in the cloud an export?

Storage alone is not automatically an export. Under ITAR 22 CFR 120.54(a)(5) and EAR 15 CFR 734.18(a)(5), sending, taking or storing unclassified technical data is not an export if it is protected with end-to-end encryption using FIPS 140-2 (or successor) compliant modules or equally effective means, and it is not intentionally stored in a proscribed country or a Country Group D:5 country. The encryption must keep data unencrypted only inside the originator's and recipient's security boundaries, and the decryption means must not go to any third party. Your engineers decide whether the design meets those conditions, and your export counsel should confirm how the carve-out applies to your data and cloud region.

Do we need AWS GovCloud or Microsoft GCC High for export-controlled CUI?

Neither is strictly mandated by the export rules themselves, but both are common choices because they restrict access to US persons and fit DoD contract requirements. AWS says it supports customers' ITAR compliance by restricting access to the AWS GovCloud (US) network it controls to US citizens, and Microsoft offers Office 365 GCC High and DoD environments for contractors holding DoD CUI or subject to ITAR, sold through Volume Licensing after an eligibility check. The right choice depends on your data, contracts and workloads. Confirm current eligibility, service coverage and access terms directly with each provider before you commit.

Does the cryptographic module have to be FIPS 140 validated?

For the encryption that protects export-controlled data, the ITAR and EAR carve-outs refer to FIPS 140-2 (or successor) compliant modules or means of equal strength, and the CMMC Assessment Guide Level 2 says an approved algorithm is not enough on its own: the module must be validated under FIPS 140 when it protects CUI outside the protected environment. Validation is a property of a specific module and version, not of a product name. Check the module's validation certificate in the NIST validated modules list and confirm that your platform runs it in approved mode, because a validated module that is not enabled leaves the data unprotected.

What does the DFARS cloud rule add on top of the export rules?

DFARS 252.204-7012(b)(2)(ii)(D) adds a separate requirement when an external cloud service provider stores, processes or transmits covered defense information. The provider must meet security requirements equivalent to the FedRAMP Moderate baseline and support the clause's incident reporting and forensic requirements. Meeting the export carve-out does not satisfy this rule, and meeting FedRAMP Moderate does not satisfy the export rules. Contracts with DoD usually need both, so ask your contracting officer and provider which FedRAMP authorization covers the specific services you plan to use.

Can our cloud provider certify that we are ITAR compliant?

No. AWS states that there is no formal ITAR certification and that, as a cloud provider, it is not an exporter of customer data. Compliance remains the customer's responsibility, shared with the provider through its access restrictions and service terms. Your organization owns its export classification, encryption design, access decisions and records. A provider's documentation can support your evidence, but only you can show how your environment meets the rules, and no vendor statement replaces your own determination or your counsel's advice.

What work must our organization do itself?

Several decisions cannot be outsourced. Your organization must classify its technical data and decide which items are ITAR or EAR controlled, name the people who may access them, define the proscribed-country and US-person rules, and approve the encryption design and key ownership. You also own your controls, policies, system security plan, training and incident handling. A partner can build and document the technical parts, but your leadership must accept the residual risk and sign the decisions that depend on your contracts and export licenses.

What does an implementation partner prepare, and what does the assessor review?

An implementation partner such as DeployOpen can plan, configure and document the self-hosted platform, the encryption and key management, access controls, logging and backup inside your own cloud accounts or data center, and the evidence that shows each control working. The partner does not issue audit reports or certifications. An independent assessor, such as a DCMA DIBCAC reviewer for DoD assessments or another qualified assessor you engage, reviews your evidence against the requirements and reaches its own conclusions. Ask any partner to state this division of roles in writing within the fixed scope.

What drives the cost of hosting export-controlled data in a US-person cloud?

The main cost drivers are the platform tier and region you need, the number of users and systems in scope, the volume and retention of data, and how much of the encryption, key management and logging you build yourself. Recurring costs include cloud consumption, licenses, monitoring, backups and periodic reviews. One-time costs include scoping, configuration, documentation and evidence collection. Engagements are fixed-scope, so ask for a written quote that lists each deliverable, the environments covered and which items you will operate yourself. No price list is published, and provider pricing should be confirmed directly with each vendor.

Who decides, certifies and holds the risk

The organization that holds the data decides what it is, who may see it and whether it is export-controlled. Under ITAR and EAR, the organization owns its export compliance, including classifying each technical data set, deciding whether a foreign person can reach it and confirming that its encryption and storage choices meet the carve-out conditions. The cloud provider does not take that decision for the customer. AWS, for example, states that as a cloud provider it is not an exporter of customer data and that it restricts access to the AWS GovCloud (US) network to US citizens, but those are the provider's own terms and the customer still has to confirm they fit its data and its people.

Classification questions often belong to export counsel, and CUI markings and contract questions to the contracting agency or prime contractor. Ask counsel to document, for each data set, the jurisdiction, the category and the reason it is or is not controlled, and ask the contracting office which systems the agency expects to hold it. Before you choose a region or a cloud service such as Microsoft's GCC High environment, confirm eligibility with the vendor, since Microsoft states these environments are sold through Volume Licensing after an eligibility validation process. Confirm the current terms of each provider in writing rather than relying on summaries.

An independent assessor reviews the evidence against NIST SP 800-171 or CMMC, and only that assessor, or the official body that runs the assessment, issues a report, score or certificate. DeployOpen plans, configures and documents the encryption, key management, access and logging setup, and prepares the evidence for review. It does not issue assessment reports, certificates or export determinations, and it does not stand in for export counsel. Agree in writing which decisions sit with each party before work begins, so that the organization keeps the risk it is accountable for and the partner is clear about what it delivers.

How DeployOpen designs and documents export-controlled storage

DeployOpen plans and builds the self-hosted open-source platforms that hold export-controlled technical data inside the client's own cloud accounts, data centers or air-gapped networks. The work covers the encryption, key handling, access and storage design that the ITAR and EAR carve-outs depend on, and it ends with documentation that the organization and its independent assessor can review.

How we scope

Scope is agreed in writing before work starts, listing the data types, systems, users and storage locations covered
We map which data flows cross the in-country security boundary and which stay inside it
We confirm with the client which encryption modules, key owners and cloud regions the design must use
Engagements are fixed-scope, and any export classification decisions stay with the client and its counsel

How we build

We configure encryption at rest and in transit using modules the client confirms are FIPS 140 validated
Key management is designed so decryption keys are never handed to a third party outside the agreed design
Access is limited to US persons where the client's export obligations require it, enforced through identity controls
We harden storage, backups and logging so encrypted export-controlled data stays in approved locations

How we hand over

Documentation covers the data flow diagram, encryption design, key custody model and storage locations
We provide a configuration record and test results showing controls operate as the written design describes
Evidence is organized so the client's independent assessor can trace each control to a stored artifact
The client owns all systems, configurations and documents, and DeployOpen does not issue audit reports or certifications

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
We review changes to cloud regions, encryption modules or key services against the documented design
Security testing of applications, APIs and infrastructure can be scheduled to check the storage design over time
Clients should confirm the scope of any retainer in writing, including how changes to the design are approved

ITAR and EAR export-controlled data: encryption, storage and cloud rules