Jurisdiction is the first question, and most teams answer it last
Export control is not one rule. It is two regimes with different regulators, different lists, different penalties, and different answers to the same question about the same file. The International Traffic in Arms Regulations (ITAR, 22 CFR Parts 120 through 130) are run by the State Department's Directorate of Defense Trade Controls and cover defense articles, defense services, and technical data described on the United States Munitions List at 22 CFR 121.1. The Export Administration Regulations (EAR, 15 CFR Parts 730 through 774) are run by the Commerce Department's Bureau of Industry and Security and cover commercial and dual-use items listed on the Commerce Control List at Supplement No. 1 to 15 CFR Part 774. Before a software firm can say anything true about its obligations, it has to know which regime its product sits under.
The order of inquiry is fixed and runs one direction. Check the USML first. If the item is described there, it is ITAR-controlled and the EAR does not reach it. Only when the item is absent from the USML does the analysis move to the Commerce Control List, a sequence BIS publishes formally as the Commerce Control List Order of Review at Supplement No. 4 to 15 CFR Part 774. Teams that start with the CCL because it reads more like a product catalog end up with classifications that collapse the first time a prime's export officer asks to see the reasoning.
Getting jurisdiction wrong is not a filing error that gets corrected later. It changes who may open the repository, whether the company must register with the government before writing a line of code, how large the penalty exposure is, and sometimes whether the contract can be performed at all.
Most common gaps in software-firm export programs
Editorial weighting from public enforcement records and published BIS and DDTC guidance. Illustrative, not a measured statistic.
What counts as an export when nothing physically ships
The word "export" carries a legal definition in both regimes that has very little to do with shipping. Under the EAR, releasing technology or source code to a foreign person inside the United States is an export, and 15 CFR 734.13(b) deems it an export to that person's most recent country of citizenship or permanent residence. Under the ITAR, releasing technical data to a foreign person is an export whether that person sits in Ames, Iowa or Amsterdam (22 CFR 120.50). No border is crossed. No package moves. The regulation is satisfied by a person reading a screen.
For a software firm the list of qualifying events is longer than most engineering managers expect. Granting repository access. A screen share during a debugging session. An email with a design document attached. A support engineer with credentials into a customer's production database. An offshore contractor with a VPN account. A slide deck sitting in a bucket with public read enabled. Each is a release of technology or technical data if the underlying item is controlled, and each is an export that happened whether or not anyone filed anything.
One more catches SaaS teams specifically. Putting controlled software into a cloud region, or into any managed service where a foreign-person administrator can reach the plaintext, is a release unless a defined carve-out applies. That carve-out exists and is described below, but it is a rule with four conditions attached rather than a general exemption for anything running in someone else's data center.
ITAR and EAR side by side
| Dimension | ITAR (22 CFR 120–130) | EAR (15 CFR 730–774) |
|---|---|---|
| Regulator | DDTC, Department of State | BIS, Department of Commerce |
| The list | U.S. Munitions List, 21 categories, 22 CFR 121.1 | Commerce Control List, 10 categories by 5 product groups, Supp. No. 1 to Part 774 |
| Where software sits | Inside a category, such as Category XI(d) or Category XV(f), tied to the article it serves | Product group D, such as 5D002 or the 600-series 9D610 |
| Registration | Required to manufacture, export, or broker defense articles, even without a single export, 22 CFR 122.1 | No general registration; encryption registration required for parts of 5D002 under 15 CFR 740.17 |
| If the item is not listed | No default. If it is not on the USML, ITAR does not apply | Default is EAR99, subject to the EAR but not on the CCL, 15 CFR 734.3(c) |
| Records | Five years, 22 CFR 122.5 | Five years, 15 CFR Part 762 |
Where a data product actually lands
Across federal software and data work the answer converges on three destinations. Knowing which one applies is most of the compliance job.
EAR99. Subject to the EAR but not described anywhere on the CCL (15 CFR 734.3(c)). Most analytics platforms, document processing tools, dashboards, and data pipelines carrying no controlled subject matter land here. EAR99 is not "uncontrolled": the ten General Prohibitions at 15 CFR 736.2 still bar a denied party, an embargoed destination, or a prohibited end use. It simply needs no license for most destinations and most customers.
ECCN 5D002 with License Exception ENC. The product contains or performs cryptographic functionality, which describes nearly every modern application. Software firms miss this one most often, because the encryption arrived inside a library nobody thought about.
ITAR technical data. The product contains, derives from, or is directly related to a defense article. Signature libraries, missile performance parameters, military sensor characterization data, and design information for a USML-listed platform all fall here, along with the software written to model or operate them. A civilian-looking analytics tool can inherit this status from its training corpus, a conclusion many teams reach far too late.
Encryption pulls nearly every product into Category 5, Part 2
If a product uses TLS, encrypts data at rest, signs tokens, or embeds a cryptographic library, Category 5, Part 2 of the CCL is in scope. The controlling ECCN for information security software is 5D002, with 5A002 for equipment and 5E002 for associated technology, and license policy sits at 15 CFR 742.15. The practical relief is License Exception ENC at 15 CFR 740.17, which authorizes most encryption software to most destinations without a license. Country Group E:1, the embargoed set at Supplement No. 1 to 15 CFR Part 740, stays off limits.
ENC is not automatic. Many items require an encryption registration through SNAP-R under Supplement No. 8 to 15 CFR Part 742 before the exception can be used, plus a classification request under 15 CFR 748.3 for the categories that need one. Firms self-classifying under ENC also owe an annual report, due February 1 each year for the prior calendar year under 15 CFR 740.17(e)(3). Mass-market products can move down to 5D992.c under the Cryptography Note, Note 3 to Category 5, Part 2, which lightens the ongoing burden once documented.
Two adjacent items are worth knowing. Publicly available encryption source code posted without restriction is treated as published under 15 CFR 734.7, but 15 CFR 742.15(b) still requires a notification email to BIS and the NSA identifying where the code sits. Intrusion and surveillance-adjacent cybersecurity items carry their own ECCNs (4A005, 4D004, 4E001.c) with License Exception ACE at 15 CFR 740.22 governing who may receive them.
Datasets, model weights, and the question nobody asks
Raw data is usually not an item on either list. A CSV of maintenance records is not a defense article and is not on the CCL. The controls attach when the data describes a controlled item, because that is what "technical data" means under the ITAR (22 CFR 120.33) and what "technology" means under the EAR. Flight-test telemetry from a USML platform is technical data. A vibration dataset from a commercial pump is not. The file format is irrelevant to both answers.
Trained model weights follow the same logic rather than a special one. Weights derived from controlled technical data can carry the control forward, which is why model provenance belongs in an export file and not only in an MLOps README. Commerce published an interim final rule in January 2025 that would have controlled the weights of the most advanced closed-weight models, then rescinded it in May 2025 before its compliance date. The durable lesson is not that specific rule. It is that weights get classified by what they encode and what they enable, on the same order-of-review path as any other item. Synthetic data inherits the same test: generating records from a controlled source sanitizes nothing if the output still conveys the parameters the regulation protects.
The published and fundamental research carve-outs, and their edges
Information already published sits outside the EAR's technology and software controls under 15 CFR 734.7, and results of fundamental research at accredited U.S. institutions of higher education sit outside them under 15 CFR 734.8, a policy tracing to National Security Decision Directive 189 in 1985. The ITAR has a parallel public-domain provision at 22 CFR 120.34. These carve-outs are why an academic partner on an STTR can publish and why a firm can write a public methods article about its own techniques.
The edges matter more than the rule. Fundamental research status is destroyed by contractual publication approval rights or by restrictions on who may participate, which is exactly what many prime subcontracts impose. ITAR technical data does not become public domain because someone posted it without authorization; that is a violation, not a reclassification. And a carve-out covers only the information released, never the underlying article.
The encrypted-transmission rule that makes cloud work
Both regimes added a rule letting encrypted data move and rest without the transmission itself counting as an export. Under 15 CFR 734.18(a)(5), sending, taking, or storing technology or software is not an export when the data is unclassified, secured with end-to-end encryption using cryptographic modules compliant with FIPS 140-2 or its successors, and not intentionally stored in a Country Group D:5 country, Russia, or Belarus. The ITAR analogue at 22 CFR 120.54 tracks the same structure and adds that the means of decryption may not go to a foreign person or to a country listed at 22 CFR 126.1.
Read the four conditions as a conjunction, because that is how they are enforced. End-to-end means the keys are not held by an intermediary, so a provider that manages the keys for you may break the condition even when the bytes are encrypted in transit and at rest. This is a large part of why ITAR-relevant workloads land in AWS GovCloud (US) or Azure Government with customer-managed keys, and why key management design is an export-control artifact rather than only a security one.
Who this applies to, and how it arrives through a contract
The EAR reaches items subject to the EAR wherever they sit, and 15 CFR 734.3 defines that reach broadly enough that no U.S. software firm is outside it. On the federal side the obligation usually arrives as a contract clause. DFARS 252.225-7048, Export-Controlled Items, requires compliance and flows down to subcontracts at every tier. NASA imposes NFS 1852.225-70. DFARS 252.204-7012 pulls export-controlled information into covered defense information, so the safeguarding obligation and the export obligation land on the same systems.
DoD SBIR and STTR solicitations flag many subject areas as export-controlled, and access to militarily critical technical data withheld under 10 U.S.C. 130 runs through DoD Directive 5230.25 and 32 CFR Part 250, which is the Joint Certification Program and DD Form 2345. Firms that certify early read the controlled documentation on day one instead of waiting out a certification cycle after award. Precision Federal holds JCP / DD-2345 certification for that reason. The parallel marking obligation comes from 32 CFR Part 2002, where Export Controlled is a CUI category with its own banner and dissemination rules.
The artifacts that have to exist
BIS publishes the elements of an effective export compliance program: management commitment, risk assessment, export authorization procedures, recordkeeping, training, audits, handling problems with corrective action, and a written manual. Translated into what an auditor actually asks a software vendor to produce, the list is short.
- A written jurisdiction and classification determination for every product, module, dataset, and model, with reasoning and date
- A technology control plan naming the systems, repositories, environments, and people it governs
- An access matrix of which foreign persons reach which controlled items, reconciled against the identity provider
- Restricted-party screening records for employees, subcontractors, teaming partners, and customers, with dates
- An export compliance manual with a named owner and a training log
- Encryption registration and the annual self-classification report where 5D002 and License Exception ENC apply
- Five years of transaction, authorization, and classification records per 15 CFR Part 762 and 22 CFR 122.5
- A written procedure for stopping work, escalating, and disclosing a suspected violation
What we find when we look
"We are SaaS, so nothing is ever exported."
Release to a foreign person is an export regardless of delivery model. A hosted product still has engineers with production access, contractors with repository credentials, and support staff who screen share into customer environments. Having no shipping department has no bearing on 15 CFR 734.13(b) or 22 CFR 120.50.
"We only hire U.S. citizens, so deemed export is handled."
Wrong on the regulation and risky on the employment side. Lawful permanent residents and protected individuals are U.S. persons under 22 CFR 120.62 and are excluded from the EAR definition of foreign person at 15 CFR 772.1, so a citizens-only rule screens out people who need no authorization at all. It also runs into 8 U.S.C. 1324b, which the Department of Justice has enforced repeatedly against employers citing export control for a citizens-only posting.
"The customer told us it is ITAR, so we treat everything as ITAR."
Over-classification has a cost. It shrinks the hiring pool, blocks sensible cloud choices, and can trigger a DDTC registration obligation under 22 CFR 122.1 the firm never actually incurred. A customer's statement is an input to the determination, not the determination. When the answer is genuinely unclear, a commodity jurisdiction request to DDTC under ITAR Part 120 produces a government answer the firm can rely on.
"We classified the product once, when we launched."
Classification follows the item, and the item changes. A new cryptographic library, a new dataset, a model retrained on customer data, a new integration with a controlled platform: each can move the answer. Review at every major release and re-look annually, keeping the prior determination rather than overwriting it.
What getting it wrong costs
The statutory exposure is not proportional to company size. Under 50 U.S.C. 1705, an EAR violation carries a civil penalty up to the greater of $250,000 or twice the transaction value, adjusted annually for inflation, and a willful violation carries criminal penalties up to $1,000,000 and 20 years imprisonment. Under 22 U.S.C. 2778(c), an ITAR violation carries criminal penalties up to $1,000,000 per violation and up to 20 years, with civil penalties under 22 CFR 127.10. BIS can deny export privileges outright under 15 CFR 764.3, and DDTC can impose statutory debarment under 22 CFR 127.7.
These are not theoretical ceilings. BIS settled with Seagate Technology in 2023 for $300 million, which the agency described as its largest standalone administrative resolution, and DDTC consent agreements in recent years have carried penalties in the tens of millions plus mandated outside compliance officers. Both agencies take voluntary self-disclosure, at 15 CFR 764.5 and 22 CFR 127.12, and both treat timely disclosure as substantially mitigating and deliberate silence as aggravating.
For a small federal vendor the commercial cost usually arrives before the regulatory one. A prime contractor's supplier questionnaire asks for the classification, the technology control plan, and the screening records. A firm that cannot produce them within a few days does not get the subcontract, and nobody writes down why. That is the real reason to build the file early: it gates revenue long before it gates liability.
Screening people without crossing the anti-discrimination line
These two obligations are compatible and are frequently mismanaged together. Export control asks whether a specific person may receive a specific controlled item; immigration law forbids treating citizenship status as a general employment criterion. The defensible practice is to screen for U.S.-person status as the regulations define it, which includes citizens, lawful permanent residents, and protected individuals, and to seek authorization when a role genuinely requires access a specific person cannot yet receive. A posting that says "U.S. citizens only" without a legal basis is the fact pattern the Department of Justice's Immigrant and Employee Rights Section has settled again and again; a posting tied to the real classification of the real work holds up. The engineering control is identical either way: role-based access mapped to the classification, enforced in the identity provider, reviewed on a recorded schedule.
A practical sequence for a firm meeting this the first time
First-pass export program, typical durations
Two sequencing notes save real time. Do step 1 before step 2, since a classification written against an incomplete inventory gets redone rather than amended. And start step 4 alongside step 3 whenever a DoD solicitation is on the calendar, because certification cycles run on government time.
Bottom line
Export control for a software or data vendor comes down to four things done in order: decide jurisdiction on the record, classify the item and keep the reasoning, control who can reach it and prove that control in the identity provider, and retain the file for five years. The regulations are long, but the obligations that touch a working engineering team are narrow, specific, and buildable into how the team already works. The firms that get hurt are the ones that never wrote anything down.
Our team builds and delivers AI, ML, data, and cloud systems for federal customers under these constraints, treating the classification file, technology control plan, and access controls as engineering work rather than paperwork bolted on at the end. If a prime or an agency has asked your firm for an export classification you do not yet have on paper, that is a solvable problem.
Frequently asked questions
Yes. Releasing controlled technology or source code to a foreign person inside the United States is an export under 15 CFR 734.13(b), and releasing technical data to a foreign person is an export under 22 CFR 120.50. Repository access, a screen share, an email attachment, and a contractor VPN account all qualify.
Check the U.S. Munitions List at 22 CFR 121.1 first. If the software is described there, it is ITAR. If not, move to the Commerce Control List using the order of review at Supplement No. 4 to 15 CFR Part 774. When the answer is genuinely ambiguous, a commodity jurisdiction request to DDTC produces a government determination.
Usually it brings the product into Category 5, Part 2 of the CCL, most often as ECCN 5D002. License Exception ENC at 15 CFR 740.17 covers most destinations, but some items need encryption registration under Supplement No. 8 to Part 742 and an annual report due February 1. Mass-market products can qualify for 5D992.c.
They are controlled when they describe or encode a controlled item. A dataset derived from a defense article is technical data under 22 CFR 120.33, and weights trained on it can carry the control forward. Commercial data with no controlled subject matter is generally EAR99. Record provenance and determination together.
DFARS 252.225-7048 obligates compliance and flows down to every subcontract tier, DFARS 252.204-7012 treats export-controlled information as covered defense information, and NASA adds NFS 1852.225-70. Access to withheld DoD technical data runs through the Joint Certification Program and DD Form 2345 under DoD Directive 5230.25 and 32 CFR Part 250.