Procurement and security reviews keep asking the same blunt question: “Can the vendor read our files?”
Vague answers kill deals. Overclaims kill trust later. This article explains what zero-knowledge document storage actually means—in plain English—and how to answer without theater.
What buyers are really asking
- Can support open our board deck if we ticket them?
- Can a breached vendor dump our contracts in plaintext?
- Who holds the keys—us or the SaaS?
- What metadata still lives on their servers?
Those are fair questions. “We use AES-256” alone does not answer them.
Three trust models (simplified)
1. Collaboration cloud (Drive / Dropbox / Box class)
Provider encrypts and operates the product. Admins and the vendor’s systems are designed to process content to deliver search, previews, and collaboration. Strong enterprise controls exist—different boundary than ZK.
2. Provider-managed “encryption at rest”
Disks are encrypted; the provider typically still holds keys required to run the app. Better than nothing; not the same as customer-held vault keys.
3. Client-side / zero-knowledge vault
Files are sealed in the browser before upload. The service stores ciphertext. Decryption keys are derived locally from customer secrets. Compliance Locker is built on that third model—see Security and what ZK means for business documents.
Honest answer template for questionnaires
Copy and adapt:
Document payloads are encrypted in the user’s browser with AES-GCM before upload. Vault keys are derived locally from the user’s master password; we do not receive the master password in readable form under normal operation. We store ciphertext, account identity, and operational metadata (including access activity). We cannot read document contents as part of routine support. This is a technical control, not a certification that your organization is compliant with a named framework.
Pair that with encryption & key custody answers and client- vs server-side encryption.
What zero-knowledge does not mean
- The vendor sees nothing about your account
- Downloaded files cannot be mishandled by recipients
- You are automatically SOC 2 / ISO / HIPAA compliant
- Forgotten master passwords are recoverable by support
Recovery tradeoffs are real—read master passwords and recovery.
How to evaluate any vendor’s claim
- Where are keys generated and stored?
- Can support decrypt a customer file in the normal product?
- What metadata is retained and for how long?
- How do share links carry key material?
- What happens on account recovery or SSO-only login?
FAQ
Can Compliance Locker staff read our documents?
Under normal operation, document encryption and decryption happen in your browser. We store ciphertext and account metadata—not readable file contents. Operators do not receive your master password in readable form.
What can the vendor still see?
Account data (email, billing), encrypted blobs, share tokens, and audit-style activity metadata. Zero-knowledge for content is not invisibility for all product telemetry.
Is this the same as “the cloud provider encrypts at rest”?
No. Provider-managed encryption at rest usually means the provider holds keys needed to serve the product. Client-side / zero-knowledge designs keep vault keys derived on the customer device.
What if we use Google or Microsoft sign-in?
SSO signs you into the account. It is not used as the vault decryption key. Unlocking sealed files still depends on your master password / local key material.
How should we answer this on a security questionnaire?
Describe client-side encryption, key custody, and what metadata remains server-visible—honestly. See our questionnaire encryption answers guide and Security page.
Related: Trust Center, pricing.