ITAR-Compliant Data Room: Zero Pass-Through, §120.54, and What 'Compliant' Actually Means (2026)

I'm Sean Yu, co-founder of Peony, a data room company. I also co-founded GingerControl, a trade-compliance software company — so export controls are not a content vertical for me, they are my other company's entire product. When someone asks me for an "ITAR-compliant data room," I have to start by disagreeing with the question, and that disagreement is the most useful thing in this whole post.

Quick answer: No data room is "ITAR-certified" — no such certification exists for software, so any vendor selling you a "fully ITAR-compliant tool" is telling you they don't understand the regime. Compliance stays with you. The real question is which architecture lets you put export-controlled technical data in the cloud lawfully. The answer has two parts: (1) the §120.54 encryption carve-out — cloud sharing is not an export if the data is end-to-end encrypted and the provider holds no means of decryption; and (2) deemed-export prevention — because a foreign national viewing your drawing is an export, access must be gated per US person, not per shared link, and logged. Peony defaults to zero data pass-through — Peony has no access to the contents of your rooms by default — which is the design the carve-out contemplates. It does not classify your data or screen your people; those stay your job. This is general information, not legal advice.

Is any data room actually "ITAR-certified"?

No. There is no such thing as an "ITAR-certified" or "ITAR-compliant" tool, and this is the single most important thing to internalize before you evaluate anything. ITAR is a regulation administered by the State Department's Directorate of Defense Trade Controls (DDTC) — it is not a certifiable standard like SOC 2, ISO 27001, or AS9100. There is no accreditation body, no published certification scheme, and no third party that can issue an "ITAR seal" to a piece of software.

What actually exists is ITAR registration with DDTC under 22 CFR Part 122, and it applies to "any person who engages in the United States in the business of manufacturing or exporting or temporarily importing defense articles, or furnishing defense services" — plus brokers under Part 129. A SaaS data room is generally none of those things. It is infrastructure a registered customer uses. So a data room cannot "be ITAR compliant" as a product, because that category does not apply to it. It can only support your compliance program by providing controls that map to specific regulatory requirements.

This matters because the market is full of vendor pages that sloppily claim "ITAR-certified" or "fully compliant." When you see that phrasing, read it as a competence signal — a red flag, not a green one. Compliance is a property of your program and your conduct, never of a tool. The honest frame, and the one I'll use throughout, is "architecture designed to support ITAR compliance programs" and "the design the §120.54 carve-out contemplates." Everything below is about that architecture.

General information, not legal advice. Confirm any published or internal compliance position with your export-control counsel or empowered official.

Can you share ITAR technical data in the cloud without an export license?

Yes — under a specific, precise carve-out, and only if you meet all of its conditions. Sending, taking, or storing ITAR technical data via the cloud is not an export, reexport, or retransfer under 22 CFR §120.54(a)(5) when the data is:

• (i) Unclassified;
• (ii) Secured using end-to-end encryption;
• (iii) Secured using cryptographic modules compliant with FIPS 140-2 (or its successors) per current NIST guidance, or by other cryptographic means providing security strength at least comparable to the minimum 128 bits achieved by AES-128;
• (iv) Not intentionally sent to a person in or stored in a country proscribed in §126.1; and
• (v) Not sent from a §126.1 proscribed country.

A Note to paragraph (a)(5)(iv) clarifies that data merely in-transit via the internet "is not deemed to be stored in a country it transits" — so encrypted data can route through a proscribed country without breaking the carve-out; only intentional sending-to or storage-in triggers the bar. Russia is now captured automatically by the "§126.1 country" language, so the ITAR text does not need a separate "or Russia" clause the way the EAR does.

The EAR mirrors this almost exactly at 15 CFR §734.18(a)(5) for "technology" and "software," with two wording differences worth noting so you don't quote them interchangeably: the EAR's third prong says "or other equally or more effective cryptographic means" rather than pinning a number, and the EAR names the Russian Federation explicitly in addition to Country Group D:5.

Now the two clauses that make or break this for a cloud tool. First, §120.54(b)(1) defines "end-to-end encryption" as (i) cryptographic protection such that the data is not in unencrypted form between the originator and the intended recipient, and (ii) "the means of decryption are not provided to any third party." Second, §120.54(c) states that "the ability to access technical data in encrypted form that satisfies the criteria set forth in paragraph (a)(5) of this section does not constitute the release or export of such technical data." Read those two together and the entire architecture of a compliant cloud tool falls out of them.

One more constraint from §120.54(b)(2) that people miss: the intended recipient "must be the originator, a U.S. person in the United States, or a person otherwise authorized to receive the technical data, such as by a license or other approval." Encryption makes the cloud storage and transit a non-event. It does not authorize you to hand the decrypted view to an unauthorized foreign national. Hold that thought — it is the whole deemed-export section below.

General information, not legal advice. The carve-out is yours to rely on; a tool enables it, your configuration and recipient choices complete it. Confirm your position with export-control counsel.

Why is the provider's ability to decrypt the whole ballgame?

Because §120.54(b)(1)(ii) says the means of decryption cannot be provided to any third party — and your cloud provider is exactly that third party. This one prong is the reason a generic cloud drive fails and a zero-access room passes. If your provider can decrypt your files, the provider has been "provided the means of decryption," the end-to-end-encryption definition is not met, and you have lost the carve-out. If the provider can only ever touch ciphertext, then under §120.54(c) the provider's mere ability to access data in encrypted form "does not constitute the release or export." Zero-access satisfies this prong by construction — not by a policy, a promise, or a data-processing addendum.

Here is the practical tell for evaluating any platform: server-side features expose decrypted access. A VDR that runs full-text indexing, generates document previews, does keyword search across contents, performs AI redaction, or runs any AI over your files necessarily decrypts those files on its servers to do the work. That capability is the opposite of the carve-out. It is not a knock on those products for ordinary deals — it is simply disqualifying for the specific job of "the provider must not be able to read this."

This is where I have to be precise about Peony, and I'll use the exact wording our claim discipline allows: Peony is the only purpose-built data room that defaults to zero data pass-through — Peony has no access to the contents of your rooms by default; nothing is read, mined, or passed to a third party, and AI features run only against models you connect, with zero retention. Two qualifiers in that sentence are load-bearing and I will not blur them. "Purpose-built data room" distinguishes Peony from pure encryption tools like PreVeil and Tresorit, which are excellent at zero-access but are not deal-grade rooms. "Defaults" distinguishes Peony from Intralinks Customer-Managed Keys, which is a paid enterprise add-on and not the default, and from self-hosting projects, which are a deployment you run rather than a default you get. I am not claiming cryptographic client-side-key zero-knowledge — the operational default-no-access claim stands on its own, and it is the property §120.54(b)(1)(ii) actually cares about for the third-party-provider question.

To be candid about the boundary: because access is the default posture, this is a design decision, not a guarantee of your export compliance. The carve-out is yours to complete with qualifying encryption, keeping intentional storage out of §126.1 destinations, and — the next section — restricting who can decrypt and view. We serve 5,900+ customers across finance, life sciences, and defense-adjacent work, and the ones in this vertical use Peony precisely because the provider-no-access default is the piece the carve-out is written around.

How do you prevent a deemed export when a foreign national views a drawing?

You prevent it by gating decryption-and-viewing per identity, so the only humans who can ever see the unencrypted data are the specific US persons (or licensed recipients) you authorized — and by logging every one of those views. This is the prong encryption does not solve. Both regimes treat release to a foreign national inside the US as an export: the EAR calls it a "deemed export" at 15 CFR §734.13(a)(2), and ITAR treats disclosure to a foreign person — whether in the US or abroad — as an export to that person's country of nationality. Visual inspection alone counts as a release. There is no shipment, no border crossing, no email leaving the country required.

The canonical case is US v. John Reece Roth. A University of Tennessee professor was criminally convicted under the AECA/ITAR and sentenced to four years in prison for giving foreign-national graduate students — a Chinese national and an Iranian national — access to ITAR-controlled technical data on a military drone plasma-actuator contract. The through-line of that case, and of the broader enforcement pattern, is that access by an unauthorized foreign national is a prosecutable export. That is why "who can view this file" is not an IT convenience question — it is the compliance question.

A forwardable shared link cannot enforce this. An identity-bound link can. In Peony the mechanism is concrete:

• Visitor groups — you place verified US-person recipients into groups and assign documents to the group, so a controlled set is visible only to the people in it and a foreign national is simply never in the group.
• Two-factor authentication and password protection — each grant is bound to a specific verified email with a second factor, so the credential is not transferable and a forwarded link is useless to anyone else.
• Dynamic watermarks — every rendered page carries the viewer's identity, deterring and tracing any attempt to screenshot and re-share a controlled drawing or manual.
• Revoke access — the instant a partner's status changes or a program ends, you cut off that one person without disturbing anyone else in the room.

The honest boundary, and it matters: Peony enforces and logs your US-person determination — it does not make it. Under ITAR a US person is a US citizen or national, a lawful permanent resident under 8 U.S.C. 1101(a)(20), or a protected individual under 8 U.S.C. 1324b(a)(3). The line is immigration status, not citizenship alone — an LPR is a US person; a work-visa holder generally is not. Verifying that status and running denied-party screening is your process, exactly the way KYC is the customer's job in other regulated verticals. Peony is the enforcement-and-evidence layer for the decision you make, not a substitute for making it.

General information, not legal advice. US-person determinations and screening should be run by your empowered official under your written procedures.

What audit trail do you need to defend an export-enforcement action?

You need a complete, per-person access log — who opened which document, which pages, when, and for how long — retained as your evidentiary record. In an export-enforcement matter or a voluntary disclosure to DDTC, the log is either the evidence that no unauthorized person accessed the data, or the honest, contemporaneous record of exactly what happened and when you caught it. Both are enormously better than reconstructing access after the fact from email threads and memory. The audit trail is not a nice-to-have reporting feature; it is your defense file.

Peony page analytics capture per-person, per-page view history automatically — every open, every page, every timestamp — so the record builds itself as people use the room. Combine that with an NDA gate that records a recipient's acknowledgement before controlled access, and revoke access to demonstrate you cut off a recipient the moment their authorization changed, and you have a defensible chain: acknowledged, gated, viewed-by-these-people-only, revoked-on-this-date. If you have to walk DDTC through your handling of a controlled package, you want to be reading from a log, not guessing.

The discipline reduces to one sentence: if you cannot prove who saw a controlled file, you cannot prove you stayed compliant. Voluntary disclosures are viewed far more favorably when the disclosing party can show it had real controls and real records, rather than a claim that "we're pretty sure only the right people saw it."

General information, not legal advice. Confirm your recordkeeping and disclosure obligations with counsel.

How do you segregate ITAR from EAR/ECCN files and share license-application documents in one room?

You segregate them with separate visitor groups and separate document sets carrying distinct permissions, so an ITAR-USML technical package and an EAR/ECCN-controlled item each reach only the recipients authorized for that specific thing. ITAR (State/DDTC) and the EAR (Commerce/BIS) are different regimes with different rules and different authorizations, so collapsing them into one permission bucket is precisely how a file reaches someone it shouldn't. Structure the room around authorization scope.

In practice: create a group for your US-person-only ITAR set, a separate group for an EAR item that a particular foreign customer is authorized to receive under a specific license, and assign documents to groups, not to individuals ad hoc. If a license authorizes a named foreign national to receive a specific ECCN item, that authorization can be reflected as its own scoped group — the tool enforces the boundary your license defines. For DDTC or BIS license-application supporting documents, stand up a dedicated room, grant scoped access, watermark every page, and log all activity, so the reviewer sees exactly the intended package and nothing adjacent leaks in.

The boundary again, because it is the honest core of this whole post: Peony does not classify your data. Whether an item is USML or EAR-controlled, its category, and its ECCN are jurisdiction and classification calls for your export counsel and empowered official. Peony enforces the boundaries you draw once you've drawn them — it is the room, not the ruling.

How bad is email-and-generic-cloud exposure, and what should you do first?

It's a serious exposure, and it fails on two independent fronts at the same time. First, email providers and standard cloud drives can decrypt your files, which breaks the §120.54 carve-out at the third-party-decryption prong — the storage and transit are arguably an export event because the provider holds the keys. Second, a forwarded attachment or a shared link can land in front of a foreign national with no gate and no log, which is a potential deemed export you cannot even detect, let alone defend. Most teams in this position already sense it — the "I know this is a liability" feeling is correct.

Here is the practical triage order:

1. Stop sending controlled technical data as email attachments immediately. This is the single highest-risk channel and the easiest to shut off today.
2. Inventory where controlled files currently live and who has had access. You cannot fix or disclose what you haven't mapped.
3. Move active sharing into a room where the provider cannot read the data and access is gated per US person with a full audit trail. This closes the go-forward hole.
4. Document what happened and talk to your export-control counsel about whether a voluntary disclosure to DDTC is warranted for any past exposure.

Fixing the channel is fast — you can stand up a zero-access room and re-route sharing in an afternoon. The review of past exposure is the harder, slower part, and it's where your empowered official and counsel earn their titles. Don't let the size of step four stop you from doing step one today.

General information, not legal advice. Whether to file a voluntary disclosure is a legal judgment for your counsel.

How does Peony compare to PreVeil, GCC High, Kiteworks, Intralinks, and Tresorit?

They are genuinely good tools that solve adjacent but different problems, and the honest answer is that the right choice depends on the job. Here's the credit-where-due breakdown, and where each is the right answer:

• Microsoft GCC High / Azure Government — a sovereign, US-person-administered enclave that holds ITAR data and is the standard answer when a contract requires FedRAMP-scoped or CMMC-scoped cloud. This is enclave collaboration inside your contractor boundary. If a prime or agency flows down a GCC High or FedRAMP requirement, use GCC High — Peony is not FedRAMP-authorized, and I won't pretend otherwise. Different lane, right tool.
• PreVeil — the category anchor for zero-access: end-to-end-encrypted email and file drive, FIPS 140-3 validated, no access to decryption keys, mapped explicitly to §120.54. Excellent when what you need is encrypted email and a secure drive for a defense contractor's internal collaboration. It is not a deal-grade data room — no per-group deal-permission matrix, no Q&A workflow, no granular document analytics.
• Kiteworks — governed, audited file transfer for regulated content, FedRAMP-authorized. The right answer when the job is secure managed file transfer at scale rather than a permissioned diligence room.
• Intralinks — an enterprise deal VDR whose Customer-Managed Keys add-on can make files provider-inaccessible with the customer's consent. The right answer for a large enterprise M&A process that will pay for CMK as a premium option. Note the two qualifiers: CMK is not the default (standard rooms give Intralinks decrypted access, and it now runs server-side AI), and it is a paid add-on.
• Tresorit — Swiss, client-side-key, zero-knowledge cloud storage — even Tresorit's staff can't read your files. The right answer when you want cryptographic zero-knowledge drive storage. It is not a data room: no deal Q&A, no diligence index, no deal-permission matrix.

The carve none of them fills: a deal-grade data room — per-group permissions, NDA and Q&A gates, granular per-page document analytics — with provider-no-access as the default, no add-on and no self-hosting required. That is the specific slot Peony occupies. If your need is enclave collaboration, encrypted email, managed file transfer, or zero-knowledge drive storage, one of the tools above is likely a better fit, and you should use it. If your need is to share controlled technical data with counterparties in a permissioned, logged, provider-can't-read room — the defense-M&A CIM, the parts package to an overseas operator, the license-application set — that is what Peony is built for. For a fuller landscape of the category, see our top data room providers guide and what a virtual data room is.

What does an ITAR-grade data room cost versus the fine for a deemed export?

A zero-access data room typically runs on the order of $30 to $52 per admin per month, with viewers usually free — so a 50-person defense supplier is generally looking at a few hundred dollars a month, driven by how many people administer rooms rather than merely view them. You can see current tiers on our pricing page. Now price the failure. A single ITAR civil violation runs up to $1,271,078 (the 2025 inflation-adjusted figure at 22 CFR §127.10) or twice the value of the transaction, whichever is greater — and violations are counted per act. A handful of files reaching a few foreign nationals does not net one fine; it can net dozens.

The enforcement record makes this concrete. 3D Systems concluded a $20,000,000 DDTC settlement over 132 violations — unauthorized exports of technical data (including CAD and manufacturing data) to Germany, Taiwan, and China, plus releases to foreign-national employees from India and the UK — with parallel penalties to BIS and DOJ pushing the total toward $27M. Bright Lights USA, a mid-sized firm, took a $400,000 DDTC penalty for unauthorized exports of ITAR technical data to vendors in China and India. Small and mid-sized shops are enforced against, and how you share files with foreign vendors and employees is squarely in scope.

Set the two numbers side by side. A $30-to-$52-per-admin subscription against up to $1,271,078 per violation, counted per file and per person, is a rounding error. It's also far cheaper than a GCC High migration, which is a real multi-month program you should undertake only when a contract actually requires that scope — not as a default reflex. But keep the honest frame: the tool is cheap insurance for the channel, and it does not make you compliant on its own. Your classifications, your US-person determinations, and your program do that. The tool makes the right behavior enforceable and the record provable.

Who actually needs this?

The archetype is narrower and more concrete than "defense contractor." Picture a civilian operator of military-origin aircraft — say, a company running a fleet of surplus CH-47 Chinooks for international heavy-lift and firefighting contracts. The operation is entirely civilian, but the maintenance manuals, parts data, and engineering drawings for a USML-origin platform are ITAR technical data regardless of who's flying it. Every time that operator sends a manual to an overseas maintenance partner, shares parts data with an international customer, or supports a license application to sell a surplus airframe, controlled documents move to a counterparty.

The same shape recurs across this vertical: aerospace MRO shops exchanging technical data with operators and OEMs; defense parts suppliers sending drawings to primes and, carefully, to authorized foreign customers; and exporters holding ECCN-classified technology managing EAR-controlled sharing under specific licenses. In every case the operation may be commercial and routine, but the documents are controlled, the counterparties are sometimes foreign, and the channel — today, usually email and a generic cloud drive — is the exposure. If you're in defense and aerospace and any of that describes a Tuesday at your shop, this is your problem to solve.

Frequently asked questions

Is any data room actually "ITAR-certified," or do we still own compliance if we use one?

No data room is 'ITAR-certified,' because no such certification exists for software. ITAR is a regulation, not a certifiable standard like SOC 2 or ISO 27001 — there is no accreditation body and no 'ITAR seal' any tool can earn. What exists is ITAR registration with DDTC, which applies to manufacturers, exporters, and brokers of defense articles, not to a SaaS platform your team uses. So compliance always stays with you: your program, your classifications, your access decisions. A platform can only support that program by providing controls — end-to-end encryption, per-person access, and audit trails — that map to specific regulatory requirements. Any vendor selling you a 'fully ITAR-compliant tool' is telling you they don't understand the regime.

Do we need a specialized ITAR data room, or is our current Google Workspace / SharePoint good enough for controlled technical data?

Standard Google Workspace, Dropbox, or commercial SharePoint is generally not good enough on its own, for one structural reason: the provider holds the keys and can decrypt your files, so it fails the load-bearing condition of the §120.54 encryption carve-out — that the means of decryption are not provided to any third party. You do not necessarily need a product with 'ITAR' in its name, but you do need an architecture where the provider cannot read your controlled technical data and where you can gate viewing to authorized US persons per document. If a specific government contract requires FedRAMP or GCC High, that is a separate lane. For private-sector B2B sharing of ITAR data, the operative requirement is the encryption carve-out plus US-person access control — not a certification.

Can we share ITAR technical data on the cloud without an export license using the §120.54 end-to-end-encryption carve-out?

Yes — sending, taking, or storing ITAR technical data via the cloud is not an export under 22 CFR §120.54(a)(5) when four conditions hold: the data is unclassified; it is secured with end-to-end encryption; the encryption uses FIPS 140-2 modules or cryptographic means at least as strong as AES-128; and it is not intentionally sent to or stored in a §126.1 proscribed country (which now includes Russia). The EAR mirrors this at 15 CFR §734.18(a)(5). The critical qualifier in §120.54(b)(1)(ii) is that the means of decryption are not provided to any third party — including your cloud provider. Encryption neutralizes the transit and storage as an export event, but it does not authorize you to let an unauthorized foreign national view the data. That is a separate control. This is general information, not legal advice — confirm with your export-control counsel.

Does our cloud vendor being able to see or decrypt our files count as an unauthorized export — and what makes a room zero-access?

If your provider can decrypt your files, you lose the §120.54 carve-out, because §120.54(b)(1)(ii) requires that the means of decryption are not provided to any third party — and your cloud provider is precisely that third party. A room is zero-access when the provider holds only ciphertext and never holds the decryption keys, so the provider's ability to touch the data is, in the regulation's own words at §120.54(c), not a release or export because it is access in encrypted form only. The tell is server-side features: any platform that runs indexing, preview, search, redaction, or AI over your document contents necessarily has decrypted access. Peony defaults to zero data pass-through — Peony has no access to the contents of your rooms by default; nothing is read, mined, or passed to a third party, and AI features run only against models you connect, with zero retention.

How do we restrict access to US persons only so a foreign national can't view our drawings?

You restrict access to US persons by gating viewing per identity, not per shared link, and by making the US-person determination yourself before you grant access. Under ITAR, a US person is a US citizen or national, a lawful permanent resident (green-card holder), or a protected individual — the line is immigration status, not citizenship alone, so a work-visa holder is generally a foreign person. In Peony, you place verified US-person recipients into visitor groups, bind each person's access to their identity with two-factor authentication and per-email links, and keep foreign nationals out of the group entirely. Peony enforces and logs your determination; it does not screen or certify people — US-person verification and denied-party screening remain your process, the same division as KYC in other regulated verticals. This is general information, not legal advice.

How do per-person access controls and identity-bound links actually prevent a deemed export?

They prevent a deemed export by making decryption-and-viewing possible only for the specific authorized person you named, so an unauthorized foreign national never reaches the unencrypted data. A deemed export happens the moment a foreign national views controlled technical data — that view is a release to their country of nationality. A shared link that anyone can forward cannot enforce this; an identity-bound link can. Peony ties each grant to a verified email with two-factor authentication, so the credential is not transferable, and dynamic watermarks stamp each viewer's identity onto every rendered page to deter and trace re-sharing. Because access is per-person, if a partner's status changes or a program ends, you revoke that one person without disturbing anyone else. Encryption handles the storage-and-transit prong; per-person access control handles the deemed-export prong.

How do we set up an audit trail of who viewed our ITAR technical data to defend an export-enforcement action?

You set up the audit trail by using a platform that logs every access event — who opened which document, which pages, when, and for how long — and by retaining those logs as your evidentiary record. In an export-enforcement action or a voluntary disclosure to DDTC, the log is the evidence that no unauthorized person accessed the data, or the honest record of exactly what happened. Peony page analytics capture per-person, per-page view history automatically, so you are not reconstructing access after the fact from email threads. Pair that with revoke-access to cut off a recipient the instant a status changes, and NDA gates that record an acknowledgement before controlled access. The discipline is simple: if you cannot prove who saw a controlled file, you cannot prove you stayed compliant. This is general information, not legal advice — confirm your recordkeeping obligations with counsel.

How do we segregate ITAR from EAR/ECCN files — and share DDTC/BIS license-application documents — in one data room?

You segregate them by using separate visitor groups and separate document sets with distinct permissions, so an ITAR-USML technical package and an EAR/ECCN-controlled file each reach only the recipients authorized for that specific item. The two regimes have different rules, so blending them into one permission bucket is how mistakes happen. In Peony, create a group per authorization scope — one for a US-person-only ITAR set, another for an EAR item shared under a specific license — and assign documents to groups, not to individuals ad hoc. For DDTC or BIS license-application supporting documents, you can stand up a dedicated room, grant scoped access, watermark every page, and log all activity, so the regulator sees exactly the package intended and nothing else. You still make the jurisdiction and classification calls; Peony enforces the boundaries you draw.

We're sharing ITAR technical data over email and generic cloud drives — how bad is our exposure and what do we do first?

It is a serious exposure, because email and standard cloud drives fail on two fronts at once: the provider can decrypt your files, breaking the §120.54 carve-out, and a forwarded attachment or shared link can reach a foreign national with no gate and no log — a potential deemed export you cannot even detect. Triage in this order: first, stop sending controlled technical data as email attachments immediately. Second, inventory where controlled files currently live and who has had access. Third, move active sharing into a room where the provider cannot read the data and access is gated per US person with a full audit trail. Fourth, document what happened and talk to your export-control counsel about whether a voluntary disclosure is warranted. Fixing the channel is fast; the review of past exposure is where your empowered official earns their title.

Is a foreign national viewing our maintenance manual really a deemed export, and what are the penalties?

Yes — a foreign national viewing controlled technical data, including a USML-origin maintenance manual or drawing, is a deemed export to that person's country of nationality, and no shipment abroad is required for it to be a prosecutable export. The penalties are severe. ITAR civil violations run up to $1,271,078 per violation (the 2025 inflation-adjusted figure) or twice the value of the transaction, whichever is greater, and they are counted per act. Willful violations are criminal: up to $1,000,000 per violation and up to 10 years' imprisonment, plus likely debarment from ITAR-regulated activity. The canonical case is US v. Roth, where a professor was criminally convicted and sentenced to prison for giving foreign-national graduate students access to controlled drone technical data — access alone, no export shipment. Per-person access control is not paranoia; it is the unit of compliance.

How does an ITAR data room compare to SharePoint GCC High or a FedRAMP platform — do we need CMMC or FedRAMP too?

They solve different problems, so which you need depends on your contract, not on the word 'ITAR.' GCC High and CMMC address protecting Controlled Unclassified Information under DFARS 252.204-7012 and NIST SP 800-171 — a contract and cybersecurity-maturity problem. The §120.54 encryption carve-out addresses whether putting export-controlled technical data in the cloud counts as an export — a different question. FedRAMP authorization is required when the customer is a federal agency, or FedRAMP-Moderate equivalency enters via DFARS -7012 for DoD CUI in the cloud; it is generally not required for private-sector B2B sharing of ITAR data. Peony is not FedRAMP-authorized. If your contract flows down a FedRAMP or GCC High requirement, use GCC High for that scope — that is the right answer and a different lane. For lawful cloud sharing of ITAR technical data under the carve-out, a zero-access data room with US-person gating is the fit.

How much does an ITAR-compliant data room cost for a 50-person defense supplier, versus the fine for a deemed export?

A zero-access data room typically costs on the order of $30 to $52 per admin per month, with viewers usually free, so a 50-person supplier is generally looking at a few hundred dollars a month depending on how many people administer rooms rather than just view them. Compare that to a single ITAR civil violation at up to $1,271,078, counted per act — and enforcement is counted per file and per person, so one careless share can multiply into dozens of violations, as in the 3D Systems settlement of $20,000,000 over 132 violations. It is also far cheaper than a GCC High migration project, which is a genuine multi-month program you should only take on if a contract requires that scope. The honest math: the tool is a rounding error against the exposure, but the tool alone does not make you compliant — your program does.

The bottom line

Nobody can sell you an "ITAR-compliant data room," and the vendors who try are the ones to walk away from. What you can buy is an architecture that lets you use the §120.54 carve-out lawfully: end-to-end encryption where the provider holds no means of decryption, so the cloud storage and transit are not an export; and per-person, US-person-gated, fully logged access, so a foreign national never views what they aren't authorized to see and you can prove it. Peony defaults to zero data pass-through and gives you the visitor groups, watermarks, two-factor binding, revocation, and page-level audit trail that operationalize the deemed-export prong — while being honest that it does not classify your data, does not screen your people, and is not FedRAMP-authorized for the contracts that require that separate lane.

That honesty is the point. The regime puts compliance on you — your classifications, your determinations, your program — and the right tool makes the correct behavior enforceable and the record provable. If you operate surplus military aircraft, run an MRO shop, supply defense parts, or export ECCN-controlled technology, and you're still moving controlled documents over email, the channel is the first thing to fix. We serve 5,900+ customers, and for the ones in this vertical, the provider-no-access default is exactly why they're here. Explore the defense and aerospace solution, or start with pricing.

This article is general information, not legal advice, and does not create any attorney-client or advisory relationship. Export-control determinations — jurisdiction, classification, US-person status, licensing, and voluntary disclosures — should be confirmed with your export-control counsel or empowered official before you rely on them.