Technology Control Plan: Template & Guide

TL;DR: A Technology Control Plan (TCP) is the document a lab or institution puts in place to keep a specific ITAR- or EAR-controlled item, technology, technical dataset, or piece of software away from unauthorized access — most often access by a foreign national who is not a licensed, approved participant. This guide covers when a TCP is actually required (with a procurement-focused lens: equipment purchases, donated instruments, and vendor-supplied technology are common triggers), a section-by-section template you can adapt, a worked illustrative example, and the ITAR-specific details that differ from a general EAR-based plan. For the core definition, see CASRAI’s Technology Control Plan (TCP) dictionary entry; this guide focuses on building and using one.

What a Technology Control Plan actually is

A Technology Control Plan is item- and project-specific, not a general compliance policy. It names the specific controlled technology (by ITAR US Munitions List category or EAR Export Control Classification Number, where applicable), names every individual authorized to access it by name and citizenship, and lays out concrete physical, IT, and administrative safeguards that keep access limited to authorized US persons and to specifically approved, licensed foreign nationals. It sits downstream of a classification decision: an export control or research security office first determines whether an item, dataset, or piece of equipment is subject to ITAR or EAR jurisdiction, and whether an exclusion or license exception — most commonly the fundamental research exclusion rooted in NSDD-189 — removes it from restriction. Only when that review concludes the item is genuinely controlled, with no exclusion or exception fully applying, does a TCP become the operational mechanism for managing the resulting access risk.

The risk a TCP is built to prevent is most often a deemed export: the release of controlled technology or technical data to a foreign person inside the United States, which US export regulations treat as an export to that person’s country of citizenship even though nothing physically leaves the country.

When a Technology Control Plan is required

A TCP is typically triggered by one or more of the following:

A foreign national will have access to a controlled item. Someone who is not a US citizen, lawful permanent resident, or other protected individual will have physical, visual, electronic, or oral access to controlled technology or technical data, and no deemed-export license exception applies.
Defense-related or dual-use equipment is being acquired. This is the trigger procurement and lab-operations staff run into most: a new instrument, component, or piece of software is being purchased, leased, or received as a donation, and it (or its underlying technical data/source code) is listed on the ITAR US Munitions List or has an EAR Commerce Control List entry with restricted destinations, end-uses, or end-users. Procurement and export-control review should happen before the item arrives on site, not after — a TCP drafted retroactively, once a foreign national already has access, does not undo the deemed export that already occurred.
An export license itself requires it. A BIS (EAR) or DDTC (ITAR) export license or license exception is issued with a TCP as an explicit condition of approval.
A sponsor or contract removes fundamental-research protection. A federal or industry sponsor imposes publication restrictions, foreign-national access restrictions, or prior-review rights that take the project outside the fundamental research exclusion, even though the underlying research would otherwise qualify.

Conversely, a project with no controlled items on it and no nationality-based access restriction generally needs no TCP at all — most open, publication-intended university research stays inside the fundamental research exclusion and never triggers export-control jurisdiction in the first place. Requiring a TCP for every foreign national in every lab, regardless of what technology is actually present, is a common overcorrection that creates unnecessary administrative burden without reducing real risk.

How to build a Technology Control Plan: step by step

Get a classification determination first. Before drafting anything, the export control office (or research security office) needs to confirm the item/technology is actually ITAR- or EAR-controlled, identify the specific USML category or ECCN, and confirm no exclusion or exception applies. Skipping this step is the single most common cause of TCPs that are either unnecessary or wrongly scoped.
Identify every person who needs access, by name. A TCP lists named individuals, not roles or departments. Each non-US-person listed needs to be screened against restricted/denied-party lists (Treasury OFAC’s SDN list, BIS’s Entity List and Denied Persons List, and DDTC’s debarred parties list, at minimum) before being added.
Define the physical security controls. This is typically a locked, badge- or key-controlled room or cabinet, restricted-access signage, a visitor log for anyone entering the space, and a documented process for what happens if an unauthorized person needs temporary access (e.g., escort requirements).
Define the IT/information security controls. Encryption at rest and in transit, a prohibition on sending controlled technical data over unencrypted email or consumer cloud storage, access logging, and a documented secure-destruction or return process at project close-out.
Build in training and acknowledgment. Every named individual should sign a briefing acknowledgment — confirming they understand what’s controlled, who may access it, and the consequences of unauthorized disclosure — before they’re granted access, not after.
Assign ongoing administration. The Principal Investigator is typically the day-to-day responsible party, with the export control office providing oversight. Build in a periodic (commonly annual) review, and require advance approval before adding personnel or changing scope — a TCP that was accurate at signing but never updated as the team changes is a common audit finding.
Route it for institutional sign-off. Most institutions require the export control officer, and often the institution’s Empowered Official for ITAR matters, to countersign before the TCP takes effect. See CASRAI’s guide to the Empowered Official role for what that sign-off involves.

Technology Control Plan template: section-by-section

The following is a generic structural outline reflecting the elements consistently required across university export-control offices and referenced in BIS guidance on deemed-export license applications. Adapt it to your institution’s actual TCP form rather than treating it as a fixed document — most research security offices maintain their own standardized template and expect it to be used rather than a self-drafted substitute.

Project/technology identification. Project title, PI, sponsor (if any), and a specific description of the controlled item, technology, technical data, or software — including USML category or ECCN.
Classification basis. A short statement of how the classification was determined and by whom, with a reference to the underlying jurisdiction/classification determination on file.
Authorized personnel list. Full legal name, citizenship/immigration status, and role for every individual authorized to access the controlled item — updated whenever personnel change.
Physical security measures. Location, access-control mechanism, signage, and visitor-log procedure.
IT/information security measures. Storage location, encryption requirements, transmission restrictions, and access logging.
Training and acknowledgment. Confirmation that each listed individual has received and signed a TCP-specific briefing before access was granted.
Administration and review. Responsible party, review cadence, and the process for amending the plan.
Approval signatures. PI, export control officer, and (for ITAR items) the institution’s Empowered Official.

Technology Control Plan example (illustrative composite)

The following is a synthesized, illustrative example built to show how the template above applies in practice. It is not drawn from any specific real institution, project, or individual.

A university engineering lab receives a donated spectrometer component whose accompanying technical documentation is subject to an EAR Commerce Control List entry, with license requirements for certain destinations. The lab includes a postdoctoral researcher who is a foreign national from a country not covered by an applicable license exception. Before the component is installed, the export control office classifies the item and confirms a TCP is required. The resulting plan names the specific component and ECCN; lists the PI and lab manager as US-person administrators with full access; lists the postdoctoral researcher as excluded from unsupervised access pending a deemed-export license determination; specifies that the component is stored in a badge-controlled room separate from open lab space; requires all technical drawings to be stored on an encrypted, access-logged institutional server rather than shared drives; and sets an annual review date tied to the postdoc’s continued affiliation. The PI signs a briefing acknowledgment, and the export control officer countersigns before the component is installed.

ITAR-specific Technology Control Plan considerations

ITAR-triggered TCPs carry a few requirements that EAR-only plans don’t:

Empowered Official countersignature. ITAR (22 CFR Part 120 and related provisions) requires institutions engaged in ITAR-controlled activity to designate an Empowered Official with specific authority to sign export authorizations and countersign TCPs — see CASRAI’s Empowered Official guide.
Stricter access-control expectations. DDTC (the ITAR licensing authority) generally expects tighter physical segregation for defense articles and technical data on the US Munitions List than BIS expects for most EAR-controlled dual-use items, reflecting the more sensitive Munitions List categories involved — see CASRAI’s ITAR US Munitions List guide.
No general EAR-style license exceptions apply. ITAR’s exemption structure is narrower than EAR’s license-exception structure; a TCP written for an ITAR-controlled item usually cannot rely on the same generic exceptions used for EAR items, and the underlying licensing/registration mechanics differ — see CASRAI’s ITAR vs. EAR comparison for the full side-by-side.
Embargoed and restricted destinations still apply. Citizenship of the individual isn’t the only variable — see CASRAI’s guide to embargoed countries in export control for how country-level restrictions interact with a TCP’s personnel list.

Common mistakes when writing a Technology Control Plan

Writing it before classification is confirmed. A TCP drafted on the assumption that something is controlled, without a documented classification determination, is not defensible in an audit and often over-restricts access unnecessarily.
Listing roles instead of named individuals. “The postdoc” is not an authorized-personnel entry; a TCP needs the actual person’s name and citizenship status, updated whenever the team changes.
Treating it as a one-time document. A TCP that isn’t reviewed periodically — and specifically re-reviewed whenever personnel or project scope changes — is a routine audit finding.
Assuming procurement and export control are separate processes. Because equipment acquisition is one of the most common TCP triggers, procurement and export-control review need to happen together, before a controlled item arrives, not as an afterthought once it’s already in the lab. See CASRAI’s deemed-export screening checklist for the parallel process on the personnel side.

Frequently asked questions

What is a Technology Control Plan?

A Technology Control Plan is an institution-level document that specifies the physical, IT, and administrative safeguards used to prevent unauthorized — particularly unlicensed foreign-national — access to a specific item, technology, technical dataset, or piece of software that has been determined to be controlled under ITAR or EAR. See CASRAI’s full dictionary definition for the underlying regulatory framing.

When is a Technology Control Plan required?

Most commonly, when a foreign national will have access to an item or dataset that has been classified as ITAR- or EAR-controlled and no exclusion or license exception applies; when a defense-related or dual-use instrument is acquired; when an export license itself makes a TCP a condition of approval; or when a sponsor/contract restriction removes a project from the fundamental research exclusion.

Is there a standard Technology Control Plan template?

There’s no single federal government-mandated form, but the core elements — technology identification, named authorized personnel, physical security, IT security, training/acknowledgment, and periodic review — are consistent across university export-control offices and reflect what BIS and DDTC look for when a TCP supports a license application. Most institutions maintain their own standardized template; use it rather than a self-drafted substitute where one exists.

Does every project with a foreign national need a Technology Control Plan?

No. A TCP is only required when a controlled item, technology, or technical dataset is actually present and a foreign national (or another restricted-access condition) triggers a real deemed-export or licensing risk. Most fundamental research — open, publication-intended, with no export-controlled equipment or data — stays inside the NSDD-189 fundamental research exclusion and needs no TCP at all.

Technology Control Plan: Template, Example, and Step-by-Step Guide

Ask about Technology Control Plan: Template, Example, and Step-by-Step Guide