ITAR Technical Data Definition: 22 CFR 120.33 Explained

Most ITAR problems I see start with a simple misunderstanding: someone thinks "controlled" means a physical part in a crate. In practice, the file that describes how to build the part is often the more regulated item, and it travels by email, shared drive, and cloud sync without anyone noticing. The definition that governs that file is 22 CFR 120.33, the section that defines technical data.

This guide walks through that definition piece by piece, covers what it excludes, and then gets practical: how to decide whether a given document is ITAR technical data, and what to do with it once you know.

Where Is "Technical Data" Defined in the ITAR?

Technical data is defined in 22 CFR 120.33. If you are reading older guidance or contracts that cite 22 CFR 120.10, that is the former home of the definition. The State Department reorganized Part 120 in 2022, and the definitions were renumbered and consolidated, with technical data landing at 120.33.

The related definitions you will need alongside it are:

• Defense article (22 CFR 120.31), which includes technical data recorded or stored in any physical form, models, mockups, or other items that reveal technical data directly relating to the item.
• Defense service (22 CFR 120.32), which covers furnishing assistance, including training, to foreign persons in the design, development, production, and similar activities for defense articles, and also the furnishing of technical data to foreign persons.
• Public domain (22 CFR 120.34), which is the main carve-out.
• Export (22 CFR 120.50) and release (22 CFR 120.56), which describe how technical data actually becomes a regulated transfer.

Technical data is a defense article. That single fact explains why the same registration, licensing, and recordkeeping obligations that apply to hardware apply to a drawing set.

What Does 22 CFR 120.33 Actually Say?

I am paraphrasing here, so read the regulation text itself before you rely on any summary, mine included. The definition has four parts.

1. Information required for the lifecycle of a defense article

The core of the definition is information, other than software, that is required for the design, development, production, manufacture, assembly, operation, repair, testing, maintenance, or modification of defense articles. The regulation specifically names blueprints, drawings, photographs, plans, instructions, and documentation as forms this information can take.

Two words in that sentence do most of the work. "Required" means the information is needed to do the activity, which is why generic background material usually falls outside the definition. And the list of lifecycle activities is broad: it reaches beyond building the item to operating, repairing, and modifying it. A maintenance manual for a USML-listed system can be technical data even though nothing in it tells you how to manufacture anything.

2. Classified information

Classified information relating to defense articles and defense services on the U.S. Munitions List is technical data, as is classified information relating to 600-series items on the Commerce Control List. Classified information is also handled under the National Industrial Security Program, so you may have two sets of rules applying to the same document.

3. Information covered by an invention secrecy order

Information covered by a secrecy order issued under 35 U.S.C. 181 is technical data. This is rare for most companies, but it matters if you work with patent counsel on defense-related inventions.

4. Software directly related to defense articles

Software, as defined in 22 CFR 120.40(g), that is directly related to defense articles is also covered. This is the piece people forget. Source code, firmware, and certain executable code tied to a USML item can be controlled in the same way as a drawing.

What Is Not Technical Data?

The definition excludes some information, and the exclusions matter as much as the inclusions.

• General scientific, mathematical, or engineering principles commonly taught in schools, colleges, and universities.
• Information in the public domain as defined in 22 CFR 120.34.
• Basic marketing information on function or purpose, and general system descriptions of defense articles.
• Telemetry data as defined in the note to Category XV(f) of the USML.

The marketing exclusion is narrower than people hope. A brochure that says what a product does and what it is for is one thing. A datasheet with performance parameters detailed enough to help someone replicate or modify the item is something else, and I would want an empowered official to look at it before it goes on a public website.

How Does the Public Domain Exception Work?

Under 22 CFR 120.34, information is in the public domain only if it has been published and is generally accessible or available to the public. The regulation lists the accepted channels, including:

• Sales at newsstands and bookstores
• Subscriptions available without restriction to anyone who wants to purchase them
• Libraries open to the public
• Patents available at any patent office
• Unlimited distribution at a conference, meeting, seminar, trade show, or exhibition that is generally accessible to the public and in the United States
• Public release in any form after approval by the cognizant U.S. government agency
• Fundamental research in science and engineering at accredited institutions of higher learning in the U.S., where the resulting information is ordinarily published and shared broadly

Two traps come up repeatedly. First, a leak is not publication. If controlled data lands on a forum or a file-sharing site without authorization, it does not become public domain, and your obligations do not disappear. Second, "I found it on the internet" is not a classification argument. The question is whether the information was lawfully published through one of the listed routes, and that is a factual question you can document or cannot.

For defense contractors, the practical route for public release is usually approval through the Department of Defense's prepublication review process, which is the "approval by the cognizant U.S. government agency" in the regulation. Build the lead time into your marketing and conference calendar.

How Does Technical Data Connect to the USML?

Technical data is not controlled in the abstract. It is controlled because it relates to an item on the U.S. Munitions List in 22 CFR 121.1. Most USML categories include a paragraph near the end that captures technical data and defense services "directly related" to the articles listed above it. Category I(i) (firearms) and Category VIII(i) (aircraft) are examples of that structure.

That is why classification of the underlying item comes first. The sequence goes like this:

1. Identify the item the data describes.
2. Determine whether that item is enumerated on the USML, using the category text and its notes and definitions.
3. If it is, determine whether the document is "required" for one of the lifecycle activities listed in 120.33.
4. If both are true and no exclusion applies, the document is ITAR technical data.

If step 2 is uncertain, the formal tools are a self-assessment documented in your files, or a commodity jurisdiction request under 22 CFR 120.4 when the jurisdiction question is genuinely open. For background on how the categories are organized, see our USML categories overview.

One point of nuance: an item that falls under the Export Administration Regulations does not carry ITAR technical data controls, but the related technology may carry EAR controls instead. Jurisdiction decides which regime applies, and getting that wrong is expensive in both directions.

Examples: ITAR Technical Data vs. Not

Treat the table as a starting point for your own analysis and not as a classification decision. The answer for any real document depends on the item, the content, and the exact USML paragraph.

When Does Handling Technical Data Become an Export?

Having technical data is not a violation. Transferring it without authorization is. Under 22 CFR 120.50, an export includes sending or taking technical data out of the United States, and it also includes releasing technical data to a foreign person in the United States, which is the deemed export. Under 22 CFR 120.56, release includes visual or other inspection by foreign persons that reveals technical data, and oral or written exchanges with foreign persons in the U.S. or abroad.

That means these ordinary events can all be exports if the data is technical data and no authorization or exemption applies:

• Emailing a drawing to a supplier in another country
• Giving a foreign national employee access to a shared engineering folder
• Walking a visitor past a whiteboard or a screen showing controlled design data
• Discussing design details on a call with a foreign person
• Carrying a laptop with controlled files on a trip abroad

Authorization for technical data typically comes through a license under 22 CFR Part 125, a technical assistance agreement under Part 124 when defense services are involved, or an applicable exemption. The deemed export side of this is covered in more detail on our deemed exports page.

How Do You Handle ITAR Technical Data in the Cloud?

Cloud environments are where I get the most questions, and they line up with the search interest in this topic. The key rule is 22 CFR 120.54, which lists activities that are not exports. Under 120.54(a)(5), sending, taking, or storing technical data is not an export if it is:

• Unclassified
• Secured using end-to-end encryption
• Secured using cryptographic modules compliant with FIPS 140-2 or its successors, supplemented by software implementation, cryptographic key management, and other procedures and controls in accordance with guidance by the National Institute of Standards and Technology, or by cryptographic means providing security strength at least comparable to 128 bits
• Not intentionally sent to a person in or stored in a country listed in 22 CFR 126.1(d)(1) or the Russian Federation
• Not sent from a country listed in 126.1(d)(1) or Russia

The regulation also requires that the data stay encrypted from originator to intended recipient, with the means of decryption not provided to any third party. That is the part that breaks many cloud arrangements. If the provider holds the keys, or your own administrators can read the data in plaintext, the end-to-end condition is in doubt. The regulation also says that the ability to access technical data in encrypted form does not itself constitute access to the data, so a provider's staff handling only ciphertext is a different situation from staff who can read content.

A practical checklist for cloud use:

1. Confirm which data sets contain ITAR technical data before choosing a platform.
2. Verify that encryption is end-to-end as the regulation defines it, and document who controls the keys.
3. Confirm the cryptographic modules are validated to FIPS 140-2 or its successors.
4. Restrict administrative and support access to U.S. persons where plaintext access is possible.
5. Know where data is stored and where your provider's support staff are located.
6. Keep your configuration documentation, because you will need it if anyone asks how you concluded that 120.54(a)(5) applied.

Note that a vendor's "ITAR compliant" or "government cloud" label is a marketing description. It is not an authorization, and the responsibility for the export stays with the registrant. If you also handle defense contracts that carry DFARS or CMMC requirements, the overlap is worth understanding, and our ITAR vs. CMMC comparison covers where the two diverge.

What Are the Consequences of Mishandling Technical Data?

Violations of the Arms Export Control Act and the ITAR carry civil and criminal exposure. Civil penalties are set under 22 CFR 127.10 and are adjusted for inflation each year, so check the current figure in the Federal Register and not in an article. Criminal penalties under 22 U.S.C. 2778(c) include fines and imprisonment for willful violations.

Many companies that find an unauthorized release have the option of a voluntary disclosure under 22 CFR 127.12, which the State Department treats as a mitigating factor. I would not make that decision without counsel, but I would also not sit on a known problem.

How Do You Classify a Document as ITAR Technical Data? A Working Process

Here is the process I walk clients through. It is meant to be run by an engineer and a compliance lead together, since neither one alone has the whole picture.

1. Identify the underlying item. What defense article or potential defense article does this document describe?
2. Classify the item. Read the USML category in 22 CFR 121.1, including notes and definitions. Check for "specially designed" language, which is defined in 22 CFR 120.41. Record your reasoning.
3. Resolve jurisdiction doubt. If you cannot decide between USML and CCL, consider a commodity jurisdiction determination under 22 CFR 120.4.
4. Apply the 120.33 test. Is the information required for design, development, production, manufacture, assembly, operation, repair, testing, maintenance, or modification? Is it software directly related to the article?
5. Check exclusions. General principles, public domain under 120.34, basic marketing, general system descriptions.
6. Mark and log. Label the document and record the classification, the date, and who made the decision.
7. Control access. Limit access to U.S. persons unless there is authorization, and put the controls in a written technology control plan. Our post on technology control plans goes into the format.
8. Keep the records. 22 CFR 122.5 sets a five-year retention period for records of the kind it describes.
9. Reassess when things change. A USML revision, a design change, or a new use can change the answer.

Common Mistakes With ITAR Technical Data

• Treating only drawings as technical data. Instructions, documentation, test procedures, and software count.
• Assuming a foreign national colleague in the U.S. is outside the rules. Release to a foreign person in the U.S. is a deemed export.
• Believing a document is public because it is online. Only lawful publication through the routes in 120.34 counts.
• Relying on a vendor's cloud label. Check the end-to-end encryption conditions yourself.
• Not tracking the data after classification. A classification that sits in one engineer's head will not survive turnover.
• Skipping the reclassification review after USML changes.

In my view, the companies that handle this well share one habit: they decided early where the controlled data lives, who can touch it, and how they would prove it. The ones in trouble usually had good intentions and no map.

If you are working through classification for a specific product line or deciding how to structure a cloud environment, the first useful step is a short inventory of what technical data you actually hold. From there, the questions get a lot more concrete, and a lot easier to answer.

Last updated: 2026-10-26

Frequently Asked Questions

What is the definition of technical data under 22 CFR 120.33?

Under 22 CFR 120.33, technical data is information, other than software, required for the design, development, production, manufacture, assembly, operation, repair, testing, maintenance, or modification of defense articles. It also includes classified information relating to defense articles, information covered by an invention secrecy order, and software directly related to defense articles.

Is 22 CFR 120.33 the same as the old 22 CFR 120.10?

Yes. The definition of technical data was formerly in 22 CFR 120.10. After the State Department reorganized Part 120 in 2022, the definition moved to 120.33. Older contracts and guidance may still cite 120.10.

Is information on the internet automatically public domain under the ITAR?

No. Under 22 CFR 120.34, information is public domain only if it was published through a recognized route, such as public libraries, patents, open conferences, or government-approved public release. Unauthorized postings of controlled data do not change its status.

Is storing ITAR technical data in the cloud an export?

Not if the conditions in 22 CFR 120.54(a)(5) are met. The data must be unclassified, protected by end-to-end encryption using FIPS 140-2 or successor compliant cryptography (or comparable strength), and not intentionally sent to or stored in listed countries or Russia. If the provider can read the data in plaintext, the exception may not apply.

Does a foreign national employee in the U.S. count as an export of technical data?

Potentially yes. Under 22 CFR 120.50, releasing technical data to a foreign person in the United States is a deemed export. Access needs a license, agreement, or applicable exemption, so access controls should be in place before the person starts.