Backup encryption: what it protects and what it doesn’t

When a backup product says “AES-256 encryption”, it sounds like the hard part is done. Your data is safe. End of story.

In reality, encryption is one layer. It protects you brilliantly in some situations, and barely at all in others. If you don’t understand the difference, you can end up paying for “encrypted backups” and still fail the one test that matters: can you restore cleanly when something goes wrong?

This article explains backup encryption in plain English, with the uncomfortable bit included: where it does not help you.

Why the word “encrypted” creates false confidence

Small businesses usually buy backup for two reasons:

• Recovery: “If we delete something or get hit by ransomware, we can get back up and running.”
• Confidentiality: “If someone gets hold of the backup storage, they can’t read our files.”

Encryption mainly solves the confidentiality problem. It does not automatically solve the recovery problem.

That gap is why backup sales pages can be technically true while you still end up stuck. “Your backups are encrypted” can be true even if an attacker can delete them, corrupt them, or prevent you restoring them.

Backup encryption in plain English

Backup encryption means your backup data is scrambled using a cryptographic key. Without the key, the backup should be unreadable.

In practice, backup encryption tends to show up in three places:

• Encryption in transit: protects data while it is moving over the network (for example, from your laptop to the backup cloud).
• Encryption at rest: protects data while it is stored (for example, sitting on backup storage disks).
• Source-side (client-side) encryption: the data is encrypted before it leaves your device, using a key you control.

There is also target-side (server-side) encryption, where the backup platform encrypts the data once it arrives. That can still be useful, but it shifts trust to the provider’s key management.

The key point: encryption is only as strong as your key handling. If the wrong person can get the key, encryption becomes theatre.

A simple way to model what encryption does during an incident

When something bad happens, there are usually two separate questions:

1. Can someone read the backup data? (confidentiality)
2. Can we restore the backup data? (availability)

Encryption mostly targets the first question. It helps when the threat is “someone got hold of the backup storage”.

But most small businesses don’t lose data because a stranger steals a backup disk. They lose data because of things like ransomware, account takeover, accidental deletion, broken sync, or a misconfigured backup job. Those are availability problems, and encryption does not automatically fix them.

Where backup encryption really protects you

1) Lost or stolen backup media

If you have a USB drive, external disk, or NAS that contains backups, encryption is essential. If the device is lost or stolen, the data should be unreadable without the key.

This is the clearest “yes, encryption helps” scenario. Without encryption, a lost drive is a straight data breach.

2) Backup storage compromise

If someone breaks into your backup storage, encryption at rest can reduce the harm. They may be able to copy backup files, but they should not be able to read them without the key.

This is why encryption at rest exists in most serious platforms. It is a baseline control, not an advanced extra.

3) Network interception during backup

If your backups travel over the internet, encryption in transit (typically via TLS) stops casual interception. It makes it vastly harder for someone sitting on the network path to read what you are sending.

4) Some regulatory and contractual outcomes

For privacy rules and customer contracts, strong encryption can change the outcome of an incident. If data is encrypted and the key is not exposed, the impact can be lower than if data is exposed in readable form.

That said, losing access to data can still count as a breach, even if no one else can read it. If ransomware encrypts your live data and you lose timely access, that is still a real incident that may require action.

Where backup encryption does not protect you

1) Ransomware that can reach the backup system

If ransomware runs on a machine that has access to the backup system, encryption does not stop it deleting backups, overwriting versions, or encrypting what it can reach.

Encryption keeps data unreadable to someone who steals storage. It does not stop an attacker using your permissions to destroy the backups.

This is why ransomware-resistant backups focus on controls like immutability (write-once for a retention period), isolated access, and blocking deletion. Encryption is still useful, but it is not the deciding factor.

2) Credential compromise and admin takeover

If an attacker steals the credentials for your backup console or cloud account, encryption rarely helps. Most systems decrypt backups as part of normal restore operations, so the platform must have some way to access keys.

Once an attacker is “inside” as an authenticated admin, the problem is not secrecy. The problem is control.

3) “We forgot the key” recovery failures

This is the brutal trade-off: encryption can protect you from outsiders, but it can also lock you out if you mishandle the key.

If your backup encryption password is stored in the wrong place (for example, in someone’s personal notes, or in the same system that got compromised), you can end up unable to restore at the exact moment you need it.

Encryption without a key management plan is a self-inflicted outage waiting to happen.

4) Silent backup failures and restore surprises

Encrypted backups can still be incomplete, corrupted, or “successful” but not restorable. Encryption does not validate that the backup contains what you think it contains, or that the restore path works.

That’s a separate discipline: verification and test restores.

5) The wrong threat model

If your real risk is accidental deletion, sync mistakes, or “someone tidied the wrong folder”, your biggest need is version history and fast restore. Encryption does not give you better versions, better retention, or better restore speed. It just scrambles the data.

Advanced considerations small businesses usually miss

Who holds the keys: provider-managed vs customer-controlled

Not all “encrypted backups” are equal. The question that matters is: who can access the keys?

• Provider-managed keys: easier operationally, but you are trusting the provider’s security and internal controls.
• Customer-controlled keys (source-side encryption): stronger confidentiality, but you own the risk of key loss and recovery planning.

Neither is always “right”. For small businesses, the best option is usually the one you can operate safely.

Key storage and blast radius

If the encryption key is stored in the same admin account that can delete backups, you haven’t separated risks. You’ve just added complexity.

A better mental model is: keep the restore path and the key path as separate as possible. If one control fails, the other should still stand.

Encryption is not immutability

Immutability means a backup cannot be altered or deleted until retention expires, even by an administrator. Encryption does not provide that. You can have encrypted backups that are still fully deletable.

If you care about ransomware recovery, you need to ask about both. “Encrypted” is not the same as “undeletable”.

What to check if you are a small business buying backup

If you want a practical way to judge whether encryption is helping you or just sounding reassuring, use this checklist:

• Is encryption enabled for both in-transit and at-rest backup data?
• Is the encryption key customer-controlled, provider-managed, or optional?
• Where is the key stored, and who can access it?
• What happens if the key is lost? (be honest)
• Can an admin delete or modify backups? If yes, what stops ransomware doing the same?
• Is there immutability or a deletion lock?
• Do you run test restores? (not just “the job says successful”)

If you would rather get your Microsoft 365 foundations right first, start with the free Starter Kit at simplebusinessit.com/starter-kit/. It helps you avoid the common setup mistakes that create avoidable security and recovery risk.

Related reading on SimpleBusinessIT.com:

• Why “email working” doesn’t mean your business is actually secure
• Microsoft 365 Setup Guide overview
• Pricing (what the guide tiers include)

Summary and key takeaways

• Backup encryption is mainly about confidentiality. It protects you if backup storage is stolen or copied.
• Encryption does not stop backups being deleted, overwritten, or made unusable by ransomware.
• Key management is the real risk. If you lose the key, you can lose the restore.
• For ransomware recovery, immutability and access control matter as much as encryption.
• The only way to know a backup is useful is to test restores.

FAQ

Is encryption “at rest” enough on its own?

No. Encryption at rest protects stored backup data, but you also want encryption in transit for data moving over networks, plus sensible access controls.

Does encryption stop ransomware?

No. Ransomware is usually an access and control problem. If attackers can reach your backups or your backup console, they can delete or damage backups even if they are encrypted.

Should we always use customer-controlled keys?

Only if you can manage them safely. Customer-controlled keys can improve confidentiality, but they also increase the risk of self-lockout if the key is lost or mishandled.

If our data is encrypted, do we avoid GDPR problems?

Not automatically. Encryption can reduce the risk of exposure, but if you lose access to personal data (for example due to ransomware), that can still be a security incident that needs proper handling.

Where should we store the backup encryption key?

Store it somewhere protected, documented, and accessible during an emergency. The worst place is “in someone’s head”. The other bad place is inside the same account that an attacker could compromise during the incident.

Is “encrypted backup” the same as “immutable backup”?

No. Encrypted means unreadable without a key. Immutable means it cannot be altered or deleted for a set time. You can have one without the other.

What’s the simplest way to reduce backup-related risk?

Make restores boring. Keep encryption enabled, separate admin access, and run regular test restores so you know you can get data back when you are under pressure.