One Thread, Two Flags: The US-Person Data Boundary for a Foreign-Parented Defense Operation

The sentence that reorganizes this entire problem is short, and most parents hear it for the first time far too late. Under ITAR, your parent is a foreign person with respect to your US subsidiary's technical data. Not a partner with extra paperwork. A foreign person: the same category as any other company abroad that does not hold a license.

The regulation gets there on incorporation, not ownership. A US person includes any entity "incorporated to do business in the United States" (22 CFR 120.62). A foreign person includes any entity "not incorporated or organized to do business in the United States" (22 CFR 120.63). Your Delaware or Massachusetts entity is a US person. Your parent in Ottawa, Brescia, or Stuttgart is a foreign person. The parent owning 100 percent of the subsidiary moves neither one across the line. There is no family exception in the text, because the text never asks about the family.

Executives hear this as an insult to a corporate relationship they spent decades building. It is not. It is a statement about data, and only about data. The parent still owns the company, appoints the board, sets the strategy, and takes the profit. What the parent stops getting automatically is the drawing.

The same instinct shows up around allied status, so it is worth closing now. Every country I serve is a DFARS qualifying country under a reciprocal defense-procurement agreement with the Department of Defense (DFARS 225.003). That status is a procurement preference on end products and components. It does not waive ITAR, it does not waive CMMC, and it does not clear FOCI. Allied status gets your parts through the Buy American analysis. It does not get your parent through the data boundary.

ITAR does define foreign ownership and foreign control for its own purposes, at 22 CFR 120.65. Foreign ownership is more than 50 percent of the outstanding voting securities. Foreign control is the authority or ability to establish or direct general policies or day-to-day operations, and it is presumed where foreign persons own 25 percent or more of the outstanding voting securities unless one US person controls an equal or larger percentage. Those definitions matter to what you tell the Directorate of Defense Trade Controls. They are ITAR's own, and they are not the Defense Counterintelligence and Security Agency's FOCI framework, which runs on separate rules. Keep the two apart, and let export counsel and a DCSA-facing specialist own their halves.

Before you can draw a boundary you have to know what it holds. Two populations of data are in play. They overlap heavily, and most shops misjudge both in exactly the same way: they wait for a marking.

ITAR technical data is information required for the design, development, production, manufacture, assembly, operation, repair, testing, maintenance, or modification of a defense article, including information in the form of blueprints, drawings, photographs, plans, instructions, or documentation (22 CFR 120.33(a)). Read that definition again and notice what is missing from it. There is no marking in it. Technical data is defined by what the information lets someone do, not by whether a stamp landed on the corner of the page. A CAM file nobody labeled is technical data if it is required to make the part.

Covered defense information runs on a parallel logic. Under DFARS 252.204-7012, it is unclassified controlled technical information or other CUI Registry information that requires safeguarding and is either marked or identified in the contract, or "collected, developed, received, transmitted, used, or stored by or on behalf of the contractor in support of the performance of the contract." That second prong needs no marking either.

So the instruction your staff has been living by, protect the marked material, is the wrong instruction. Two regimes, two definitions, and neither one waits for a sticker. Both attach on function and context, which is precisely why they cannot be delegated to whoever handles the stamp.

This is the part that lands hardest in the room. The single biggest obstacle between an allied manufacturer and a DoD contract is usually not the regulation. It is the group IT architecture the parent spent fifteen years standardizing, and is rightly proud of.

Under 22 CFR 120.56(a)(3), technical data is released through the use of access information to cause or enable a foreign person to access, view, or possess unencrypted technical data. Read the verb. Enable. The clause is written on capability, not on intent, and not on whether anyone opened the file. Under 22 CFR 120.56(b), authorization for a release is required in order to provide that access information to a foreign person in the first place. So the question an export lawyer and an assessor both ask is not whether the parent looked. It is whether the parent could be enabled to reach it.

Five patterns account for most of what I find on a first walk:

The first idea every capable CTO brings to this problem is encryption, and the instinct is right. ITAR gives encryption a real carve-out. That carve-out is both more useful and more narrow than nearly everyone believes, and the gap between those two readings is where programs get expensive.

Here is what it grants. Under 22 CFR 120.54(a)(5), sending, taking, or storing technical data is not an export when the data is unclassified, secured using end-to-end encryption, and secured using cryptographic modules compliant with FIPS 140-2 or its successors, or by other cryptographic means providing security strength at least comparable to the minimum 128 bits achieved by AES-128, and not intentionally sent to a person in or stored in a country proscribed under 22 CFR 126.1, and not sent from one. The rule even settles the routing anxiety directly: data in transit via the internet is not deemed to be stored in a country it transits. And 22 CFR 120.54(c) states plainly that the ability to access technical data in encrypted form meeting those criteria does not constitute a release or an export.

Now read the definition the carve-out runs on. For this purpose, end-to-end encryption requires that the data not be in unencrypted form between the originator and the intended recipient, and that "the means of decryption are not provided to any third party" (22 CFR 120.54(b)(1)). The intended recipient has to be the originator, a US person in the United States, or a person otherwise authorized to receive the technical data (22 CFR 120.54(b)(2)).

That is where it collapses for most group architectures. Access information is defined at 22 CFR 120.55 as information allowing access to encrypted technical data in unencrypted form, and the regulation names the examples itself: decryption keys, network access codes, and passwords. Provide those to a foreign person and 22 CFR 120.56(b) requires authorization to do it. Use them to enable a foreign person to reach unencrypted data and you are inside 22 CFR 120.56(a)(3), a release. And 22 CFR 120.50(a)(6) makes the release of previously encrypted technical data an export in its own right.

So the architecture falls out of the text, and it is the thesis of this paper. The ciphertext can cross the group's infrastructure. The keys cannot cross to the parent. Your parent can hold the storage, carry the traffic, own the pipe, and run the replication, so long as what it holds stays unreadable to it and the means of decryption stay inside the US-person boundary. That single asymmetry is what lets one company keep one IT relationship and two flags.

Two cautions, and I mean both of them. The conditions in 22 CFR 120.54(a)(5), plus the definition in (b), are conjunctive: they all have to hold, on your actual facts, at the same time. And whether your specific architecture qualifies is a legal determination your export counsel makes, not one an operations architect makes for you. My job is to build the environment so that determination is clean, documented, and easy to answer yes to. The determination itself stays with counsel, and I say that in the first meeting rather than the last.

Most foreign-parented shops run ITAR and CMMC as two projects, with two vendors and two budgets, and often a third for the network build. They are one build. Understanding why saves the six months these programs usually lose.

NIST SP 800-171 is citizenship-blind. Its access controls ask whether a user is authorized. They do not ask what passport the user holds. That is not a gap in the standard, it is a division of labor. ITAR is the regime that decides who can be authorized for export-controlled technical data. NIST SP 800-171 is the machinery that enforces the decision, logs it, and generates the evidence. CMMC Level 2 is the Department of Defense checking that the machinery is real.

Which fixes the sequence. ITAR draws the boundary. The 800-171 controls hold it. The assessor scores it. Build them in that order and each one feeds the next: the access matrix you write for the export question becomes the access control the assessor tests. Build them as three parallel vendor conversations and you get three answers that contradict each other at the gate.

One definition inside DFARS 252.204-7012 ends the most common plan I hear, which is that the group IT organization will simply run the US site the way it runs every other site. A covered contractor information system is defined as "an unclassified information system that is owned, or operated by or for, a contractor" and that processes, stores, or transmits covered defense information. Operated by or for. If your parent's IT department operates your US systems, those systems are covered contractor information systems, and the parent's environment is not outside your assessment. It is inside it. Handing the work to the group does not move the obligation offshore. It pulls the group into scope.

The clause carries the rest of the shape you have to plan for:

Everything so far is easy to picture as an office problem. File shares, mailboxes, an ERP, a helpdesk. That framing is precisely how foreign-parented shops fail, because the controlled data does its most dangerous traveling on the floor.

The moment a drawing leaves the ERP and becomes a work instruction at the machine, technical data has crossed from a system you treat as protected into a system you have historically treated as a machine rather than a computer. The CAM file on a shared floor PC. The program sitting on the controller. The historian logging process data tied to a controlled part, then syncing to a server the whole office can reach. For a domestic shop, that crossing is already the most overlooked control point in the building. For a foreign-parented shop, every one of those crossings carries a second question stacked on top of the first: not only whether this is controlled, but who at the group can reach the system it landed on.

The example that makes this concrete is not a villain. It is your best automation engineer. A line goes down in Nashua at 2 a.m. The parent's controls engineer in Turin commissioned that exact cell four times and can have it running in twenty minutes over a remote session. He is a foreign person. The controller holds a program derived from controlled technical data. That remote session is the entire regulation in one screen share, and the supervisor on shift is going to make that call at 2 a.m. unless the architecture already made it for him.

So the boundary gets designed into the floor rather than drawn around it. Segment the OT network so a reachable office endpoint is not a path to a controller. Route the necessary hand-offs through a controlled, logged conduit instead of a USB drive. Decide in advance, in writing, which cells hold controlled programs and who may reach them, so the 2 a.m. decision is a lookup instead of a judgment call. And where the group's engineering support genuinely is the right answer, get it authorized properly through counsel while the line is still running, rather than discovering the question during an incident.

This is why I treat the data border and the operating model as one design problem rather than two. The same converged thread that gives an assessor a single auditable path from the contract to the cut is the thread that gives the P&L an honest view of what the floor is actually doing. Built once, it is the auditor's evidence and the owner's instrument panel. Built twice, it is two systems that disagree.

Every parent hears the US-person data boundary as a wall between itself and the company it owns. That reading kills more of these projects than any control does, and it is wrong. Built properly, the parent loses almost nothing it actually needs.

Go back to the definition. ITAR technical data is information required to design, make, test, repair, or modify a defense article, and 22 CFR 120.33(b) expressly excludes basic marketing information on function or purpose and general system descriptions. Consolidated financials are not technical data. Order intake, backlog, on-time delivery, scrap rate, throughput, headcount, capex, quality metrics, and the SQDIP board are not technical data. Almost nothing a parent's board actually reviews on a Tuesday is technical data.

So the design task is precise, and it is an operating task rather than a legal one: give the parent every number it is entitled to, and none of the drawings it is not. In practice the reporting layer is built to cross the boundary and the engineering layer is built not to. That distinction is the whole architecture, and it is why this gets decided at design time, when it costs a conversation, instead of at assessment time, when it costs a re-platform.

I am the operations partner, and I am precise about the edge of that. I stand up and run the compliant US operation: the floor, the operating model, the IT and OT build, the US-person data boundary, and the readiness evidence for the gate you are racing. Entity formation, ITAR and DDTC registration, FOCI mitigation, license and exemption determinations, and CFIUS questions stay with your corporate counsel and your export-control counsel. I coordinate with them and own the operating outcome.

That line is not modesty, it is the reason the build holds. Whether a specific architecture qualifies for the 22 CFR 120.54 carve-out, whether a specific transfer needs a license, whether your ownership structure triggers a DDTC notification: those are legal determinations with legal consequences. An operations architect who answers them for you is selling you a liability with a confident voice. What I do is build the operation so those determinations are clean, documented, and easy, and so the evidence exists before anyone asks for it.

This build is not theoretical and it is not rare. In April 2026, American Rheinmetall achieved CMMC Level 2 certification across its US production facilities: a German-parented US operation holding the posture, on the public record. I have been the foreign parent's operator in the US myself, running an Italian sensor multinational's North America operations, and I am standing up US defense manufacturing operations for a Canadian-parent subsidiary now. The path exists and people are walking it. What is scarce is the operator who walks it with you. Six tiers of firms will help a foreign manufacturer enter the US market, from FOCI counsel to Big-4 structuring to site selection to CMMC IT vendors, and every one of them hands you a document, a building, or a certificate. The DoD Chief Information Officer's Standards Guide for Foreign Partners is the closest thing to an official synthesis, and it is a controls overlay rather than an operator's sequence. Someone still has to stand up and run the operation. That layer is the work, and it is the one I own.

The bottom line is the title. Your parent is a foreign person with respect to your US subsidiary's technical data, so the drawings, the derived files, and the keys stay inside a US-person boundary while the ciphertext, the financials, and the governance cross it freely. ITAR draws that boundary, NIST SP 800-171 holds it, and CMMC Level 2 proves it holds. Build the three as one thread and the assessor finds the controls already running, because they are how the work gets done. Build them as three vendor conversations and you learn which one was wrong at the gate, with the contract on the table. One thread. Two flags.