Understanding Technology Control Plans in Deemed Export Compliance
Article Summary
A Technology Control Plan is a document that defines who inside a company may access specific controlled technology, under what conditions, and how that access is confirmed. It exists because the deemed export rule treats the release of controlled technology to a foreign national as an export to that person's country of nationality, no matter where the release physically occurs. Mixed-nationality research teams, cloud collaboration platforms, and generative AI tools have all made that release point harder to see, which is exactly why a written compliance program alone is not enough. A Technology Control Plan is what turns that program's stated obligation into something that can actually be verified.
An effective plan starts with a catalog of exactly which controlled technology or technical data the company holds, since nothing else in the plan can be scoped correctly without it. It also requires personnel identification with citizenship or visa verification, physical and information security measures that separately govern who can enter a space and who can access files electronically, and defined protocols for visitors and contractors. Training has to end in a signed acknowledgment rather than a completed session alone, and the plan needs an ongoing self-evaluation component along with a named plan owner accountable for it at the facility or project level. Leaving any one of these out creates a plan that looks complete on paper but cannot actually demonstrate control in practice.
An Export Compliance Program manual states a company's overall policy: which regulations apply, who is responsible, how licensing decisions get made, and how violations get reported. A Technology Control Plan is narrower and more operational, typically built around a specific facility, project, or body of controlled technology. It answers the practical questions an ECP manual leaves open, such as which door requires badge access, which server folder is restricted, and which employees have actually been screened and trained. A company can have a fully compliant ECP manual and still fail a deemed export review if no Technology Control Plan exists to show how access is actually being restricted.
The most direct point of exposure is the R&D lab or test floor, where a prototype, schematic, or component under inspection can constitute a release the moment a foreign national sees it. Shared drives and cloud collaboration platforms extend that same exposure into written exchange, since a broadly set folder permission functions the same way as handing over a printed drawing. Engineering meetings, whiteboard sessions, contractors, subcontractors, visiting scientists, and interns all create additional exposure, often because they sit outside a company's long-term personnel screening. M&A due diligence and integration work, along with generative AI tools that can summarize or translate a restricted file, round out the list of places this risk actually shows up.
The process starts by mapping the controlled technology itself and taking a census of every employee, contractor, intern, and regular visitor by citizenship and status. From there, a gap analysis compares that census against the technology map to find every point where access exists without confirmed authorization. The next steps are drafting specific access procedures for each site or system, integrating the finished plan into the company's existing Export Compliance Program rather than treating it as a separate document, and routing it through review and formal sign-off by the company's designated export compliance official before it takes effect.
A Technology Control Plan should be revised any time a triggering event occurs, including a new hire with foreign national status, a new piece of controlled technology, a reorganization, an acquisition, or a move to a new facility. Beyond those triggers, the plan should go through a larger annual audit that tests whether its personnel census, citizenship verification, and visitor and contractor records are actually current rather than assuming they still hold. Recordkeeping is part of this cycle as well, since records generated under the plan must be retained for five years from the latest relevant event. A plan that is reviewed on schedule but whose supporting records are not retained for that full period will not hold up under a later audit.
Export compliance officers have spent the past two years watching the boundaries of technology transfer shift. A research engineer working from a shared facility, a collaboration drive accessible across three countries, and a cloud-based AI assistant summarizing a restricted design file can all raise the same underlying question: has controlled technology just been released to a foreign person? Under 15 CFR 734.13(b), the release of controlled technology to a foreign national is treated as an export to that individual's country of nationality, regardless of where the release physically occurs.12 Mixed-nationality research teams, cloud collaboration platforms, and generative AI tools have made that release point harder to see and easier to miss.
A written compliance program states the obligation. A technology control plan is what proves the company is meeting it. It defines, in specific and auditable terms, who may access particular controlled technology, under what conditions, and how that access is verified and recorded. This article explains what a technology control plan requires, where deemed export exposure typically originates inside a company, and how to build and maintain a plan that holds up under review.
What Is a Technology Control Plan?
A Technology Control Plan is a specific document that BIS recommends as part of an organization's broader export compliance program, and it exists to answer one operational question: who inside the company may access a given piece of controlled technology, under what conditions, and how is that access confirmed.
BIS's own guidance on export compliance programs instructs that when a company hires foreign nationals at its U.S. facilities and those individuals will have access to controlled technology, the company should create a Technology Control Plan to prevent an unauthorized release.3 The same guidance describes what the plan should contain: a physical security plan, an information security plan, personnel screening procedures, training and awareness programs, and a self-evaluation component, all incorporated into the company's existing export compliance program rather than standing apart from it.3
That relationship matters. An Export Compliance Program manual states the company's overall policy: which regulations apply, who is responsible, how licensing decisions get made, how violations get reported. A Technology Control Plan is narrower and more operational. It is typically built around a specific facility, project, or body of controlled technology, and it answers the practical questions an ECP manual leaves open: which door requires badge access, which server folder is restricted, which employees have been screened and cleared, and which training has actually been completed and documented.
A company can have a compliant ECP manual and still fail a deemed export review if no TCP exists to show how access to controlled technology is actually being restricted in practice.
Core Components of an Effective TCP
A catalog of controlled technology and technical data. The plan should identify, by product, program, or system, exactly which technology or technical data is subject to control. BIS's own compliance guidance instructs organizations to catalog their technology as a first step toward preventing an unintentional release, so the plan states precisely what it is meant to protect rather than leaving that question open.3
Personnel identification and citizenship or visa verification. BIS guidance directs organizations to centralize hiring and human resources processes so that appropriate screening is completed before controlled technology is provided to a foreign national.3 A workable plan applies this at the individual level: every employee, intern, or contractor with potential access is identified by citizenship and immigration status before that access is granted, not after.
Physical and information security measures. BIS names a physical security plan and an information security plan as separate required components, one governing who can enter a space where controlled technology is present, the other governing who can access it electronically.3 The two are not interchangeable. A facility can be physically secure while its file systems remain openly accessible, or the reverse, and a plan has to account for both.
Visitor and contractor protocols. BIS recommends recordkeeping for foreign national visitors that captures the visitor's name and nationality, the organization represented, the date and purpose of the visit, who they met with, and a summary of what was discussed. The same standard extends to contractors acting on the company's behalf, including consultants, interns, freight forwarders, distributors, and joint venture partners.3
Training with signed acknowledgment. Training alone establishes awareness. A signed acknowledgment establishes accountability. BIS describes companies asking employees to sign a statement at the end of training confirming they understand the material and will comply with it, with failure to do so subject to disciplinary consequences at the compliance manager's discretion.3
A self-evaluation and monitoring component. BIS lists a self-evaluation program among the required elements of a Technology Control Plan, distinct from the company's larger annual export compliance audit. In practice, this means periodic review of whether the plan's controls, screening, and access restrictions are still functioning as designed, not simply whether the plan exists on paper.3
A named plan owner. Every component above depends on someone being responsible for it. BIS's compliance program guidance calls for a designated export compliance contact, identified by name and title, who can be reached with questions about violations or procedural uncertainty. A Technology Control Plan should carry that same specificity at the facility or project level.3
Where Foreign National Access Actually Happens
A Technology Control Plan is only as good as its map of where a release can actually occur, and that list is longer than the obvious cases. Under 15 CFR 734.15, technology or source code is released the moment a foreign person visually inspects an item that reveals it, or the moment it is exchanged orally or in writing, regardless of where that exchange takes place.4 Judged against that standard, several everyday points of contact inside a company carry deemed export exposure.
R&D labs and test floors are the most direct example. A prototype on a bench, a schematic on a monitor, or a component under inspection can constitute a release the instant a foreign national employee, contractor, or visitor sees it, whether or not anyone intended to share anything.
Shared drives and cloud collaboration platforms extend that same exposure into written exchange. A folder permission set too broadly, or a document uploaded to a shared workspace without regard to who can open it, functions the same way a printed drawing handed across a table would. This site's coverage of remote access under the newer chip rules addresses that dynamic in more depth and is worth reading alongside this section.
Engineering meetings and whiteboard sessions create release through oral or written exchange in a setting that rarely feels regulated. Contractors, subcontractors, visiting scientists, and interns are release points because they are, by definition, outside the company's own long-term personnel screening, often present for a fixed period and granted access quickly to keep a project moving.
M&A integration teams belong on this list as well. Due diligence data rooms and post-close integration work routinely put controlled technical data in front of personnel whose citizenship has not yet been reviewed against it, often under deal timelines that leave little room for a screening process to catch up.
Generative AI tools introduce a newer version of the same problem, since a chat assistant summarizing or translating a restricted file can release its contents to whoever is on the other end of that conversation. This site's separate article on AI assistants and deemed exports covers that scenario specifically, and a complete TCP should account for it rather than treat it as a separate category of risk.
Building the Plan: A Practical Framework
Map the controlled technology. Identify, by product line, program, or research project, exactly which technology and technical data the company holds that is subject to the EAR or ITAR, and where each item physically or digitally resides. BIS guidance identifies this cataloging step as the starting point for preventing an unintentional release, and nothing later in the plan can be scoped correctly without it.3
Take a census of personnel by citizenship and status. Identify every employee, contractor, intern, and regular visitor with potential proximity to that technology, and record citizenship and immigration status for each. This census should be built at the individual level and kept current as people join, leave, or change roles, not treated as a one time exercise tied to a single audit cycle.
Run a gap analysis between access and authorization. Compare the census against the technology map to find every point where someone without confirmed authorization currently has, or could plausibly get, access. This step is where most exposure surfaces, since access is typically granted for convenience or speed long before anyone asks whether it was authorized in the first place.
Draft access procedures per site or system. For each gap identified, write the specific physical and information security measures that close it, consistent with BIS's requirement that a plan include both a physical security plan and an information security plan.3 Procedures should name the system, room, or facility in question rather than describe security in the abstract, so that the person implementing them knows exactly what to do.
Integrate the plan into the existing ECP. A Technology Control Plan is not a standalone document. BIS is explicit that it should be incorporated into the company's broader export compliance program, cross referenced by the ECP manual rather than filed separately from it or treated as a side project of the compliance function.3
Route the plan through review and sign off. Before the plan takes effect, it should be reviewed by the company's designated export compliance official and formally approved. That sign off is what converts a drafted plan into an active control the company can point to during an audit, and it should be repeated whenever the plan is revised, not only at its creation.
Maintaining and Auditing the TCP Over Time
A Technology Control Plan goes stale the moment any of its underlying facts change, which in most companies happens continuously. A new hire with foreign national status, a new piece of controlled technology entering development, a reorganization that moves a project to a different team, an acquisition, or a move to a new facility all invalidate the technology map or personnel census the plan was built on. Each of these events should trigger a defined revision, not a general sense that the plan should probably be looked at eventually.
Outside of trigger events, BIS's own guidance calls for a larger annual audit that reviews both the organization's export procedures and a sample of actual transactions against those procedures.3 Applied to a Technology Control Plan specifically, that annual review is where the self-evaluation component required by BIS is actually performed, rather than left as a line item on paper.3
The review should test the plan against its own components rather than assume they still hold. Is the personnel census current, or does it still list someone who left the company eight months ago? Does every name on that census map to a documented citizenship or visa verification? Do the visitor and contractor records required under BIS guidance actually exist for the period under review, complete with name, nationality, and purpose of visit?3
Recordkeeping ties directly into this maintenance cycle. Records required under the EAR, including the ones a Technology Control Plan generates, must be retained for five years from the latest relevant event, such as the export or transfer in question.5 A plan that is reviewed annually but whose supporting records are not retained for that full period will not hold up under a later audit, regardless of how well the plan itself was written.
•••••
A written export compliance program tells a reviewer what a company intends to do. A Technology Control Plan is what shows whether that intention actually holds up against the people, systems, and facilities the company operates every day. The distinction matters because deemed export exposure rarely arrives as a single dramatic event. It accumulates in a folder permission that was never narrowed, a visitor log that was never completed, a new hire whose citizenship was never verified before the first project meeting.
Building a Technology Control Plan around an accurate technology inventory, a current personnel census, and a defined review cycle turns that exposure into something a company can actually manage, and something an auditor can actually verify. For organizations working with controlled technology across research, engineering, and manufacturing functions, that difference is often what separates a compliance program on paper from one that holds up in practice.
Sources
- Bureau of Industry and Security — "What is a deemed export?" — https://www.bis.gov/learn-support/deemed-exports/what-deemed-export
- 15 CFR § 734.13 (eCFR) — Export — https://www.ecfr.gov/current/title-15/subtitle-B/chapter-VII/subchapter-C/part-734/section-734.13
- Bureau of Industry and Security — "The Elements of an Effective Export Compliance Program" — https://www.bis.gov/sites/default/files/documents/ECP_0.pdf
- 15 CFR § 734.15 (eCFR) — Release — https://www.ecfr.gov/current/title-15/subtitle-B/chapter-VII/subchapter-C/part-734/section-734.15
- 15 CFR § 762.6 (eCFR) — Period of Retention — https://www.ecfr.gov/current/title-15/subtitle-B/chapter-VII/subchapter-C/part-762/section-762.6
Key Points
What does an effective Technology Control Plan require, and how does it relate to a company's Export Compliance Program?
A Technology Control Plan is not a standalone compliance document. It is a specific, BIS-recommended plan that sits inside a company's broader Export Compliance Program and exists to prove that access to controlled technology is actually restricted in practice.
- A Technology Control Plan is triggered by hiring foreign nationals with access to controlled technology. BIS's own compliance program guidance instructs that when a company hires foreign nationals at its U.S. facilities and those individuals will have access to controlled technology, the company should create a Technology Control Plan to prevent an unauthorized release. That guidance places the obligation on the employer at the point of hiring, not after an access issue has already occurred.
- The plan must include five specific components, not a general security policy. BIS's guidance defines what a Technology Control Plan should contain: a physical security plan, an information security plan, personnel screening procedures, training and awareness programs, and a self-evaluation component. A plan missing any of these is incomplete regardless of how thorough it appears elsewhere.
- A Technology Control Plan is incorporated into the Export Compliance Program, not filed separately from it. BIS is explicit that the plan should be built into the company's existing compliance program rather than treated as its own side initiative. Compliance teams that maintain a Technology Control Plan disconnected from the ECP manual create two documents that can drift out of alignment with each other.
- An ECP manual states policy; a Technology Control Plan proves the policy is followed. The ECP manual covers which regulations apply, who is responsible, and how licensing and violations are handled at the company level. The Technology Control Plan is narrower and operational, answering specific questions the manual leaves open, such as which door requires badge access or which employees have actually completed screening.
- The plan is typically scoped to a facility, project, or body of technology, not the whole company. This scoping is what allows the plan to answer concrete questions instead of general ones, naming the specific system, room, or facility involved rather than describing security in the abstract.
- A compliant ECP manual does not substitute for a Technology Control Plan in a deemed export review. A company can have a fully documented compliance program and still fail review if it cannot show, through an actual Technology Control Plan, how access to controlled technology is being restricted in day to day practice
What are the core components of an effective Technology Control Plan, and what does each one actually require?
Each component of a Technology Control Plan addresses a different point where access to controlled technology can go unrestricted, and treating any one of them as optional creates a gap the rest of the plan cannot close.
- A catalog of controlled technology and technical data anchors the entire plan. The plan should identify, by product, program, or system, exactly which technology or technical data is subject to control. BIS's compliance guidance instructs organizations to catalog their technology as a first step toward preventing an unintentional release, since nothing else in the plan can be scoped correctly without that inventory.
- Personnel identification requires citizenship and visa verification at the individual level. BIS guidance directs organizations to centralize hiring and human resources processes so that appropriate screening is completed before controlled technology is provided to a foreign national. A workable plan applies this to every employee, intern, or contractor with potential access, verified before access is granted rather than after.
- Physical and information security measures are separate, required components, not one combined policy. BIS names a physical security plan and an information security plan individually, one governing who can enter a space where controlled technology is present, the other governing who can access it electronically. A facility can be physically secure while its file systems remain openly accessible, or the reverse, and a plan has to account for both.
- Visitor and contractor protocols extend the plan beyond a company's own employees. BIS recommends recordkeeping for foreign national visitors that captures the visitor's name and nationality, the organization represented, the date and purpose of the visit, and a summary of what was discussed. The same standard extends to contractors acting on the company's behalf, including consultants, interns, freight forwarders, distributors, and joint venture partners.
- Training only counts as a control when it ends in a signed acknowledgment. Training establishes awareness, but a signed acknowledgment is what establishes accountability. BIS describes companies asking employees to sign a statement at the end of training confirming they understand the material and will comply with it, with disciplinary consequences at the compliance manager's discretion for failing to do so.
- Ongoing self-evaluation and a named plan owner keep the plan from becoming static. BIS lists a self-evaluation program among the required elements of a Technology Control Plan, distinct from the company's larger annual audit, and calls for a designated compliance contact identified by name and title. Without both, a plan can look complete at the moment it is written and still have no one responsible for confirming it still works.
Where does foreign national access to controlled technology actually happen, and why do these points get missed?
A Technology Control Plan is only as good as its map of where a release can actually occur, and several of the most common points of contact rarely feel like export events at all.
- R&D labs and test floors create exposure through visual inspection alone. A prototype on a bench, a schematic on a monitor, or a component under inspection can constitute a release the instant a foreign national employee, contractor, or visitor sees it, whether or not anyone intended to share anything.
- Shared drives and cloud collaboration platforms extend that exposure into written exchange. A folder permission set too broadly, or a document uploaded to a shared workspace without regard to who can open it, functions the same way a printed drawing handed across a table would.
- Engineering meetings and whiteboard sessions create release in settings that rarely feel regulated. Oral and written exchange in an ordinary working meeting is treated the same as a formal exchange of documents.
- Contractors, subcontractors, visiting scientists, and interns sit outside a company's long-term personnel screening by definition. They are often present for a fixed period and granted access quickly to keep a project moving, which is exactly what makes them easy to overlook.
- M&A integration teams introduce risk through due diligence data rooms and post-close integration work. These activities routinely put controlled technical data in front of personnel whose citizenship has not yet been reviewed against it, often under deal timelines that leave little room for a screening process to catch up.
- Generative AI tools introduce a newer version of the same problem. A chat assistant summarizing or translating a restricted file can release its contents to whoever is on the other end of that conversation, and a complete plan has to treat that as the same category of risk as any other release point rather than as something separate.
How should a company actually build a Technology Control Plan, step by step?
Building a Technology Control Plan follows a specific sequence, and skipping an earlier step undermines the ones that come after it.
- Map the controlled technology first. Identify, by product line, program, or research project, exactly which technology and technical data the company holds that is subject to the EAR or ITAR, and where each item physically or digitally resides. Nothing later in the plan can be scoped correctly without this step.
- Take a census of personnel by citizenship and status. Identify every employee, contractor, intern, and regular visitor with potential proximity to that technology, and record citizenship and immigration status for each, kept current as people join, leave, or change roles.
- Run a gap analysis between access and authorization. Compare the census against the technology map to find every point where someone without confirmed authorization currently has, or could plausibly get, access. This is where most exposure surfaces, since access is typically granted for convenience or speed before anyone asks whether it was authorized.
- Draft access procedures for each specific site or system. For every gap identified, write the specific physical and information security measures that close it, naming the system, room, or facility in question rather than describing security in the abstract.
- Integrate the finished plan into the existing Export Compliance Program. A Technology Control Plan is not a standalone document. It should be incorporated into the company's broader compliance program and cross-referenced by the ECP manual rather than filed separately from it.
- Route the plan through review and formal sign-off. Before the plan takes effect, it should be reviewed and approved by the company's designated export compliance official, and that sign-off should be repeated whenever the plan is later revised, not only at its creation.
How should a company maintain and audit a Technology Control Plan over time?
A Technology Control Plan is only accurate for as long as the facts underneath it stay the same, which in most companies is not very long.
- Specific events should trigger an immediate plan revision. A new hire with foreign national status, a new piece of controlled technology entering development, a reorganization, an acquisition, or a move to a new facility all invalidate the technology map or personnel census the plan was built on, and each should prompt a defined revision rather than a general sense that the plan should eventually be updated.
- A larger annual audit is required outside of trigger events. BIS's own guidance calls for an annual audit that reviews both the organization's export procedures and a sample of actual transactions against those procedures, and this is where the plan's required self-evaluation component is actually performed.
- The audit should test whether the personnel census is still current. This means confirming the census does not still list someone who left the company months earlier, and that every name on it maps to a documented citizenship or visa verification.
- The audit should confirm visitor and contractor records actually exist for the period under review. These records need to be complete, including name, nationality, and purpose of visit, not simply assumed to have been kept.
- Recordkeeping requirements tie directly into this maintenance cycle. Records generated under the plan must be retained for five years from the latest relevant event, such as the export or transfer in question, and a plan that is reviewed on schedule but whose supporting records are not retained for that full period will not hold up under a later audit.
What is the practical risk of having an Export Compliance Program without an actual Technology Control Plan?
Deemed export exposure rarely arrives as a single dramatic failure. It accumulates in exactly the gaps a written policy alone cannot close.
- A written compliance program states an intention; it does not verify that the intention is being met. The distinction matters because a reviewer can confirm a policy exists without ever confirming it reflects what is actually happening inside the company.
- Exposure accumulates through small, ordinary gaps rather than one identifiable event. A folder permission that was never narrowed, a visitor log that was never completed, or a new hire whose citizenship was never verified before the first project meeting are the kinds of gaps that build up unnoticed.
- Release can happen through entirely ordinary business activity. R&D labs, shared drives, engineering meetings, contractors, visiting scientists, M&A integration work, and generative AI tools are all places controlled technology moves without anyone necessarily intending to export anything.
- Without a technology inventory and personnel census, a company cannot identify its own gaps. These two elements are what make it possible to compare who has access against who is actually authorized, and without them a gap analysis has nothing to work from.
- A compliant Export Compliance Program manual does not, on its own, satisfy a deemed export review. BIS guidance is explicit that a Technology Control Plan should be incorporated into that broader program, meaning the manual and the plan are expected to work together rather than the manual standing in for the plan.
- A Technology Control Plan converts an assumed policy into something an auditor can actually verify. Built around an accurate technology inventory, a current personnel census, and a defined review cycle, the plan turns deemed export exposure into something the company can manage rather than something it simply hopes it has avoided.
