Cloud encryption: who can read the data, and who holds the keys?
Understand encryption in transit, at rest and end to end through a document-sharing example and a practical supplier questionnaire.
“Encrypted” is an incomplete answer to a security question. It may describe the connection, the storage device or a design in which the service provider cannot normally decrypt the content. To compare services, ask what is encrypted, when it becomes readable and who can authorise that operation.
A strong algorithm is only one part of the answer. The key's location, access permissions, recovery process and the places where plaintext appears determine what the system actually protects.
Follow a document through the service
Imagine uploading a fictional engineering report from a laptop. The browser establishes an HTTPS connection. The server receives the report, creates a preview, indexes its text and stores it. A colleague later opens the preview from another device.
TLS protects the communication channel between its endpoints. In this example, the application server is an endpoint and can process the report. “Encrypted in transit” therefore does not mean the server cannot read it. IETF: TLS 1.3, RFC 8446.
Encryption at rest protects stored data under a particular key and access model. If the application can retrieve the key and decrypt the report to create previews, the provider's system has a decryption path. That may be appropriate for the service, but it is different from provider-inaccessible content.
End-to-end encryption changes the boundary
In an end-to-end encrypted design, content is encrypted for the intended endpoints and the intermediary service is not meant to possess the keys needed to read it. The details still matter: which endpoints, which data, which sharing operations and which recovery arrangements?
If previews or search run on the user's device, that may fit such a design. If a server reads the plaintext to perform them, ask how that processing fits the claimed boundary. Some systems offer different protection for different features rather than one uniform model.
Do not infer end-to-end encryption from “AES-256”, “customer-managed key” or “zero knowledge” alone. Request a clear data-flow explanation and the conditions under which decryption can occur. NIST's foundational cloud key-management report explains why ownership and control of keys require explicit consideration in cloud services. NIST IR 7956.
| Claim | Useful evidence | Does not establish by itself |
|---|---|---|
| TLS | Protected connection to the intended server | That the provider cannot read content |
| Encryption at rest | Coverage of stored data and control of keys | Protection from every authorised application or administrator |
| End-to-end encryption | Content keys at intended endpoints; documented recovery and sharing | A safe endpoint, hidden metadata or recoverability after all keys are lost |
A worked choice between two fictional services
Service A encrypts network traffic and stored files, and its servers decrypt documents for search and previews. Service B encrypts document contents on client devices and performs supported searches locally. Assume these descriptions have been verified for the relevant features.
For a team needing central server-side processing, A may meet its approved requirements if access, administration and contractual controls are appropriate. For content that must remain unreadable to the intermediary, B's design may be a better fit, but only after evaluating its sharing and recovery details.
Neither choice is proved by the marketing label. A can have strong operational controls; B can still expose data through a compromised endpoint or an authorised recipient. The decision should follow the actual confidentiality requirement and workflow.
Ask about data outside the main file
List previews, extracted text, filenames, folder names, participant identities, timestamps, logs, notifications, exports and backups. Which are covered by the same encryption boundary? Metadata can reveal useful information even when file contents are protected.
Also ask what happens when an attachment is emailed, a public link is created or an integration processes a document. A protected original does not automatically protect every derivative. Once a recipient downloads a readable copy, later revocation of the online link cannot recall that copy from their device.
Recovery is part of the design
If the only decryption key is lost and no recovery mechanism exists, resetting the account password may restore sign-in without restoring readable data. Conversely, an administrator-assisted recovery mechanism implies an additional authorised path that should be understood and controlled.
Test recovery with non-sensitive sample data before relying on the service for unique records. Document who may recover, how authority is checked, what is logged and whether a departing employee's files remain accessible through an approved organisational process.
A short supplier questionnaire
- Where is content readable during upload, processing, sharing and recovery?
- Which parties can obtain or use decryption keys, including administrators and integrations?
- Are backups, previews and metadata covered, and what exceptions apply?
- What happens when keys, devices or administrator access are lost?
- Can the organisation export usable data without depending indefinitely on the supplier?
- Which claims have independent evidence, and what does that evidence actually cover?
Record answers for the selected plan and configuration, not just the brand. This article explains evaluation concepts; it does not claim that WorkStudio or any named product implements a particular encryption model.
Enable JavaScript to use reading progress and usefulness ratings.