A printable security questionnaire for evaluating any workspace, messaging, or storage vendor. Use it as-is, paste it into an RFP, or hand it to your compliance team. Free to use, no attribution required (but appreciated).
WHY IT MATTERS:If the vendor holds them, they can decrypt your content whenever they choose, are compelled to, or are compromised. The only honest "we can't read your data" answer is one where the keys never reach the vendor's servers.
WHY IT MATTERS:Keys generated on your device, never transmitted to the server, are the strongest property. Keys generated server-side and "protected" by the vendor are weaker by an order of magnitude.
WHY IT MATTERS:If yes, the vendor holds a copy of your data somewhere they can decrypt. The honest answer for a zero-knowledge vendor is "no — recovery depends on shares you hold across your own devices."
WHY IT MATTERS:Most vendors' support tooling can read customer content directly. A vendor that says "only metadata" has done the architectural work to make that true.
WHY IT MATTERS:"Encrypted at rest" is satisfied by a database file that's encrypted, even if the vendor holds the keys. "Engineers see ciphertext" requires end-to-end encryption with user-held keys.
WHY IT MATTERS:Vendors that haven't audited this internally probably can't answer. Vendors that have an honest answer — even an uncomfortable one — are doing the work.
WHY IT MATTERS:Common patterns: (1) sent to the vendor's own model, retained for training; (2) sent to a third-party model provider (OpenAI, Anthropic); (3) processed client-side with model access via API but no retention. Each has very different privacy properties.
WHY IT MATTERS:The honest options are "no, never," "yes by default, you can opt out," "yes on certain tiers," or "depends on the third-party model provider's policy." Vague answers usually hide one of the last three.
WHY IT MATTERS:Client-side context construction + server-blind orchestration is possible (Koaich does it). Most workspace AI does not — the AI needs cleartext access on the server to operate.
WHY IT MATTERS:A vendor that holds the keys can produce content. A vendor that doesn't can only produce metadata. The first one's "strong privacy policy" doesn't change what the architecture allows.
WHY IT MATTERS:Vendors that publish this — Signal, Apple, Cloudflare, Microsoft — show their work. Vendors that don't are choosing not to be auditable on this dimension.
WHY IT MATTERS:An honest "yes" with context (volume, type of request) is fine. An honest "no — we have no content to produce" is the architectural answer. "We can't comment" is a soft signal.
WHY IT MATTERS:Every vendor of scale will be breached eventually. What matters is what an attacker walked away with. A vendor with a clean record might also just be one nobody's bothered to attack yet.
WHY IT MATTERS:This is the "blast radius" question. A vendor whose servers hold cleartext or vendor-held keys answers "everything." A vendor with end-to-end encryption answers "nothing — they get ciphertext under keys we don't hold."
WHY IT MATTERS:The policy is less important than that one exists. Mature vendors have one; less mature ones don't.
WHY IT MATTERS:Vague "bank-grade encryption" marketing is a red flag. Specific protocols (Signal Protocol, MLS, nacl.box) cited with version numbers are the opposite.
WHY IT MATTERS:Cure53, Trail of Bits, NCC Group, Doyensec are reputable firms. "Pending" or "in process" is acceptable for new vendors. "Industry-leading" without a named firm is marketing language.
WHY IT MATTERS:For native apps, this means reproducible builds + signature verification. For web, this means a code transparency log (Sigstore-style) or similar. Most vendors don't have this; vendors that do take security seriously.
WHY IT MATTERS:Every workspace vendor uses sub-processors. The question is whether each sub-processor receives cleartext or ciphertext. A vendor that hands cleartext to a CDN multiplies the attack surface.
WHY IT MATTERS:Acquisition is the most common path to a vendor's privacy posture changing without users noticing. Vendors with cryptographic guarantees can answer this honestly; vendors with policy guarantees often can't.
We wrote the questions, so we should answer them publicly. Our complete answers — what we hold, what we don't, what's on the roadmap — are at /security, with the full metadata inventory in §6.5.