What Is ITAR Compliance? A Guide for Small Defense Contractors

You win a defense subcontract, and procurement sends over the flow-downs. Buried between cybersecurity clauses and quality terms is a requirement you cannot ignore: ITAR.

For a small contractor, that moment usually plays out the same way. Engineering thinks it is a drawing control issue. IT thinks it is a cloud settings problem. Operations assumes legal will handle it. None of those views is fully right, and that is why companies get into trouble.

The practical answer to “what is ITAR compliance” is simple. It is the set of export control rules that determine whether your company can touch certain defense-related products, data, and services without creating legal risk. In practice, it affects who can open a file, where that file lives, which cloud admin can access it, what your subcontractor sees, and whether your current CMMC plan is enough.

For small and mid-sized defense contractors, ITAR is not just a legal definition. It is an operating constraint. If you handle the wrong data in the wrong system, or let the wrong person see the wrong screen, you may have a violation even if nothing was physically shipped overseas.

The high stakes for small contractors

Small firms feel the pressure early because they usually do not have separate compliance, security, and IT teams. One person may be covering contracts, export controls, and CMMC evidence collection at the same time. That creates a practical problem. ITAR rarely fails because someone intended to export defense data. It fails because everyday business systems were never set up for controlled defense work.

The weak points are predictable:

Shared drives: Engineering stores controlled files in the same folders used for general project work.
Email habits: An employee forwards a file to a personal inbox or sends it through an unapproved collaboration tool.
Third-party administration: An MSP or cloud administrator can see systems that hold controlled technical data.
Mixed compliance assumptions: Leadership assumes a CMMC project plan covers ITAR, even though export control decisions and access restrictions require separate attention.
Cloud sprawl: Data ends up in multiple SaaS tools without a clear decision about where ITAR data is allowed to live and who can administer it.

That last point trips up many SMBs. CMMC and NIST SP 800-171 focus on protecting controlled unclassified information. ITAR adds export control restrictions that go beyond baseline cybersecurity. A company can improve its CMMC posture and still have ITAR exposure if the wrong administrator, support vendor, or non-U.S. person can access controlled technical data in the cloud.

The consequences are serious. The U.S. Department of State can impose civil penalties up to $1 million per violation under 22 CFR 127.1, pursue criminal enforcement, require corrective actions, and restrict future export activity. For a small contractor, the immediate damage usually comes sooner than any headline penalty. Work gets paused. The prime loses confidence. Legal costs rise. Internal time disappears into containment, audits, and remediation. In some cases, a single mishandled dataset is enough to put a new defense supplier on the wrong list for future awards.

That is why small contractors need to answer three questions early. What data is ITAR-controlled. Who can access it. Where will it live, especially if your CMMC plan depends on commercial cloud tools. Those answers shape the rest of your compliance program.

What ITAR actually controls

ITAR controls defense activity by defining what sits inside the regulated boundary and what actions require government oversight. For a small contractor, that boundary matters long before a shipment leaves the building. It affects engineering files, service work, vendor access, and the cloud systems your CMMC plan depends on.

The starting point is the U.S. Munitions List (USML). If an item, software function, or related service falls under a USML category, ITAR applies. That is the first classification decision a contractor needs to get right, because every downstream control depends on it.

In practice, most companies encounter ITAR in three working categories:

Category	What it means	Example
Defense articles	Physical items subject to ITAR control	A component, assembly, sensor, or specialized part tied to a defense system
Technical data	Controlled information related to a defense article	Drawings, models, instructions, or test documents tied to a USML item
Defense services	Assistance provided in relation to controlled items	Training, integration support, maintenance guidance, or operational instruction

ITAR does not stop with the hardware. It follows the article, the know-how around it, and the services that support it.

Why this matters in daily operations

Small businesses usually feel ITAR first through process friction, not legal theory. Engineering wants to share a model with a supplier. IT wants to use a cloud platform to meet CMMC logging and access control requirements. Program managers want outside support for implementation or administration. Each of those decisions can be fine, or can create an export control problem, depending on what is being handled and who can touch it.

That is where ITAR and CMMC intersect for SMBs in a very practical way. CMMC and NIST SP 800-171 require you to protect controlled data with access control, auditing, configuration management, and incident response. ITAR adds a separate question: does your security architecture also prevent unauthorized foreign access to controlled defense information and related services? A system can be secure enough for a CMMC assessment and still be the wrong system for ITAR data if hosting, support access, or administrator privileges are not tightly scoped.

A common mistake: a company buys a cloud tool with good security features, assumes the problem is solved, and only later asks whether the provider’s support model, administrative backend, or data residency creates ITAR exposure. By then, the tool is embedded in operations.

The concepts that drive compliance decisions

A workable ITAR program starts with a few core concepts:

Classification comes first. You need a defensible decision on whether the item or service falls under the USML.
Control follows access. The compliance question is often about who can see, receive, administer, or support the controlled environment.
Authorization matters. Some transfers, disclosures, and services require approval from the Department of State before they occur.
Records matter. If you cannot show how you classified the item, restricted access, and handled transfers, you will have a hard time defending your program.

Employee access is usually where policy meets reality. Teams that need a practical baseline should review ITAR requirements for employees before they start assigning system roles, admin privileges, or file access in shared environments.

Who must comply

ITAR does not stop at the prime contractor. It follows the work.

If your company manufactures a component, writes code tied to a defense system, repairs a controlled assembly, analyzes test results, or stores technical data for a customer, you may be inside the compliance boundary. Many small businesses miss this because they do not see themselves as arms exporters. The regulation cares less about your self-description than about what you handle.

A prime may have the government relationship, but the subcontractor often has the drawing, the process sheet, the test record, or the assembly know-how. That is enough to create exposure. ITAR obligations commonly flow down to:

Manufacturers and fabricators producing controlled parts
Engineering firms holding drawings, models, or specs
Software teams working with defense-related technical information
Service providers supporting maintenance, testing, or modification
Subcontractors and consultants who receive controlled files from a customer

The deciding question is not “are we a defense company?” It is “do we possess or provide controlled defense items, data, or services?”

Who counts as a U.S. person

One of the most important ITAR concepts is the U.S. person standard. Technical data access is restricted to U.S. persons, defined under 22 CFR 120.62 as citizens, permanent residents, or protected individuals. Violations can result in fines up to $1 million per violation under 22 CFR 127.1, plus debarment from federal contracts.

That sounds straightforward until you apply it to real workplaces. A foreign national employee in your U.S. office. A contractor on a help desk team. A cloud support technician outside the United States. A shared engineering screen during a meeting. These are not edge cases. They are normal business conditions that can create a deemed export if controlled technical data is disclosed without authorization.

A deemed export is still an export, even if nobody crossed a border and nothing left the building.

The mistake SMBs make most often is focusing on intent. Regulators focus on access. If a non-U.S. person can open the file, administer the system, recover the mailbox, view the screen, or receive the attachment, you may already have a problem. Employee screening, role-based permissions, and documented handling rules matter as much as legal review.

How ITAR and CMMC relate

ITAR and CMMC show up in the same conversation, but they are not the same thing.

ITAR tells you who may have access to certain defense-related items and data. CMMC tells you how systems must protect sensitive information in the defense supply chain. One is focused on export control. The other is focused on cybersecurity maturity and evidence.

Use a facility analogy. ITAR is the rule about who is allowed in the room. CMMC, built around NIST SP 800-171 for many contractors, is about the locks, alarms, logs, visitor controls, and response procedures around that room. You need both if the room contains controlled defense information.

A practical mapping looks like this:

Requirement area	ITAR focus	CMMC and NIST focus
Access	Whether non-U.S. persons can access controlled data	Whether access is restricted, authenticated, reviewed, and logged
Storage and handling	Whether controlled data is treated under export rules	Whether data is protected in systems with required safeguards
Physical controls	Whether facilities and handling meet export-related obligations	Whether broader security practices are implemented and documented
Audit readiness	Whether you can demonstrate proper control of exports	Whether you can prove implementation of required controls

NIST SP 800-171 provides 110 baseline security requirements. ITAR adds physical and handling mandates that NIST does not fully cover, including facility security against unauthorized access and special markings on USML data. A company can document strong cybersecurity controls, pass internal reviews, and still have ITAR-specific gaps because those export-boundary controls were never documented.

If your company handles both CUI and ITAR-controlled technical data, treat compliance as a combined operating problem:

Classify the data correctly
Separate who may access it from how systems secure it
Confirm your cloud environment supports both
Document physical, administrative, and technical controls together

Passing a cybersecurity assessment will not save you if your export controls are weak. Export discipline will not save you if your systems cannot support CMMC evidence. Small contractors preparing for third-party review should also understand how evidence is examined in practice. This primer on what to expect in a CMMC compliance assessment helps teams connect policy language to actual audit behavior. For the related question of how CMMC and FedRAMP fit together, see CMMC vs FedRAMP.

Registration, licensing, and recordkeeping

Registration with the Directorate of Defense Trade Controls (DDTC) is the starting point for companies that manufacture, export, or broker covered defense articles or services. It tells the government who you are and what kind of defense-related activity you are in. It does not authorize exports, technical data releases, or defense services by itself.

That distinction matters in daily operations. Companies sometimes register with DDTC and assume they are cleared to send drawings, discuss controlled work with a subcontractor, or give a foreign person access to a project folder. Registration does not give that permission. The authorization question still has to be answered transaction by transaction, based on the data, the recipient, the location, and the activity.

Registration and licensing serve different purposes

Licensing sits closer to the work itself. It applies where ITAR requires specific approval for an export, reexport, retransfer, technical data release, or defense service. The practical mistake is treating licensing as a legal formality handled after the engineering team has already shared files or started technical conversations.

That sequence creates avoidable exposure. A workable process uses a gate before any transfer or access is granted. Someone has to confirm what the item or data is, whether ITAR applies, whether an exemption is available, whether authorization is required, and what records must be kept to support that conclusion. If you also support CMMC-scoped programs, tie that gate to your access control workflow so export decisions and system permissions match.

Recordkeeping is what regulators and primes will test

Weak recordkeeping is where otherwise decent programs fail. Reviewers do not care that your team meant well. They care whether you can show the classification decision, the approval path, the access history, the training record, and the retained transaction file.

Keep records that answer basic operational questions fast:

Classification files: why the item, software, or technical data was treated as ITAR-controlled
Authorization records: what license, exemption, or internal determination applied
Access logs: who could access the data, when access was granted, and who approved it
Training records: who completed training, what was covered, and when refreshers occurred
Transfer history: what was sent or disclosed, to whom, by what method, and under what authority
Retention procedures: where records live, how long they are kept, and how they are retrieved during an audit or customer review

For small contractors, this is also where ITAR, CMMC, and cloud decisions meet. If your file sharing platform cannot give you clean access history, controlled permissioning, and defensible admin boundaries, your recordkeeping burden gets heavier fast. Teams still relying on consumer-grade collaboration habits should review how safe Google Drive is for handling CUI before assuming the same environment can support export-controlled workflows.

Administrative control has to be assigned

Shared responsibility fails unless one person owns the calendar, the filings, the authorization records, the training schedule, and the retention process. That person does not need to do every task personally. They do need the authority to stop a transfer until the company has answered the export question and captured the evidence.

If a prime contractor or regulator asks “show me why this disclosure was allowed” and your team starts searching inboxes, your program is not under control. Build a system that can produce the answer in minutes.

Common cloud pitfalls

The fastest way to misunderstand ITAR is to assume your ordinary business stack is compliant by default. It usually is not.

Small contractors often inherit standard cloud platforms because they are familiar, cheap, and easy to deploy. Then defense work arrives, and the company tries to layer policy on top of tools that were never selected for export-controlled workloads.

The issue is not just storage location. It is the full access path. A platform may store data in the United States and still create risk if administration, support, replication behavior, or integrated services permit access by non-U.S. persons. The phrase “ITAR compliant cloud” gets abused in marketing. Compliance depends on configuration, administrative boundaries, and provider operating model.

Common problem areas include:

Global admin access: provider personnel outside the U.S. may have support or backend visibility
Broad sharing defaults: file links and inherited permissions spread too far
Mixed-use tenants: commercial and controlled data sit in the same environment with weak segmentation
Unvetted integrations: third-party apps connect to mailboxes, drives, or collaboration spaces
Poor migration planning: old files move into new systems without classification or access cleanup

Standard commercial deployments of Microsoft 365 or Google Workspace are not appropriate for ITAR workloads without careful review of access, support, residency, and administrative control. The dangerous setup is not the obviously insecure one. It is the polished commercial platform that works great for normal business and quietly violates export assumptions in the background.

Small contractors usually do better when they choose platforms and processes built around defense constraints from the start. In practice, that means evaluating whether your environment supports:

US-only data residency
Administration by U.S. persons
Granular permissions tied to roles
Audit-friendly logging and e-discovery
Controlled email and file handling in one policy model

What does not work is trying to bolt export controls onto a loosely governed collaboration stack after the fact. That approach creates exceptions, side channels, and confusing workarounds. People always choose the easier path under deadline pressure.

ITAR compliance self-check

If you cannot answer these clearly, your program needs work:

Have we determined whether our products, components, or data touch the USML?
Do we know which files count as technical data and where they live?
Is access restricted to the right people, including employee, contractor, and admin access?
Have we addressed deemed export risk in offices, meetings, support workflows, and cloud systems?
Are DDTC registration, licensing decisions, and compliance ownership clearly assigned?
Can we produce training, access, and handling records without scrambling?
Do our CMMC and NIST 800-171 efforts align with our ITAR obligations, or are they running as separate projects?
Are our email, storage, and collaboration tools appropriate for export-controlled data?
Have we reviewed subcontractors, MSPs, and cloud providers for unauthorized access risk?
Would we be comfortable explaining our controls to a customer, auditor, or regulator today?

What to do next

Do not try to fix everything at once. Start in this order:

Run a formal internal assessment. Inventory controlled data, systems, users, and vendors.
Assign one accountable owner. Someone needs authority to coordinate legal, IT, HR, and operations.
Get export counsel involved early. Classification and licensing mistakes are expensive to unwind.
Align ITAR with CMMC planning. Do not let export controls and cybersecurity mature on separate tracks.
Evaluate your cloud stack thoroughly. If your tools create doubt around residency, admin access, or auditability, treat that as a business risk, not a technical preference.

The companies that handle ITAR well do not rely on heroic effort. They build repeatable controls that survive normal workdays, employee turnover, subcontractor changes, and customer scrutiny.

The bottom line

ITAR compliance is not a label you stamp on a folder. It is an operating constraint that touches people, systems, and hosting decisions every day. For small defense contractors, the practical work is identifying controlled data, restricting access, choosing systems that support both export controls and CMMC evidence, and documenting decisions well enough that a prime, regulator, or auditor can verify them quickly.

If your team needs to replace a patchwork of email, file storage, and collaboration tools with a U.S.-hosted environment built for defense work, that is what we are building at IRONKEEP.