ITAR and ISO 27001: Aligning Export Control with InfoSec

I get some version of this question from nearly every defense contractor and dual-use manufacturer I work with: "We're ITAR registered. Do we still need ISO 27001?" The honest answer is that the two frameworks solve overlapping but not identical problems. Companies that treat them as separate projects usually end up building two access control systems, two audit logs, and two incident response plans that don't talk to each other.

ITAR, the International Traffic in Arms Regulations at 22 CFR Parts 120-130, controls the export of defense articles, defense services, and technical data. ISO/IEC 27001:2022 is a management system standard for information security. Neither one was written with the other in mind. But technical data under 22 CFR 120.33 is information, and information security is exactly what ISO 27001 governs. Once you see that overlap, the question shifts from "which framework do we pick" to "how do we build one control environment that satisfies both."

One note on citations before we go further: DDTC substantially renumbered ITAR's definitions in a rule that took effect September 6, 2022 and was finalized February 27, 2023. If you've read older ITAR compliance articles citing 120.10 for technical data or 120.17 for the export definition, those section numbers now point to different provisions. This article uses the current numbering throughout.

What ITAR Actually Requires of Your Information Systems

ITAR does not hand you a checklist of firewall rules or encryption standards. It regulates conduct: who may access, use, or transfer technical data tied to a defense article on the U.S. Munitions List.

The rule that trips up more IT and engineering teams than any other is the deemed export concept inside the export definition at 22 CFR 120.50. That provision treats the release of technical data to a foreign person inside the United States as an export to every country where that person holds citizenship or permanent residency, even if the data never crosses a border. Put a foreign national engineer into a shared drive with unrestricted access to ITAR-controlled CAD files, and you've exported that data. It doesn't matter that everyone works in the same building in Ohio.

"Foreign person" is defined at 22 CFR 120.63; "U.S. person" at 22 CFR 120.62. That distinction is the whole hinge of deemed export risk, and it's why an access control system built around job role alone will always miss it.

The practical compliance burden that follows lands almost entirely on access control, data segregation, and audit trail, which happen to be core disciplines of an information security management system. A company registered with the Directorate of Defense Trade Controls under 22 CFR 122.1 is expected to demonstrate real, working controls over who can reach its technical data, not a policy binder nobody has opened since the registration renewal that produced it.

Where ISO 27001:2022 Picks Up the Work

ISO/IEC 27001:2022 organizes its Annex A controls into four themes, organizational, people, physical, and technological, for 93 controls total. A meaningful slice of those map directly onto what a defense contractor needs to demonstrate for ITAR purposes:

• Clause 6.1.2 (information security risk assessment) is the natural place to document deemed export risk from foreign-person access, third-party contractors, and cloud storage of technical data.
• Clause 8.1 (operational planning and control) ties your risk treatment plan to actual operating procedures, the same procedures a technology control plan describes in export-control language.
• Annex A 5.15, 5.18, and 8.3 (access control, access rights, and information access restriction) give you the mechanism to enforce nationality-based access segmentation instead of an honor system or a spreadsheet someone updates when they remember to.
• Annex A 8.12 and 5.14 (data leakage prevention and information transfer) address where technical data actually leaks: email attachments, personal cloud storage, and unmanaged contractor laptops. None of that shows up on an org chart, but all of it is a deemed export waiting to happen. In my experience running technical data flow assessments, this is where the biggest gap usually sits.
• Annex A 7.4 and 7.7 (physical security monitoring and clear desk/clear screen) matter too, since a lot of ITAR technical data still exists as printed drawings on a shop floor. A locked door is a control just as much as a role-based permission is.

The Compliance Overlap, Mapped

That table is not a certificate of compliance. ISO 27001 certification does not, by itself, satisfy your ITAR obligations, and no accredited certification body will tell you otherwise. What it gives you is a management system, complete with internal audit under clause 9.2 and management review under clause 9.3, that can carry the operational weight your access control plan claims to have.

Where NIST 800-171 and CMMC Fit In

If you sell to the Department of Defense, you're probably also holding Controlled Unclassified Information under DFARS clause 252.204-7012, which points to NIST SP 800-171 as the required security baseline. ITAR technical data and CUI aren't the same legal category, but they frequently live on the same servers, get accessed by the same engineers, and get protected, or not, by the same firewall rules.

Here's how the three frameworks actually differ in scope and enforcement:

I've seen companies build a NIST 800-171 program for CMMC, a separate ISO 27001 program for customer assurance, and a separate technology control plan for DDTC, each with its own risk register, with none of the three teams comparing notes. That's not thoroughness. That's three audit-prep cycles for one set of engineering drawings.

The fix isn't picking one framework and abandoning the others. Your ITAR obligations don't disappear because you're ISO 27001 certified, and a DoD contract clause doesn't disappear because you have a technology control plan. The fix is one control set, mapped once, that different auditors can each check against their own citation.

Building a Unified Control Environment

I generally walk clients through the same four moves, in this order, when consolidating export control and information security into one operating system.

1. Classify the data first. You can't protect technical data you haven't labeled as technical data. Annex A 5.12 (classification of information) gives you the mechanism; ITAR gives you the category to classify against. Every engineering drawing, bill of materials, source repository, and test report tied to a Munitions List article needs a label your access control system and your export compliance officer both recognize.

2. Build access control around nationality, not just role. Most commercial access models ask whether a person's job requires the data. ITAR asks a second question most IT teams have never had to ask: is this person a U.S. person under 22 CFR 120.62? Your identity and access management system needs a citizenship-status field, and your onboarding and offboarding procedures under Annex A 6.1 and 6.5 need to trigger a permissions review the moment that status changes, not at the next scheduled audit.

3. Close the transfer gaps. Annex A 8.24 (use of cryptography) governs encrypted transfer and storage of technical data. Pair it with a hard rule: no ITAR technical data leaves the network through an unmanaged channel. That means locking down personal cloud storage, restricting USB write access on engineering workstations, and auditing outbound email for CAD and drawing file types. None of this is exotic; it's data loss prevention work most mature security programs already do. ITAR just raises the stakes, since the penalties in 22 CFR 127.1 can include criminal liability, not just a lost contract.

4. Run one internal audit, not three. Clause 9.2 already requires a documented internal audit process with defined criteria, scope, and competent auditors. Extend that same audit cycle to test your ITAR access controls and your CMMC-relevant safeguards in the same pass. One set of findings, one corrective action log under clause 10.2, one story to tell whichever reviewer shows up first: a DDTC compliance officer, a certification body auditor, or a prime contractor's supplier security questionnaire.

Common Failure Points I See in Practice

Three gaps show up more often than any others when I run a technical data flow assessment:

• The unmanaged default. A shared engineering drive with "everyone in the company" permissions is the single most frequent finding. It's a deemed export sitting in plain sight the moment a foreign-person contractor, intern, or new hire gets added to the general employee group.
• The stale control plan. A technology control plan that describes controls the company stopped operating a year ago, because the plan was written once for a registration renewal and never touched again. An ISO 27001 management system, with its mandatory management review and audit cadence, is specifically built to catch that kind of document rot. If your control plan and your ISMS documentation aren't reviewed on the same cycle, one of them is quietly going stale.
• Physical security treated as a facilities problem. A locked server room means nothing if the loading dock has printed engineering drawings sitting on a cart where a delivery driver can see them. Annex A 7.4 and 7.7 exist because information security doesn't stop at the network boundary, and neither does export control.

Frequently Asked Questions

Does ISO 27001 certification satisfy ITAR compliance obligations?

No. Certification proves your management system meets an international standard; it does not substitute for DDTC registration, an export license, or any control ITAR requires by regulation. It does give you an auditable system that can carry and evidence those controls.

Do subcontractors handling ITAR-controlled technical data need their own ISO 27001 certification?

Not by law. ITAR obligations flow to whoever holds and transfers the technical data, regardless of certification status. In practice, primes increasingly require ISO 27001 from subcontractors as a supply-chain condition, so a subcontractor without a mature information security program can find itself locked out of defense work even while remaining technically ITAR-compliant on paper.

Is ITAR technical data the same thing as CUI under NIST SP 800-171?

No. They're separate legal categories: technical data is defined at 22 CFR 120.33, while CUI is scoped by DFARS 252.204-7012 and the CUI Registry. A single document can qualify as both. Because no single certification or registration covers both categories, the control architecture, not the paperwork, is what has to unify them.

Who should perform the combined ITAR/ISO 27001 internal audit, and how often?

Clause 9.2 requires internal auditors who are independent of the process they're auditing and competent to evaluate it, which for this combined scope usually means someone who understands both information security controls and export control obligations. Most of the manufacturers I work with run this combined audit annually, timed a few months ahead of their DDTC registration renewal so any findings get corrected before that renewal, not after.

If you're carrying an ITAR registration and an information security program that customers or primes are now asking you to formalize, the work is almost never starting from zero. It's usually consolidating controls you've already half-built under two different names, and giving them one management system to live in.

For companies building a defense-related ISO 27001 program alongside ITAR obligations, our ISO 27001 consulting services and ITAR compliance consulting work are built around exactly this kind of dual-framework alignment.

Last updated: 2026-08-14