ITAR Compliance: A Practical Guide For SaaS Companies
Recent actions by the Directorate of Defense Trade Controls (DDTC) show why access governance matters for companies handling defense technical data. In October 2024, the State Department concluded a $200 million consent agreement with RTX Corporation over export violations, including unauthorized transfers of technical data controlled under the International Traffic in Arms Regulations (ITAR). And this is just one example.
For SaaS leaders, ITAR compliance turns on who can access controlled data and where it resides, which brings software companies into export-control scope through distributed teams and cloud infrastructure, including offshore contractors, in ways a machine shop never faced.
Covered SaaS companies need to identify what ITAR governs, whether their operations fall in scope, which requirements apply, and how an authorized cloud boundary can satisfy data residency, U.S.-person access, encryption, and monitoring demands shared with Controlled Unclassified Information (CUI) and Federal Risk and Authorization Management Program (FedRAMP) obligations.
Key Takeaways
- ITAR governs defense trade. The regulations govern defense articles, technical data, and defense services listed on the U.S. Munitions List, administered by DDTC.
- SaaS companies qualify. A company falls under ITAR when it stores, processes, or grants access to ITAR technical data, including through foreign nationals or offshore teams.
- Covered companies register. They also need a technology control plan that governs personnel screening and U.S.-Person-Only access under DDTC registration requirements.
- Infrastructure matters. ITAR's residency, personnel, and encryption controls overlap with CUI export-control handling and FedRAMP, which is why covered workloads converge on authorized cloud boundaries.
ITAR Applies To Defense Articles, Technical Data, And Defense Services
The ITAR regulatory framework, codified at 22 CFR Parts 120–130 and administered by DDTC, implements Section 38 of the Arms Export Control Act. The regulations govern the manufacture, export, and temporary import of defense articles, the furnishing of defense services, and brokering activities involving items described on the U.S. Munitions List (USML).
An item falls under ITAR when it is described in one of the USML categories at 22 CFR 121.1, along with any technical data or defense service directly related to it.
Technical data means information required for the design, development, production, manufacture, assembly, operation, repair, testing, maintenance, or modification of defense articles, including blueprints, drawings, plans, instructions, and directly related software. It excludes general scientific principles commonly taught in universities and information in the public domain.
For SaaS companies, access alone can create a regulated event.
Certain SaaS Companies Fall Under ITAR
A SaaS company falls under ITAR when its software operations touch controlled defense data, even if it never manufactures a defense article. The regulations govern how defense-related technical data is stored, accessed, transmitted, and protected, and several common operating patterns pull software companies into scope:
- Storing or processing ITAR technical data for defense customers. ITAR requirements flow down through the supply chain under DFARS §225.79 and 252.225-7048, so primes scrutinize their SaaS subcontractors' export posture.
- Employing foreign nationals with system access. Releasing technical data to a foreign person inside the U.S. constitutes a deemed export, so a non-U.S. person engineer with access to controlled data incurs a deemed export every login.
- Providing access information to foreign persons. Since the 2020 encryption rule, providing a foreign person with decryption keys, network access codes, or passwords that enable access to unencrypted technical data requires prior DDTC authorization.
- Using offshore engineering or managed service providers. An MSP or vendor using foreign-owned or foreign-staffed services touching ITAR-scope systems may need DDTC authorization or a different staffing model.
- Moving data to or within the cloud. Storage on servers outside the U.S., or administration by non-U.S. persons, can constitute an unauthorized export even when no one intended to send anything anywhere.
Those patterns all require the same operating discipline: map controlled data to the systems and people that can reach it.
ITAR Compliance Rests On Three Core Requirements
For an in-scope SaaS company, compliance begins with DDTC registration and a documented control plan that makes export-control decisions enforceable in daily operations.
1. Register with the DDTC
Under ITAR § 122.1, a single occasion of manufacturing, exporting, or furnishing a defense service triggers the registration requirement, and registration remains mandatory even if a company never exports.
- Companies submit DDTC Form DS-2032 through the Defense Export Control and Compliance System (DECCS)
- DDTC review typically takes approximately 30 days.
- Registration renews annually, with submissions due at least 30 days but no earlier than 60 days before expiration.
Fees start at $3,000 per year under the tier structure effective January 9, 2025. Registration is a precondition for any license or approval, and export authorization requires a separate license or approval.
2. Implement a technology control plan (TCP)
The DDTC's Compliance Program Guidelines list management commitment, personnel-screening procedures, a physical security plan, an information security plan, and training and awareness programs as required elements.
A defensible TCP should turn those elements into enforceable controls. It also includes regular TCP updates reflecting changes in technology scope or personnel, documented authorization chains for any release of controlled technology, and signed employee compliance acknowledgments.
For a SaaS company, the information security plan carries the operational work. It should define:
- defined system boundaries for every environment holding ITAR data;
- encryption in transit and at rest;
- tamper-resistant logging under NIST SP 800-53 Revision 5 (September 2020) controls; and
- auditable change control.
Those controls turn the TCP from a policy document into an enforceable boundary.
3. Screen personnel and restrict access to U.S. persons
Every employee, contractor, and visitor must be screened for U.S. person status and against U.S. Government-denied parties lists before receiving access, with results documented. U.S. person validation belongs in identity governance workflows covering onboarding, revalidation and offboarding.
Enforce unique user identification for every user, since even a shared login can constitute a deemed export. Apply role-based access control (RBAC) and the principle of least privilege, and require multi-factor authentication (MFA) for every account that touches controlled systems. Where foreign-person access is genuinely necessary, the TCP must first obtain the required DDTC authorization.
ITAR, CUI And FedRAMP Cover Overlapping But Distinct Ground
These three regimes intersect constantly for defense-market SaaS companies, but one doesn't replace another:
- ITAR technical data is a category of CUI. The NARA CUI Registry explicitly lists export-controlled information, marked as CUI//EXPT or CUI//SP-EXPT, depending on the underlying authority.
- FedRAMP and ITAR govern different obligations. FedRAMP authorizes cloud security against NIST SP 800-53 Rev5 controls; ITAR governs export jurisdiction. A company may need both.
- ITAR and FedRAMP set different access baselines. ITAR requires U.S.-person-only access unless DDTC authorizes a foreign-person release. FedRAMP baselines built on NIST SP 800-53 don't impose that rule.
- DFARS ties them together. DFARS 252.204-7012 requires cloud services that handle covered defense information to meet FedRAMP Moderate or equivalent, and the Moderate vs. high levels decision sets the control depth.
That distinction is why the infrastructure decision cannot be solved by a generic security authorization alone.
ITAR Obligations Often Point Back To An Authorized Cloud Boundary
ITAR's cloud exposure reduces to two structural questions commercial cloud regions leave unresolved: does controlled data stay on U.S. soil, and is every person with logical or physical access a U.S. person? Commercial regions don't provide those commitments by default.
Under 22 CFR § 120.54, sending or storing technical data is not an export when four conditions hold at once:
- The data is unclassified;
- it is end-to-end encrypted;
- The encryption uses FIPS 140-3 validated cryptographic modules; and
- The data is never sent to or stored in a proscribed country under § 126.1.
End-to-end means decryption keys never reach any third party. A SaaS provider that holds customer keys or whose foreign-national staff could access them would break the carve-out.
In practice, companies converge on government cloud boundaries, such as AWS GovCloud (US), Azure Government, and Google Cloud's Assured Workloads ITAR package, which guarantee U.S. data residency and U.S.-person administration and hold FedRAMP High authorizations and DoD impact-level provisional Authority to Operate (ATO) decisions.
A Pre-Authorized Boundary Compresses The Infrastructure Path
That convergence compounds cost. Hosting in GovCloud doesn't complete your SaaS product's FedRAMP authorization; defense customers and DFARS flow-downs from their primes require authorization of your offering specifically. A longer infrastructure build pushes ITAR-scoped revenue later, while your technology control plan lacks the boundary it is supposed to control.
A pre-authorized FedRAMP boundary changes the sequencing. Rather than building U.S. data residency, validated encryption, audit logging, and U.S.-persons infrastructure from scratch, vendors deploy inside an environment where those controls already exist and inherit a significant portion of what FedRAMP and ITAR-adjacent requirements demand.
That shifts the infrastructure question from a 12-to-36-month build into a deployment decision, letting the SaaS team focus on the export-control program itself, meaning registration, the TCP, personnel screening, and access governance, rather than reconstructing its foundation.
An Authorized Boundary Simplifies ITAR-Adjacent Compliance
ITAR has no certification, and auditors can't grant one. Compliance depends on jurisdictional facts about controlled data and the people and infrastructure that can reach it. Procedural obligations cost thousands; infrastructure obligations cost millions, and they are the same residency, U.S.-person access, encryption, and audit-logging controls that CUI and FedRAMP already demand.
Knox Systems compresses that lift. Its FedRAMP-as-a-Service platform delivers authorization in approximately 90 days at roughly 90% lower cost than traditional builds, through a pre-authorized boundary spanning AWS, Azure, and Google Cloud. Knox supports FedRAMP Moderate, FedRAMP High, and DISA IL-4 (with IL-5 in progress), and vendors inherit 60% to 80% of the controls, including U.S. data residency, validated encryption, and audit logging that anchor an ITAR program.
If federal or defense revenue is blocked on your compliance posture, book a meeting with Knox.
FAQs about ITAR Compliance
What evidence do customers typically request without ITAR certification?
Expect requests for the current DDTC registration and the technology control plan, as well as records demonstrating personnel screening, access controls, and ITAR-scope data residency.
Is there any DDTC fee relief for small registrants?
A small-registrant pilot program offers a reduced fee where the standard cost represents a significant share of prior-year revenue.
Does voluntary disclosure reduce ITAR penalties?
Typically, yes: DDTC's voluntary disclosure program generally results in reduced penalties for organizations that self-report before a government investigation begins. It is not a guarantee, since DDTC has pursued consent agreements despite disclosure where aggravating factors existed, such as exports to proscribed countries.
Does internet routing count as cloud storage?
DDTC has clarified that data in transit over the internet is not considered stored, which matters when analyzing routing paths. The clarification applies to routing; stored data still has to fit an available authorization or the § 120.54 carve-out.