What can a workspace tool actually produce under a subpoena?
A practical breakdown of what Slack, Notion, Google Workspace, Microsoft 365, Dropbox, and Koaich can produce in response to a legal demand — and why architecture determines the answer more than policy does.
Workspace tools receive legal demands routinely. Subpoenas, search warrants, civil discovery motions, regulatory inquiries — major SaaS vendors get them weekly, sometimes daily. The relevant question for a sophisticated buyer is not whether a vendor will receive a legal demand (they will), but what the vendor can produce in response.
What a vendor can produce is determined by what they hold. A vendor that holds cleartext data can produce cleartext data. A vendor that holds ciphertext under user-held keys can produce only ciphertext — and metadata. The cryptographic architecture sets the upper bound on legal disclosure, regardless of the vendor's intent or policy.
Slack
Slack stores message content in cleartext on its infrastructure. Under a valid subpoena or search warrant, Slack can produce: messages (sent and received), files attached to messages, channel membership history, account metadata (emails, IPs, login timestamps), workspace and user IDs, integration data.
Slack publishes a transparency report. The 2024 numbers were in the high thousands of legal requests per year, with content disclosed on a substantial subset.
Notion
Notion stores document content in cleartext on its infrastructure (server-side encryption with Notion-held keys). Under a valid legal demand, Notion can produce: documents and pages, attached files, comments, version history, workspace membership, account metadata.
Notion publishes a transparency report. Their disclosure rate to legal demands is lower-volume than Slack but the architectural ceiling is the same: cleartext content is producible.
Google Workspace
Google Workspace stores content in cleartext for the default tiers. Under a legal demand, Google can produce: Gmail messages, Drive files, Calendar events, Meet recordings, Docs/Sheets/Slides content, account metadata, location data tied to the account.
Customers using Client-Side Encryption (CSE, available on Enterprise Plus) provide their own key service. For CSE-covered surfaces, Google produces ciphertext only — the customer holds the key. Google publishes a transparency report.
Microsoft 365
Microsoft 365 stores content in cleartext for the default tiers. Under a legal demand, Microsoft can produce: Exchange Online mail, OneDrive files, SharePoint documents, Teams messages, Calendar events, OneNote content, account metadata.
Customers using Customer Key (M365 E5) supply their own at-rest encryption keys via Azure Key Vault HSM. The runtime data path is still decrypted by Microsoft's services for product features (Copilot, search, indexing). Customer Key reduces what's accessible at rest but doesn't eliminate the cleartext path. Microsoft publishes a transparency report.
Dropbox
Dropbox stores files in cleartext on its infrastructure (encryption-at-rest with Dropbox-held keys). Under a legal demand, Dropbox can produce: file content, file metadata, sharing links, access logs, account information.
Dropbox's transparency report shows several thousand legal requests per year with disclosure on the majority. The architecture allows it; the policy regulates how Dropbox responds to specific requests.
Signal
Signal stores messages encrypted end-to-end; the keys are user-held. Under a legal demand, Signal can produce: account creation date, last connection date (rounded to day-level granularity), the phone number associated with the account. That's it.
Signal's documented response to several high-profile subpoenas confirms this — they have no message content to produce. The cryptography sets the ceiling.
Koaich
Koaich stores messages, documents, and files as ciphertext under user-held keys. Under a legal demand, Koaich can produce: account metadata (email at signup, account creation date), structural data (which vaults exist, how many members each has, message counts and timestamps), and ciphertext blobs that we cannot decrypt.
We cannot produce content — not because of a policy choice we'd make under pressure, but because we don't hold the keys. This is the property end-to-end encryption is for.
What this means for risk assessment
If your workspace tool stores content in cleartext, the universe of parties that can compel disclosure of your content is large — government agencies, civil litigants, regulators, foreign authorities operating through MLAT treaties, intelligence services operating through national security letters. The vendor's privacy policy describes intent; the architecture describes what's possible.
If your workspace tool holds ciphertext under your keys, that universe shrinks to metadata. For client work, regulated industries, journalism, legal practice, and other contexts where structural disclosure-resistance matters, this is the bet that's worth making.