Security questionnaires punish vague answers. “We encrypt everything” stalls deals; precise key-custody language closes them. Buyers are not asking whether you know AES exists—they are asking who can read the documents if your admin account or ours is compromised.
Use this guide to answer document-encryption questions with evidence—whether you evaluate Compliance Locker or any sealed vault.
Questions that actually matter
- Where does encryption and decryption run—browser/client or server?
- Who can unwrap file keys under normal operation?
- How are share decryption keys delivered to recipients?
- What metadata remains visible to the operator?
- What does account recovery imply about key escrow?
- What access events can you export for an audit?
For the architectural split behind those answers, read client-side vs server-side encryption and what zero-knowledge means for documents.
Answer patterns that survive review
Encryption in transit and at rest
State TLS for transport and ciphertext at rest. Then add the differentiator: whether the application can decrypt on the server to provide features, or whether plaintext is only available on authorized clients.
Key custody
Name the model: client-held keys derived from a user secret; server stores ciphertext and wrapped key material it cannot unwrap alone. If that is not true, do not imply it.
Sharing
Describe expiry, view limits, optional passwords, watermarks, and how share keys stay off ordinary server logs (for example URL fragment delivery). Link to your security page—not a slogan.
Auditability
List event types you can export. Do not promise WORM or attestation you do not have. See what auditors ask for.
Sample concise answers (adapt to facts)
“Can vendor employees read our files?”
Under normal operation, Compliance Locker operators cannot decrypt customer document plaintext because encryption and key unwrapping happen client-side. Operators still process account, billing, and operational metadata required to run the service.
“Do you support customer-managed keys / CMEK?”
CMEK and client-side vault encryption answer different questions. CMEK controls cloud KMS use; client-side encryption keeps usable document keys off the application server. Say which you offer—do not conflate them.
“How do you prevent oversharing?”
Policy knobs: default expiry, max views, optional passwords, revoke, and watermarks—plus operational guidance to avoid eternal mega-folders.
What not to write
- “Military-grade encryption” without key custody detail
- Implied certifications you have not completed
- “Zero logs” when you clearly retain account and access metadata
- Copy-pasting Drive admin log capabilities as vault evidence
For claim-safe product language, start from Trust and Compliance.
FAQ
Does ‘AES-256’ answer the encryption question?
No. Algorithms matter, but reviewers care where encryption runs and who can unwrap keys. AES-256 with server-held keys is a different control than AES-256 with client-held keys.
Is zero-knowledge the same as ‘vendor cannot access data’?
For document plaintext under normal operation, that is the intent—if the product truly keeps usable keys off the server. Metadata, account data, and support channels still exist. Be precise.
Should we claim SOC 2 or HIPAA because we encrypt?
No. Encryption supports governance; it is not a certification. Answer framework questions with evidence you actually have—see our Trust and Compliance pages for claim-safe language.
What evidence should we attach?
Architecture summary, key custody description, share-control defaults, and sample (redacted) activity export fields—not marketing one-pagers alone.
How do we answer recovery / password reset?
State whether the vendor can restore vault access without the user’s secret. Frictionless recovery usually implies recoverable key material—say so honestly.
Related: Client-side vs server-side encryption, Security overview.