Secure cloud storage services: a 5-point security audit

“Encrypted” is not a security result. It is a transport or storage property. A cloud provider can encrypt files in transit, encrypt them at rest, retain the ability to decrypt them, expose operational metadata, offer weak recovery controls, and still market the service as secure.

Secure cloud storage services need to be evaluated as a control stack. The relevant variables are encryption scope, account takeover resistance, sharing permissions, recovery behavior, and independently verifiable evidence. A failure in one layer can nullify the others. End-to-end encrypted storage does not compensate for a phishable account login. A FIDO2 key does not make an unrestricted public link safe. Version history does not replace an offline backup.

This audit uses five test points. It does not produce a universal score. Consumer and business plans differ materially, even within the same provider. The data shows that plan-level detail is often where the usable security controls are hidden.

Security is not a badge. It is the behavior of the service when a password is reset, a link is forwarded, or a synced folder is encrypted by ransomware.

1. Separate transport encryption from end-to-end encryption

Every credible cloud service should encrypt data in transit and at rest. These are baseline controls, not a privacy verdict.

Encryption in transit protects a file while it moves between the client device and the provider’s infrastructure. Encryption at rest protects the stored data on servers and storage media. Both reduce exposure from network interception and physical storage compromise. Neither answer the central question for private cloud storage: who can decrypt the file content?

A conventional cloud service generally manages encryption keys on behalf of the account. This enables browser previews, server-side search, password resets, content scanning, and managed recovery. It also means the provider may have a technical path to file contents under defined internal processes.

Zero-knowledge encryption providers use a different model. The client encrypts content before upload, and the provider is designed to operate without the decryption secret. This model reduces provider-side access to contents. It also moves recovery risk to the user. If the password, recovery phrase, and recovery file are lost, the encrypted data may be permanently inaccessible.

The audit should establish the actual encryption boundary:

• File contents: Are documents, photos, and archives encrypted before leaving the device?
• Filenames and folder names: Are they encrypted, or does the service retain them for indexing and interface functions?
• File sizes and timestamps: These fields may remain operationally visible even in end-to-end encrypted storage.
• Permissions and sharing records: The provider may need access to recipient identities, access rules, and sharing events.
• Search index: Determine whether search is performed locally, through encrypted indexes, or by the provider after server-side decryption.
• Key recovery: Identify whether the provider can restore access after a forgotten password. That convenience has an architectural implication.

Proton Drive, for example, states that its end-to-end encryption can cover file contents, filenames, and folder names. Its service still processes operational data such as creation and modification times, permissions, and the uploader’s username. That is not a contradiction. It is the normal distinction between encrypted content and service metadata.

The same distinction applies to file previews, collaboration, and cross-device sync. A cloud platform can make a strong encryption claim while retaining enough metadata to operate the service. The private cloud storage audit must test each category independently.

The recovery test exposes the real model

Password recovery is not a support detail. It is a key-management test.

If an end-to-end encrypted service permits a password reset, determine what happens to previously encrypted files. In a strict design, resetting account credentials without an old password or recovery key can leave historical files inaccessible. This is expected. The old data was encrypted with keys derived from or protected by credentials the provider does not possess.

A provider that can transparently restore all encrypted files after any password reset may offer useful account recovery. It may also retain a recovery capability that needs to be understood before placing sensitive archives in the service.

Do not treat either architecture as automatically correct. The trade-off is measurable:

2. Test authentication for phishing resistance, not just MFA presence

“MFA enabled” is insufficient audit output. The method matters.

Authenticator-app codes, SMS codes, and email codes add a second factor. They reduce the impact of a leaked password. They do not reliably prevent phishing because a fraudulent site can request the code and relay it to the legitimate service in real time.

NIST distinguishes this clearly. At Authentication Assurance Level 2, the user must prove control of two distinct factors, and the application must offer a phishing-resistant authentication option. A manually entered one-time password does not meet that phishing-resistant definition.

For secure file hosting features, the preferred authentication hierarchy is direct:

1. FIDO2 or U2F hardware security key. This is the strongest common consumer-facing option. The authentication exchange is bound to the legitimate site origin. A fake login domain cannot simply collect and replay the credential.

2. Passkey, where implemented with appropriate platform controls. Passkeys can provide phishing resistance, but the audit should verify device synchronization, account recovery, and fallback methods.

3. Authenticator-app TOTP. A material improvement over passwords alone. Still vulnerable to real-time phishing and social engineering.

4. SMS or email codes. Better than single-factor login, but dependent on cellular-account and mailbox security. These should not be the only available second factor.

The audit also needs to test fallback paths. A service can support FIDO2 security keys yet undermine them with weak recovery options. Review the following points in the account console, not just on a marketing page:

• Can a password reset be initiated solely through email access?
• Does recovery require a waiting period or identity re-verification?
• Are backup codes available, and where are they stored?
• Can security keys be removed without presenting an existing second factor?
• Does a recovery action invalidate active sessions on other devices?
• Are login alerts generated for new locations, browsers, or devices?
• Does the provider permit multiple hardware keys? It should. One key is a single point of failure.

Proton documents support for authenticator-app two-factor authentication and U2F/FIDO2 keys. That is a stronger control set than a TOTP-only service. The practical result still depends on the user registering at least two physical keys, retaining recovery material offline, and removing less secure fallback methods where the service permits it.

MFA is a category. Phishing resistance is a property of a specific authentication method.

A password manager also belongs in this test. Reused passwords remain a high-frequency account takeover path. Unique, high-entropy credentials reduce the value of a breach at another service. The password manager itself should be protected with its own MFA and recovery review. Moving credentials into a weak vault does not improve the system.

3. Measure sharing controls against the recipient path

Encryption controls file storage. Sharing controls govern distribution. These are separate systems, and providers often apply them at different plan tiers.

A secure storage account can create an insecure sharing event in one click. A public link may be forwarded, copied into a chat, indexed by a third-party service, or opened on an unmanaged device. Link protection changes the exposure level but does not make a link equivalent to a named-user permission model.

The audit should create a non-sensitive test folder and inspect what the service actually permits:

• Named-user sharing: Can access be granted to a specific account rather than anyone holding a URL?
• Permission granularity: Are view, comment, edit, upload, download, and reshare rights separated?
• Link passwords: Are they available on the current plan, and are passwords transmitted separately from the URL?
• Expiration dates: Can the link expire automatically? Is the expiry time precise or only date-based?
• Download restriction: Does the platform limit browser downloads, or does it merely hide the visible button? A recipient with screen access may still capture content.
• Revocation: Can the owner immediately remove a recipient, disable a link, or revoke a session?
• External-domain controls: On business-oriented plans, can sharing be restricted to approved domains?
• Activity logs: Does the owner receive a record of link creation, recipient changes, downloads, or failed access attempts?

Dropbox documents password protection and expiration dates for shared links on specified paid plans. These controls are useful, but their limits matter. A link restriction does not change the permissions of a person who already has direct access to the folder or file. The owner must revoke the direct permission separately.

This is where many cloud security verification exercises fail. They test a link, see a password prompt, and stop. The correct test uses three identities:

1. A recipient with direct folder access.

2. A recipient accessing only through the link.

3. An unauthenticated browser session.

Remove access and re-test all three. The service should make the resulting permissions explicit. If it does not, treat the ambiguity as an operational defect.

Sharing also creates metadata. Even an end-to-end encrypted service may need to record who shared a file, when access was granted, and which account holds a permission. For digital artists and collectors managing work-in-progress files, wallet-related documents, or release assets, the broader relevance of digital privacy for artists and global audiences is not abstract: sharing metadata can identify collaborators and timing even when the asset itself is encrypted.

4. Audit version history as a retention policy, not a backup system

Sync is replication. It is not backup.

If a corrupted file is synchronized, the corruption can propagate. If ransomware encrypts a local folder and the sync client uploads those encrypted versions, the cloud copy can be affected as well. If an account holder permanently deletes a file and the retention window passes, version history may provide no route back.

The practical test is a deletion and overwrite drill. Use a disposable folder. Upload several files. Modify one, delete another, empty any trash or deleted-items area, then inspect restoration behavior from a different device. Record the exact retention period and the point at which restoration becomes impossible.

Dropbox provides a clear example of why plan comparison is necessary. Its documented version history is 30 days on Basic, Plus, and Family plans; 180 days on several professional and business tiers; and up to 365 days on Business Plus, Advanced, and Enterprise plans. Permanently deleted items cannot be restored through version history.

Those figures are not a universal benchmark. They are a reminder that a provider name does not define a recovery capability. The subscription tier does.

The recovery audit should document four separate timers:

Ransomware resilience requires a separate backup architecture. CISA recommends offline, encrypted backups, regular tests of backup availability and integrity, and consideration of delete protection, object lock, and version controls where they are supported.

For a consumer account, the minimum practical implementation is an encrypted local backup drive that is disconnected after completion. For a small business, the requirement is stronger: separate credentials, separate administrative control, a documented retention period, and restoration testing. A backup that has not been restored is an unverified assumption.

Do not confuse a long version-history period with immutability. A retention window may help recover files after a local compromise. It does not necessarily prevent a compromised account owner or administrator from deleting versions, changing retention rules, or removing the backup repository itself.

5. Treat SOC 2 and ISO 27001 as evidence, not a conclusion

Compliance language is frequently compressed into a marketing claim. The audit needs to expand it again.

SOC 2 is an examination of organizational controls relevant to areas such as security, availability, processing integrity, confidentiality, and privacy. ISO/IEC 27001:2022 specifies requirements for an information security management system. Both can indicate that a provider has formal processes, control ownership, risk management, and an audit framework.

Neither certification establishes that every customer file is end-to-end encrypted. Neither proves the provider cannot access file contents. Neither guarantees the absence of a breach.

The relevant question is not whether a logo appears on a provider’s security page. It is what the report or certificate covers.

A useful assurance review has four parts:

• Scope: Does it cover the storage service, mobile apps, identity infrastructure, data centers, and support operations, or only a subset?
• Date: Is the audit period current? A report can describe controls that have since changed.
• Type: For SOC 2, distinguish a report examining control design from one examining operation over a period of time.
• Exceptions: Were there qualifications, excluded systems, or identified control gaps? A badge does not display these details.

The Cloud Security Alliance’s Cloud Controls Matrix is another useful reference point for enterprise evaluations. Version 4.1 contains 207 controls across 17 security domains. It is not a consumer shopping score. It is a structured way to ask whether a provider has documented controls for identity, application security, logging, data protection, and incident response.

For individual users, the compliance review should remain proportionate. Do not demand enterprise documentation from every personal storage subscription. But do demand precise answers to basic architectural questions: where keys reside, how recovery works, which sharing controls exist on the purchased tier, how long recovery artifacts survive, and what happens after permanent deletion.

A provider that answers those questions clearly is easier to evaluate. A provider that substitutes generic “military-grade encryption” language is not.

The operational verdict

Secure cloud storage services should pass all five audit areas before they hold primary copies of sensitive data. Encryption without account hardening is incomplete. Hardware-key authentication without controlled recovery is incomplete. Controlled sharing without independent backup is incomplete. SOC 2 or ISO 27001 without scope verification is incomplete.

Use the service for the role its controls support.

Buy a cloud storage plan when it provides documented encryption boundaries, FIDO2 or passkey support, understandable recovery mechanics, granular sharing and revocation controls, retention that matches the data’s recovery window, and current assurance evidence with a defined scope.

Skip a provider as a primary sensitive-data repository when its encryption claim does not identify key ownership, its MFA is limited to manually entered codes, its sharing permissions are opaque, its version history is presented as backup, or its compliance claims cannot be tied to a current and relevant control scope.

The data does not support a single “most secure” cloud service across every use case. It supports a stricter conclusion: security claims are only useful after the account, sharing model, recovery path, and retention policy have been tested separately.