Semiconductor Data Room for IP & Export Control: Why Sharing a Chip Design Is a Compliance Decision

A design engineer finishes a block, exports the GDSII, and sends it off to the foundry. A sign-off report goes out by email to the assembly and test partner. A folder gets shared with an IP vendor over Teams. Nobody hesitates, because it is all running on the same Microsoft 365 the company already trusts.

That trust is misplaced, though not in the way people expect. The platform is fine. The problem is the moment the file leaves the design database. Once a GDSII or a sign-off PDF is exported, it no longer carries the access rules, encryption, and isolation that protected it at the source – and in this industry that exported file is often export-controlled. So the decision to share it was never really an IT decision. It was a compliance decision dressed up as a file share. That is the case for a semiconductor data room: not a deal-room luxury, but the control layer for the ordinary handoffs that keep a chip moving.

Start with the fact that makes all of this unavoidable. Nobody builds an advanced chip alone. The value chain is a lock with eight keys – design, IP, materials, equipment, foundry, assembly, test, and the customer – and it is absurdly concentrated. Nearly all of the world’s EUV lithography comes from one company. Most of the leading-edge chips come out of one foundry. A single advanced fab costs somewhere north of $15 billion. You cannot design your way around any of that; the economics force your most valuable IP across company lines just to get a wafer started. The only real choice you have is whether those handoffs are governed.

It isn’t the database that leaks. It’s the file that leaves it.

Your design and process databases are already locked down – role-based access, encryption, isolation. Where they sit, the crown jewels are safe. Exposure starts the instant you export, and semiconductor work exports all day long. RTL, netlists, and GDSII go out to the foundry. PDKs and IP blocks come back from partners. Recipes, certificates of analysis, and yield data travel with materials. Tool specs and service records move between you and your equipment vendors. Roadmaps, pricing, NDAs, and export filings circulate on the commercial side.

Every one of those is a copy that kept the value of the original and dropped its protection. Guarding the repository while the exported GDSII travels unprotected is locking the vault and mailing the contents.

Advanced-node design data, the tools that create it, and the process technology behind it all fall under export controls – the EAR, the Foreign Direct Product Rule, Entity List restrictions, and ITAR where the work touches defense. Under those rules, sending a GDSII to an overseas foundry or opening a PDK to a foreign engineer can be a controlled transaction rather than a routine share. One exported file, sent to the wrong party or the wrong country, can cross a line that is genuinely hard to walk back.

What catches companies out is that the failure almost never looks like a breach. It is mundane. A share link that never expired. A guest account still live two years after the project wrapped. A permission set one folder too wide. A site whose owner left and whose access nobody revisited. No trail behind any of it. Sharing a design turns into an export-control problem for a boring reason: in most organizations, deciding who can open that exported file is nobody’s actual job.

Why the usual tools don’t close the gap

Most teams reach for one of two options, and each leaves a hole.

A bare Teams site or SharePoint share gets you a login and little else – no access keyed to geography or citizenship, no per-recipient watermarking, no expiry when an engagement ends, and no audit trail you would want to put in front of a customer. Sensitivity labels help at the file level, but a label will not notice that a guest still has access long after they should have lost it.

A standalone data room – Intralinks, Datasite, the usual names – hands you the governance but parks your export-controlled design IP on someone else’s cloud, outside the boundary you control. For an M&A process that is an inconvenience. For a chip design it is a jurisdiction problem you have created for yourself.

So people split the difference badly. They over-share into email and commercial cloud, or they lock things down so hard that engineers quietly route around them. Either way, the file walks.

What a semiconductor data room does differently

The way out is to treat external collaboration as a governed workflow inside your own Microsoft 365 tenant, rather than an export out of it. A tenant-native VDR for semiconductor IP does a handful of things a Teams site and a third-party VDR cannot manage together.

Each relationship gets its own room – a foundry here, an IP licensor there, a supplier for OSAT, another for an equipment vendor – and each is walled off from the rest, so partners who happen to compete never learn the others exist. The IP itself stays put: a three-tier room streams a protected view to the foundry or vendor without ever copying the file out of your SharePoint. Access is tied to who someone is and where they are, mapped to your EAR, FDPR, and ITAR obligations, so you can both enforce and later prove that a controlled file never reached the wrong hands. Protection rides along with the document, because every upload inherits the room’s Purview label the moment it lands and carries the encryption and rights with it. And every view, download, and permission change lands in a log you cannot quietly edit – so when a customer, an auditor, or an export reviewer asks, you have the answer instead of a reconstruction.

That is the model Govern 365 is built on: data-room controls layered onto the Entra ID, Purview, and SharePoint you already run, so design and process IP never leaves the tenant you already trust. The semiconductor-specific detail lives on the Govern 365 for Semiconductor page.

What it comes down to

If you keep one line from this, keep this one: the risk lives with the file that leaves and with who can open it, not with how solid the platform feels. Protecting the design database while the exported GDSII floats around unprotected is guarding the wrong thing. Govern the room the file moves through, keep that room inside your tenant, and gate access by person and place. Do that, and “secure” stops being the thing that slows the work down.

Frequently asked questions

Is sharing a chip design across the supply chain really an export-control issue?

It can be. Advanced-node design data, the tools that produce it, and the underlying process technology fall under regimes like the EAR, the Foreign Direct Product Rule, and Entity List restrictions – with ITAR in the picture for defense-adjacent work. So handing a GDSII to an overseas foundry, or opening a PDK to a foreign engineer, may count as a controlled transaction rather than an ordinary share. That is why who can open a file, and from which country, becomes something you have to control rather than assume.

What is the “derivative file” problem?

Your design and process databases are controlled at the source. But the moment content is exported – to a GDSII package, a sign-off PDF, an Office file – the copy keeps the value and sheds the controls. That copy is what actually moves between companies, and it is where most exposure happens. A semiconductor data room addresses it by attaching a sensitivity label and travelling rights to every file, so the copy stays governed wherever it ends up.

Isn’t a Teams site or a standalone VDR enough?

Neither closes the gap on its own. A Teams site gives you a login but no geography- or citizenship-aware access, no per-recipient rights, no automatic expiry, and no audit trail worth showing. A standalone VDR adds governance but puts your export-controlled IP on a third party’s cloud, which is a jurisdiction question you did not have before. A tenant-native VDR gives you the governance without a second boundary, a second log, or a second copy of your IP to defend.

How does a semiconductor data room keep our IP inside our tenant?

It puts data-room controls on the Microsoft 365 you already run. Partners get scoped access to isolated rooms in your tenant instead of copies; a three-tier room streams protected views without duplicating anything; access is conditioned on role, need-to-know, geography, and person; protection travels with the file; and every action is logged in Purview. The design and process IP never crosses the boundary.

Does this work for day-to-day supply-chain collaboration, not just deals?

Yes, and that is where most of the value is. Working securely with foundries, IP partners, materials and equipment vendors, OSAT providers, and customers is a permanent condition, not a one-off event. Room templates, guest governance, least-privilege permissions, and geography-aware access let you stand up a governed room for a new partner in minutes, with the controls already on.

Govern 365 for Semiconductor – foundry, IP, and export-controlled collaboration across the chip value chain, inside your own tenant.
Govern 365 Virtual Data Room – the tenant-native data room these controls are built on.
Secure by Design – Niraj Tenany’s book on secure collaboration in Microsoft 365.

Take the next step

Book a Govern 365 semiconductor data room demo to see isolated foundry, supplier, and customer rooms; export-control-aware access gated by person and place; room-based protection that travels with GDSII and sign-off files; and audit reporting you can hand to a reviewer – 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.