Export Control Data Room: Why EAR, FDPR & the Entity List Are Data-Sharing Problems

Trade compliance writes a good Technology Control Plan. It names the controlled data, lists who may touch it, sets the rules for foreign nationals, and gets signed off by legal. It is a serious document, and it is entirely correct.

Then, at four in the afternoon, an engineer drops a design file into a shared folder so a colleague in another country can pick up where they left off. Nothing in the plan reached across the room to stop it, because the plan lives in a policy library and the sharing lives in SharePoint. That gap – between the rule as written and the rule as enforced – is where semiconductor export-control exposure actually sits. It is why an export control data room matters: not to restate the regulation, but to enforce it at the exact moment someone tries to open a file.

Three regimes, one operational question

Semiconductor work runs into three overlapping controls, and it is worth stating them plainly.

The EAR – the Export Administration Regulations – govern most commercial technology, including advanced-node design data, tools, and process technology. Releasing controlled technology to a foreign person, even on a screen, can require a license.
The Foreign Direct Product Rule extends US jurisdiction to certain foreign-made items that were produced using US technology or software – which is how a design or a downstream product can stay in scope even when it is developed abroad.
The Entity List names specific parties that require a license before you can share controlled technology with them, and it changes; a counterparty that was fine last quarter can be restricted this quarter.

Read them side by side and they collapse into the same practical question, asked over and over, every time a file moves: can this specific person, in this specific country, working for this specific company, open this specific file? That is not a legal question in the moment. It is an access-control question. The law defines the answer; your systems either enforce it or they do not.

Why the legal layer, on its own, doesn’t hold the line

A policy document cannot see a file being shared, and that is the whole problem. Three failure patterns show up again and again, and none of them are caught by a plan sitting in a binder.

The first is the deemed export. Giving a foreign person access to controlled technology – including a foreign-national employee sitting in your own office – is treated as an export to their home country, even if nothing physically ships and even if they only view it. The most common export-control failure in this industry is not smuggling; it is an ordinary access grant to someone who was never cleared to see the data.

The second is the moving target. The Entity List and the specific rules for advanced computing change on their own schedule, not yours. If you shared a folder with a partner in March and that party is restricted in June, the exposure is not the original share – it is that the access is still live and nobody re-checked it against the new list.

The third is reach. Because the Foreign Direct Product Rule can follow US-origin technology into foreign-made work, “we developed it overseas” is not the clean exemption people assume. The controlled thing can be the design data itself, wherever the person opening it happens to sit.

Every one of these is enforced, or missed, at the level of identity and files – not at the level of policy. Which means export control is, in the end, a data-sharing problem.

What an export control data room actually enforces

If the regulation resolves to “can this person, in this country, open this file,” then compliance is real only when your collaboration infrastructure can answer that question at the moment of access and prove afterward that it did. That is a small set of concrete capabilities, and they are worth being specific about.

Access has to be conditioned on identity, not just credentials – tied to a person’s role, their employer, and their location or citizenship, so entitlement can turn on the same facts the regulation turns on. Protection has to travel with the document, so a controlled file that does leave a room still carries its encryption and rights. Sharing has to be scoped and containable: a separate room per counterparty means that when the Entity List changes, you revoke one relationship’s access without unpicking everyone else’s. Access has to expire on its own when an engagement ends, because “we meant to remove them” is not a defense. And every view, download, and permission change has to land in a record you cannot quietly alter – because when a regulator, a customer, or your own auditor asks you to show that controlled data never reached an unauthorized person, a reconstruction is not evidence.

There is one more requirement that is easy to miss: the controlled data should not leave your own boundary to be collaborated on. Routing export-controlled design files through a third-party data room puts them on someone else’s cloud, under someone else’s operations – which is a jurisdictional question you created rather than closed. Keeping the room inside the Microsoft 365 tenant you already control removes it.

That is the model Govern 365 is built on: access conditioned on person and place through Entra ID, protection carried by Microsoft Purview labels, isolated and expiring rooms per relationship, and an immutable audit trail – all inside your own tenant, so the design IP never leaves it. The industry view is on the Govern 365 for Semiconductor page; the everyday-collaboration side of the same story is in why sharing a chip design is an export-control question and why design IP can’t live in an ungoverned Teams site.

The point worth keeping

Your Technology Control Plan describes the rule. Your data infrastructure enforces it or fails to. Export control feels like a legal matter right up until you realize that every actual violation happens as a file being opened by the wrong person, in the wrong place, with nothing in the way. Put the enforcement where the sharing happens – condition access on person and place, contain it per relationship, expire it on its own, and log all of it – and the plan finally has something behind it.

Frequently asked questions

What is the difference between the EAR, the Foreign Direct Product Rule, and the Entity List?

In plain terms: the EAR is the main body of US commercial export rules and covers most semiconductor technology, so releasing controlled technology to a foreign person can require a license. The Foreign Direct Product Rule extends US jurisdiction to certain foreign-made items built with US technology or software, which keeps design and downstream products in scope even when developed abroad. The Entity List names specific parties you cannot share controlled technology with absent a license. They overlap, and together they turn each file share into a question about who, where, and for whom.

Isn’t a Technology Control Plan enough to stay compliant?

A plan is necessary, but it describes the rule rather than enforcing it. Compliance becomes real when your systems can condition access on the same facts the plan relies on – role, employer, citizenship, location – and can prove, after the fact, that controlled data never reached an unauthorized person. Without that enforcement and evidence layer, the plan documents an intention that your collaboration tools may or may not be honoring.

What is a deemed export, and how does it happen inside our own company?

A deemed export is the release of controlled technology to a foreign person, treated as an export to that person’s country – even if nothing physically ships and even if they only view the file on a screen. It happens internally whenever a foreign-national employee or contractor is granted access to controlled data they were not authorized to see. Because it is an access event, the way to prevent it is to condition access on citizenship or nationality and to log every access, so you can both stop and evidence it.

What happens when a partner is added to the Entity List after we’ve already shared data with them?

That is exactly why scoping and revocation matter. If each counterparty works in its own isolated room, you can cut that relationship’s access in one action when the list changes, without disturbing anyone else – and the audit trail shows when access ended. In an open, shared environment the same change means hunting through sites and permissions to find every place that party could still reach, which is slow and hard to prove.

How does an export control data room enforce the rules rather than just document them?

By moving enforcement to the point of access. Entra ID conditions who can open a file on role, employer, and location or citizenship; Microsoft Purview labels carry encryption and rights that travel with the document; rooms are isolated per relationship and expire when the engagement ends; and every access is written to an immutable log. The result is that the regulation’s answer – this person may or may not open this file – is applied automatically and captured as evidence, instead of living only in a policy binder.

Take the next step

Book a Govern 365 semiconductor data room demo to see access conditioned on person and place, isolated rooms you can revoke one at a time, guest access that expires on its own, protection that travels with the file, and an immutable audit trail you can hand to a regulator – all inside a live Microsoft 365 environment. Prefer to read first? Pick up Secure by Design for the broader playbook on governed collaboration in Microsoft 365.