“Is cloud storage safe” bundles four different questions together, and they have different answers. Separating them turns an anxious question into a set of decisions.
Risk one: losing the files
This is the risk people consistently underrate, and the one cloud storage helps most with.
A laptop can be dropped, stolen, or simply fail - drives have a meaningful annual failure rate and give little warning. An external drive on the same desk fails in the same flood, fire or burglary, which is why “I have a backup drive” is less reassuring than it sounds.
Storage that keeps redundant copies across professionally run infrastructure is substantially more durable than any single device, and it is not close.
If your files exist in exactly one place right now, that is the risk to address first, ahead of anything more exotic. The realistic thing that destroys your data is not an attacker; it is a hardware failure on a Tuesday.
Risk two: someone getting into your account
This is the realistic attack, and it almost never involves defeating encryption. It involves a password.
The routes that actually get used: credentials reused from an unrelated breach and tried everywhere; a convincing phishing page; malware on the machine you log in from; and session tokens stolen from a browser. These work because they are cheap and they scale.
The defences are unglamorous and effective:
A unique password, which in practice means a password manager. Reuse is the mechanism that turns someone else’s breach into your problem.
Two-factor authentication, which turns a stolen password into a non-event. An authenticator app or a hardware key is meaningfully stronger than SMS, which is vulnerable to SIM swapping - though SMS is still far better than nothing.
Separate credentials for applications and scripts, so revoking one does not mean changing everything. Our guides to SFTP and server backups cover scoping these properly.
Reviewing active sessions occasionally, and signing out ones you do not recognise.
Risk three: the provider’s own security
You are trusting an organisation’s engineering and operations. That trust is reasonable to interrogate rather than assume.
Signals worth looking for: encryption in transit and at rest as an unremarkable baseline; a published security contact and a route for reporting vulnerabilities; clear statements about where data is stored; and an audit trail you can inspect yourself, so account activity is a matter of record rather than assertion.
For material where you would rather not extend that trust at all, end-to-end encryption changes the shape of the problem entirely: the key is derived on your device, so what is stored is ciphertext. The trade-offs are substantial and worth understanding before reaching for it - what zero-knowledge actually means covers them, including the loss of search, previews and protocol access, and the fact that losing your key material means losing the data.
Risk four: accidents and other people
The most common data loss event is not an attack. It is somebody deleting the wrong folder, or a share link that outlived the project by two years.
File versions and a recoverable trash address the first. Check the retention window before you need it - discovering it is seven days on day eight is a bad way to learn.
Deliberate expiry on share links addresses the second. Links accumulate silently because nobody is assigned to review them; setting a date at share time is the only approach that survives contact with real working habits.
Access controls address the case where forwarding is the concern - a password for casual protection, restricting to named addresses for anything with real consequences, as covered in sharing sensitive documents.
In an organisation this is mostly a permissions question. Our guide to team folders and roles covers giving people the access they need and no more, and removing it when they change roles.
If you think an account has been compromised
Order matters here, and the instinctive first move is the wrong one.
Change the password first, then revoke sessions. Doing it the other way round lets an attacker holding a live session simply set a new password themselves.
Revoke every active session, not just the ones you do not recognise. A stolen session token keeps working after a password change unless sessions are explicitly terminated - this is the step people miss, and it is why “I changed my password” sometimes fails to end an incident.
Rotate application credentials and API keys. These usually survive a password change by design, which is convenient right up until it is not.
Check the audit trail for what was accessed, from where, and whether anything was shared or deleted. Look specifically for share links created that you did not create - that is how data leaves after an account compromise, and it persists after you have locked the attacker out. What a useful trail contains covers why denied attempts matter here too.
Then turn on two-factor authentication if it was not already on, and check your email account, which is usually the actual entry point.
What actually happens, in proportion
If you ranked real incidents by frequency, the order is roughly: accidental deletion, then account compromise through a weak or reused password, then device loss, then - far down the list - anything involving the provider being breached.
Most people’s security effort is distributed in almost exactly the reverse order.
A sensible baseline
Turn on two-factor authentication today. Use a password manager. Keep a second copy of anything irreplaceable, in a different place from the first. Put expiry dates on external shares. Check the trash retention window. Review who has access to shared folders when someone leaves.
None of that is exciting, and it addresses the overwhelming majority of what actually goes wrong.
