Backup encryption at rest and in transit is now standard across almost every backup product, and most UK businesses assume their backups are protected because the vendor’s website says so. Far fewer can answer the questions that actually determine whether encryption helps or harms them: who holds the encryption keys, where those keys are stored, who can use or delete them, and what happens to the backups if the keys are lost, the person who set them up leaves, or an attacker gets to the keys first.
Those questions matter because encryption cuts both ways. It protects backup data from anyone who steals the storage, intercepts a transfer or gains access to the provider’s systems. But encrypted data without its key is permanently unreadable, including by you. We regularly see businesses whose recovery plans depend on a passphrase stored in one person’s head, a key held in the same cloud tenant an attacker has just compromised, or a key vault that nobody has permission to access anymore. In each case the backups exist, are encrypted perfectly, and are useless.
This guide starts with the real risk of losing your own backups through key mismanagement, then covers encryption at rest versus in transit, provider-managed versus customer-managed keys, the operational discipline key management actually requires, and how encryption interacts with ransomware recovery and immutability. It is written for IT managers, business owners and anyone responsible for making sure backups can actually be restored when they are needed.
What backup encryption actually protects
Encryption transforms backup data so that it can only be read with the correct key. In backup systems it typically appears in two places.
- Encryption in transit protects backup data as it moves from your servers, devices or cloud services to the backup destination, usually using TLS or an equivalent encrypted channel. It defends against interception on the network.
- Encryption at rest protects backup data while it is stored, on disk, tape, object storage or the provider’s platform, typically using strong symmetric encryption such as AES with 256-bit keys. It defends against someone who obtains the storage itself, whether a stolen disk, a misconfigured storage bucket or unauthorised access to the provider’s infrastructure.
What encryption does not do is equally important. It does not stop an attacker who has valid access to your backup system from deleting backups, changing retention or restoring data to somewhere they control. It does not protect backups from being encrypted again by ransomware if the attacker can write to them. And it provides no protection at all if the keys are stored alongside the data or are accessible to the same compromised accounts. Encryption is one layer; access control, immutability and key separation are others.
For each backup system, write down the answers to three questions: who holds the encryption key, where is it stored, and how would we get it if the person or system that normally holds it were unavailable? If any answer is “we are not sure”, that is the most important thing to fix in your backup strategy, ahead of any new product or feature.
The real risk: locking yourself out of your own backups
Discussions of backup encryption usually focus on keeping attackers out. In practice, the more common failure we see is businesses locking themselves out. The scenarios are depressingly consistent.
The lost passphrase
Many backup products let you set an encryption passphrase that the vendor never sees, which is excellent for privacy. If that passphrase is lost, the vendor cannot help, by design. When the IT manager who set it up years ago has left, and nobody wrote it down securely, the backups cannot be decrypted.
The key in the compromised environment
Backups encrypted with keys stored in the same cloud tenant, domain or management system as the production environment can become unrecoverable in a serious incident. If an attacker takes control of that environment, they may delete or disable the keys, or the business may be unable to access the key store during recovery.
The key nobody can reach
Customer-managed keys in a cloud key vault give strong control, but only to those with permission to use them. After staff changes, permissions can end up with accounts that no longer exist, or with nobody at all.
The accidentally deleted or rotated key
Deleting an old key during a tidy-up, or rotating keys without keeping older versions available for older backups, can render historic backups unreadable. This often goes unnoticed until someone tries to restore from an older point.
The key tied to a vendor you are leaving
When switching backup providers, backups encrypted with provider-held keys may only be readable through that provider’s service. If the contract ends before data is migrated or retained elsewhere, access may be lost.
Each of these is preventable with straightforward discipline. None is prevented by stronger encryption.
Scoring three key custody models
Who holds the keys is the central decision in backup encryption. The score grid compares three common models. A high badge means strong performance on that dimension, except for the last row, where high means high risk of self-inflicted lockout.
The grid shows the central trade-off. The more control you take over keys, the more protection you gain from the provider and from others, and the more responsibility you take on for never losing them. Provider-managed keys are simplest and hardest to lose, but give you little control. A customer-held passphrase gives the most control and privacy, and carries the highest risk if key management is weak. Customer-managed keys in a cloud key service sit between the two, with risks that depend on how the key service itself is secured and administered.
Backup encryption in UK businesses — the numbers
The figures below are indicative, drawn from backup and recovery reviews we carry out for UK businesses. They are not a formal survey.
The contrast between the first two figures summarises the problem. Encryption is almost universal; understanding of the keys is not. The last figure shows why the gap often goes unnoticed: restore tests usually happen on the normal backup console, where keys are available automatically. Few businesses test the scenario where the console, the key holder or the key store is unavailable, which is exactly the scenario a serious incident creates.
“The vendor says it is encrypted” versus known keys and tested recovery
The comparison shows the difference between assuming encryption is handled and managing it deliberately.
“The vendor says it is encrypted”
Encryption enabled, keys not understood
Known keys and tested recovery
Encryption managed as part of recovery planning
The right-hand column does not require a different product. It requires decisions, documentation and a test. Most businesses can move from left to right in a few days of focused work.
Key-related recovery problems we find
The chart shows how often each key-related problem appears in the backup reviews we carry out. Many businesses have more than one, so figures add up to more than 100%.
Most of these are not technical failures. They are gaps in documentation, access and separation. The second item is particularly significant for ransomware recovery: keys stored where an attacker who compromises production can reach them undermine the whole point of having backups. Our earlier guide to backup encryption and data security introduces encryption types; this guide focuses on keys and recovery.
Encryption at rest versus in transit
Both forms of encryption are needed, and they protect against different things. Checking each separately avoids gaps.
Backup data in transit
When backups travel from your systems to a backup server, to the cloud or between sites, they cross networks where they could in principle be intercepted. Modern backup products and cloud services encrypt this traffic, typically with TLS. The points to check are that encryption is enforced rather than optional, that older, weaker protocol versions are disabled, that agents verify they are talking to the genuine backup destination, and that replication between backup sites or regions is encrypted as well. Traffic within your own network, such as from servers to a local backup appliance, deserves the same treatment, since attackers inside the network are a realistic threat.
Backup data at rest
Encryption at rest protects stored backups. It may be applied by the backup software before data leaves your environment, by the storage platform or cloud service when data arrives, or both. The difference matters. Encryption applied by your backup software before upload means the storage provider only ever holds encrypted data. Encryption applied by the storage platform protects against theft of disks or unauthorised physical access, but the platform can decrypt the data when it is accessed through normal channels.
End-to-end encryption
Some backup services encrypt data on your systems with keys the provider never sees, so it remains encrypted in transit, at rest and within the provider’s systems, and only you can decrypt it. This offers the strongest privacy, and it places the full responsibility for key safety on you.
Don’t forget local and removable copies
Local backup appliances, external drives, tapes and copies taken for migrations or offsite storage should be encrypted too. A lost unencrypted backup drive is one of the more common causes of reportable data breaches, and one of the most avoidable.
What to check in your backup settings
Encryption options are usually found in a backup product’s job, repository or storage settings. Whatever the product, the same checks apply.
- Is encryption enabled for every job and repository? Some products encrypt by default; others require it to be switched on per job or destination, and older jobs may predate the setting.
- Where does encryption happen? On the source before transfer, on the backup server, or only at the storage layer.
- Which key or passphrase protects each job? Different jobs may use different passphrases set at different times by different people.
- Is transport encryption enforced? Including between backup servers, proxies and repositories, and for replication.
- Are copies to tape, removable media or secondary sites encrypted? Copy jobs sometimes have separate settings.
- Is there a key recovery option? Some enterprise backup products offer organisation-level recovery keys that can decrypt backups if a job passphrase is lost; if available, decide whether to use it and protect it accordingly.
- Who can change encryption settings? Restrict this to a small group, and log changes.
Recording the answers for each system in one place often reveals inconsistencies, such as one old job still running unencrypted, or several passphrases nobody can now account for.
Provider-managed versus customer-managed keys
The choice of key custody model is a trade-off between simplicity and control. Each model suits different organisations.
Provider-managed keys
The backup or cloud provider generates, stores and manages the keys. Encryption happens automatically, and you never handle keys directly. This is simple, very hard to lose and suitable for many SMEs whose main concern is protection against theft of storage. The limitation is that the provider can, in principle, decrypt the data, and you cannot independently revoke its access. Your recovery also depends on the provider’s systems and your account with them.
Customer-managed keys in a cloud key service
You create and control keys in a key management service such as Azure Key Vault or AWS Key Management Service, and grant the backup service permission to use them. You can see when keys are used, rotate them, and revoke access, which renders the data unreadable to the service. This gives significantly more control and suits organisations with regulatory, contractual or risk-driven requirements. It also introduces a dependency: if the key service is unavailable, misconfigured or the key is deleted, backups become inaccessible.
Customer-held passphrases and keys
You hold the key or passphrase yourself, outside the provider’s systems, and the provider never has access. This gives maximum privacy and independence. It also gives maximum responsibility: if the key is lost, the data is gone, and nobody can help.
Choosing
For many SMEs, provider-managed keys combined with strong access control, immutability and offsite copies provide sound protection with little risk of lockout. Customer-managed or customer-held keys make sense where there are specific requirements, such as regulated data, contractual obligations or a policy that the provider must not be able to read backups, and where the business is prepared to manage keys with appropriate discipline. Choosing customer-managed keys without that discipline can increase risk rather than reduce it.
How often customer-managed keys are protected from deletion
Cloud key services offer protections against accidental or malicious key deletion, such as soft delete, purge protection and mandatory waiting periods before a key is destroyed. Across the customer-managed key deployments for backups that we review, the proportion without these protections enabled is significant.
The figure is indicative rather than a formal survey. Without deletion protection, a single administrator error or a compromised administrator account could delete the key that protects every backup, leaving the backups permanently unreadable. Enabling these protections is usually a configuration change taking minutes. In Azure Key Vault, for example, soft delete and purge protection can be enabled; in AWS KMS, key deletion is scheduled with a waiting period during which it can be cancelled. Check the current options in your platform and make sure they are on.
Putting key management in place
The timeline sets out a practical sequence for bringing backup encryption keys under control in an existing environment.
The first week often delivers the most important result: discovering that a critical backup depends on a single person or an account that no longer exists. Fixing that immediately removes the most serious risk before any wider changes are made.
Encryption key management maturity — where most UK businesses sit
Combining documentation of custody, separation from production, access by more than one person, deletion protection, escrow and tested key recovery gives an indication of key management maturity for backups. The gauge reflects a typical UK SME.
A score around thirty typically reflects encryption that is switched on but not managed: keys handled by default settings, passphrases known to one person, key stores administered by the same accounts as production and no test of recovering keys under pressure. The data is encrypted; the business’s ability to decrypt it in a crisis is untested.
The work in the timeline above usually moves a business into the seventies within a month. None of it requires new products; it requires deciding who holds keys, protecting them and testing that they can be recovered.
What key management costs compared with losing a key
The table compares indicative costs of key management approaches with the cost of losing access to encrypted backups. Figures are broad ranges for UK SMEs and depend on the number of systems and requirements.
| Approach | Indicative cost | What it provides | Main risk |
|---|---|---|---|
| Provider-managed keys | Usually included in the backup service | Simple encryption at rest with no key handling | Limited control; dependence on provider account |
| Customer-managed keys in a cloud key service | Small monthly charges per key and per operation, plus set-up time | Control, auditing and the ability to revoke access | Key deletion or lost permissions without proper protection |
| Customer-held passphrase with secure escrow | Staff time; a password manager or secure storage | Maximum privacy and independence from the provider | Loss of passphrase if escrow is neglected |
| Key management review and documentation | £500 to £3,000, or a few days in-house | Known custody, access, escrow and recovery steps | Becomes outdated without periodic review |
| Losing access to encrypted backups | Potentially the full cost of the data | Nothing | Permanent loss; regulatory and business consequences |
Every option above the last row is cheap relative to what it protects. The last row is not hypothetical: businesses do lose access to backups through key problems, and in those cases no amount of money recovers the data. Key management is one of the lowest-cost, highest-value controls in any backup strategy.
The operational discipline key management requires
Encryption key management for backups is not complicated, but it does require consistent habits. These are the ones that matter most.
At least two custodians
No backup key or passphrase should be accessible to only one person. Name at least two custodians, and make sure their access does not depend on the same device or account. For customer-managed keys, that means at least two people with permission to administer and use keys, through separate, strongly protected accounts.
Secure escrow
Passphrases and key recovery material should be stored securely in at least one place independent of the systems they protect: a business password manager with emergency access configured, a sealed record in a safe, or a split arrangement where two people each hold part. The escrow copy should be reachable even if your main IT systems are down.
Separation from production
Keys protecting backups should not be administered by the same accounts, or stored in the same environment, as the production systems those backups protect. If an attacker compromises a production administrator account, they should not automatically gain control of backup keys.
Deletion protection
Enable every available protection against key deletion, including soft delete, purge protection and waiting periods, and restrict who can schedule key deletion.
Rotation with retention
Rotating keys periodically is good practice, but older backups remain encrypted with older key versions. Make sure older versions are retained for as long as the backups that need them. Many key services handle this automatically; manual processes need care.
Logging and review
Cloud key services log key usage and administrative changes. Review these logs, and alert on unusual events such as key deletion requests, permission changes or access from unexpected sources.
Documentation in the recovery plan
The recovery plan should state, for each backup system, where its key is, who the custodians are and how to recover it. Store the plan where it can be reached during an incident, not only on the systems that might be unavailable.
Staff changes
Review key access whenever someone with key responsibilities joins, leaves or changes role. Leavers are the most common cause of keys becoming inaccessible.
Designing break-glass access properly
Break-glass access is the emergency route to keys and backups when normal access is unavailable: the usual administrator is absent, the identity system is compromised, or the main management tools are down. It is the part of key management most often missing and most often needed.
A sound break-glass arrangement has a few features. It relies on credentials or key material that are stored separately from everyday systems, such as a sealed record in a safe or a password manager vault with emergency access, rather than on the normal administrative accounts. It requires two people to activate, so that a single compromised or careless individual cannot use it alone. It is documented in plain steps that someone under pressure can follow, stored where it can be reached in an outage. It is monitored, so any use triggers an alert and review. And it is tested, at least annually, by actually performing a restore using only the break-glass route.
For cloud key services, break-glass access often means one or two emergency administrator accounts, excluded from normal sign-in policies that might lock them out during an incident, protected by strong authentication methods stored securely, and used only in emergencies. Check your platform’s guidance on emergency access accounts and configure them deliberately.
The test is simple: if every person who normally manages backups were unavailable tomorrow, and the main network were down, could two named people in the business restore critical data using only what is in the break-glass pack? If not, the arrangement needs work.
Key management practices in place
The progress bars show how often each practice is in place across the UK businesses whose backups we review. Figures are indicative.
Backup key management practices in place
Encryption itself is close to universal. Everything that ensures the business can still decrypt its backups in a crisis — documentation, multiple custodians, escrow, separation, reviews and tested recovery — is in place in a minority of businesses. That gap is the subject of this guide, and it is cheap to close.
Encryption, ransomware recovery and immutability
Ransomware attacks increasingly target backups, because attackers know that recoverable backups weaken their position. Encryption plays a specific and limited role in defending against this.
What encryption does and does not do against ransomware
Encryption at rest stops attackers reading stolen backup data, which matters because many attacks now involve data theft as well as disruption. It does not stop an attacker with access to your backup system from deleting backups, shortening retention or encrypting backup files again with their own key. Protecting backups from those actions requires immutability and access separation.
Immutability
Immutable backups cannot be modified or deleted for a defined period, even by administrators. Combined with encryption, immutability ensures backups remain both confidential and intact. Our guide to immutable backups covers how immutability works and how to configure it.
Attackers can target keys too
An immutable backup is still useless if its encryption key is deleted or made inaccessible. A sophisticated attacker with control of a cloud tenant might try to delete or disable customer-managed keys, revoke the backup service’s permission to use them, or change key policies. Deletion protection, separation of key administration from production administration and monitoring of key events close this route.
Recovery when the environment is compromised
In a serious ransomware incident, the production environment, its identity system and its management tools may all be untrusted or unavailable. Recovery plans need to work in that situation: backup consoles reachable through separate credentials, keys retrievable through a break-glass procedure that does not depend on the compromised identity system, and documentation available offline. Test this scenario specifically; it is the one that matters.
Offsite and air-gapped copies
The familiar principle of keeping multiple copies, on different media, with at least one offsite and one offline or immutable, applies with encryption in mind: each copy needs its own key arrangements, and keys for an offline copy must be recoverable without the online environment. Our guide to the 3-2-1 backup rule covers copy strategy in more depth.
Encryption, deduplication and performance
Encryption has some practical side effects worth understanding when designing backups.
Deduplication and compression. Encrypted data looks random, so it cannot be compressed or deduplicated effectively after encryption. Well-designed backup products compress and deduplicate first and encrypt afterwards. If data is encrypted by another tool before the backup software sees it, storage efficiency can fall sharply and backup sizes grow. Check the order of operations when combining tools.
Performance. Modern processors handle encryption efficiently, and for most backup workloads the performance impact is small. Very large backups on older hardware may see some overhead; in practice network and storage speeds are usually the limiting factors.
Encrypted source data. Backing up data that is already encrypted, such as encrypted databases or files, is fine, but recovery then depends on both the backup key and the source encryption key. Make sure both are part of the recovery plan.
Encryption, compliance and data protection
This section is a general overview, not legal advice. Take advice on your specific obligations.
UK data protection law requires appropriate technical and organisational measures to protect personal data, and encryption is explicitly referred to as an example of such a measure. Backup data often contains large volumes of personal data, so encrypting backups is generally an expected control. Where encrypted backup media is lost or stolen and the key remains secure, the risk to individuals may be considerably lower, which can affect how a potential breach is assessed; the Information Commissioner’s Office provides guidance on this.
Frameworks such as Cyber Essentials, ISO 27001 and sector-specific requirements may also expect encryption and key management controls, and customers increasingly ask about them in security questionnaires. Being able to describe your key custody model, who holds keys and how recovery is tested gives credible answers. Where data must be destroyed at the end of its retention period, deleting the encryption key for a set of backups, sometimes called crypto-shredding, can render the data unreadable, provided no other copies of the key exist; confirm the approach with your advisers if you rely on it for compliance.
Questions to ask your backup provider about encryption
Whether you use a managed backup service or a cloud backup product, these questions establish what encryption actually means for your data.
- Is data encrypted in transit and at rest, and with what? Ask for specifics rather than assurances.
- Who holds the keys? Provider, you through a key service, or you directly?
- Can your staff decrypt our backups? Under what circumstances and with what controls and logging?
- Can we bring our own key? And what happens to access if we revoke it?
- What happens if we lose our passphrase or key? Is there any recovery option, and what are its security implications?
- How are keys protected from deletion and compromise? On your side and theirs.
- Are backups immutable, and does immutability cover key changes?
- How do we restore if our own environment and identity system are compromised?
- How would we read our backups after leaving your service?
Clear, specific answers indicate a provider that has thought about these issues. Vague answers suggest you should investigate further before relying on the service for critical data.
Common backup encryption mistakes
The mistakes below account for most of the key-related risks we find.
- Assuming encryption is handled. Without knowing who holds the keys, you cannot know whether recovery is possible.
- One person holding the passphrase. A single point of failure for every backup it protects.
- Passphrases in email or shared documents. Insecure, and often lost when accounts are deleted.
- Keys in the same environment as production. Compromise of production can mean loss of backups.
- No deletion protection on customer-managed keys. One mistake or compromised account can destroy access.
- Choosing customer-managed keys without the discipline to run them. More control can mean more risk.
- Deleting old key versions. Older backups become unreadable.
- Unencrypted removable copies. Lost drives and tapes remain a common breach cause.
- Encrypting before deduplication. Storage costs rise sharply.
- Testing restores only from the normal console. Key recovery under incident conditions goes untested.
With customer-held or end-to-end encryption, the provider cannot decrypt your backups or reset a lost passphrase, by design. That is the point of the model. Before choosing it, make sure the business has secure escrow, multiple custodians and a tested recovery procedure. Without them, the strongest encryption becomes the most certain way to lose your data.
The 12-point backup encryption checklist
The checklist covers the essentials for encrypting backups without locking yourself out.
- Inventory every backup and copy. Including local appliances, removable media and replicas.
- Confirm encryption in transit is enforced. Including replication between sites.
- Confirm encryption at rest for every copy. Including removable and offsite media.
- Document the key custody model. Provider-managed, customer-managed or customer-held, per system.
- Name at least two key custodians. With independent, strongly protected access.
- Escrow passphrases and recovery material securely. Reachable when main systems are down.
- Separate keys from production administration. Different accounts, ideally a different environment.
- Enable deletion protection. Soft delete, purge protection and waiting periods where available.
- Retain older key versions. For as long as backups encrypted with them are kept.
- Combine encryption with immutability. Confidential and unalterable.
- Review key access on staff changes. And review key usage logs periodically.
- Test key recovery under break-glass conditions. At least annually, without normal admin access.
A standard restore test from the backup console proves that data can be recovered when everything else is working. A key recovery test proves it can be recovered when it is not: the usual administrator unavailable, the identity system untrusted, the key retrieved from escrow. Our guide to backup restore testing covers building both into a regular testing programme.
Case study: the passphrase that left with the IT manager
A UK architectural practice with around 50 staff backed up its file server and project archive to a cloud backup service, using end-to-end encryption with a passphrase set by its IT manager four years earlier. The IT manager left on good terms, and a managed service provider took over IT support. Backups continued to run successfully, with daily success reports.
Eighteen months later, a storage failure on the file server required a full restore. The provider attempted to restore from the cloud backups and was asked for the encryption passphrase. Nobody had it. The handover documentation listed the backup service and the administrator login but not the passphrase. The former IT manager, contacted by phone, believed it had been recorded in a document on the file server, which was the system that had failed. The backup vendor confirmed it had no way to recover the data without the passphrase.
The practice was fortunate: a local backup appliance held a recent copy, encrypted with a key managed by the appliance itself, and most data was recovered from it, with some loss of recent work. Afterwards, the practice and its provider reviewed every backup system. They documented each key custody model, moved passphrases into a business password manager with emergency access for two named people and a sealed copy held offsite, enabled immutability on the cloud backups, separated backup administration from day-to-day IT accounts, and added an annual key recovery test in which a restore is performed using only escrowed material.
“The backups were running every night and reporting success. What we did not know was that nobody could actually open them. Now we test the passphrase as well as the restore, and two of us know exactly where to find it.” — Practice Director, UK architectural practice
The lesson is not that end-to-end encryption was the wrong choice. It is that the strongest encryption model requires the strongest key discipline, and successful backup reports say nothing about whether the keys can be found when they are needed.
Keys when you change backup provider
Changing backup provider raises an encryption question that is often missed: how will you read historic backups after the old service ends? With provider-managed keys, backups are typically only readable through the provider’s service, so ending the contract can end access to everything retained there. With customer-managed or customer-held keys, you may hold the key but still need the provider’s software or format to restore.
Plan this before switching. Options include keeping the old service running at a reduced level until retention periods expire, restoring and re-backing up data that must be kept, or exporting backups in a format you can read independently, with the keys needed to decrypt them. Check retention obligations, such as financial records or contractual commitments, so nothing that must be kept becomes unreadable. Our guide to backup vendor lock-in and exit strategy covers the wider exit plan.
Encryption for Microsoft 365 and SaaS backups
Backups of software-as-a-service data, such as Microsoft 365 mailboxes, OneDrive and SharePoint, or CRM platforms, are usually provided by specialist services that store copies in their own cloud. The same questions apply: is data encrypted in transit from the source service and at rest in the backup service, who holds the keys, can you bring your own key, and how would you restore if your account with the source service were compromised?
For these services, the account and identity used to administer backups matter as much as the encryption. If the backup service is administered using the same identity system as the source data, an attacker who compromises that identity may reach both. Separate administrative accounts with strong authentication, and a documented route to restore if the main identity system is unavailable, are part of making encrypted SaaS backups genuinely recoverable.
At a glance: backup encryption without the lockout
| Area | What good looks like | Why it matters |
|---|---|---|
| Encryption in transit | Enforced, modern protocols, including replication | Protects backups on the network |
| Encryption at rest | Every copy, including local and removable media | Protects stored backups from theft |
| Key custody | Model chosen and documented per system | Determines who can decrypt and who can lose access |
| Custodians | At least two, with independent access | No single point of failure |
| Escrow | Secure copy reachable when systems are down | Recovery when the usual route fails |
| Separation | Keys not administered by production admin accounts | Production compromise does not reach keys |
| Deletion protection | Soft delete, purge protection, waiting periods | Prevents accidental or malicious key loss |
| Rotation | Periodic, with older versions retained | Older backups stay readable |
| Immutability | Combined with encryption | Backups confidential and unalterable |
| Monitoring | Key events logged and alerted | Early warning of tampering |
| Staff changes | Key access reviewed every time | Leavers do not take access with them |
| Testing | Key recovery tested under break-glass conditions | Proves recovery works in a real incident |
| Provider exit | Plan for reading historic backups | Retention obligations still met |
How Cloudswitched approaches backup encryption
We treat encryption keys as part of recovery planning, not as a product setting. Every backup engagement includes a review of how each backup is encrypted in transit and at rest, who holds the keys, where they are stored, and how they would be recovered if the usual people or systems were unavailable.
We help you choose the right key custody model for each system — provider-managed where simplicity and low risk of lockout matter most, customer-managed or customer-held where requirements call for more control — and then put the discipline in place: multiple custodians, secure escrow, separation from production administration, deletion protection, rotation that retains older versions, and monitoring of key events. We combine encryption with immutability and offsite copies so backups are protected against both theft and tampering.
Finally, we test. Alongside regular restore tests, we run key recovery tests using break-glass procedures, so you know your backups can be decrypted in the scenario that matters most. No backup design removes every risk, but known keys and tested recovery turn encryption from a potential trap into the protection it is meant to be.
Do you know who holds your backup keys?
Talk to us about a backup encryption and key management review, immutable backups and tested recovery for your business.
Talk to a Cloud Backup SpecialistFrequently Asked Questions
Are my backups encrypted?
Most modern backup services encrypt data in transit and at rest, but settings vary and local or removable copies may not be covered. Check each backup system and copy specifically, and find out who holds the keys.
What is the difference between encryption at rest and in transit?
Encryption in transit protects backup data as it moves across networks. Encryption at rest protects it while stored. Both are needed, and they defend against different threats.
What are customer-managed keys?
Encryption keys you create and control in a key management service, granting the backup service permission to use them. They give you control, auditing and the ability to revoke access, and they require careful management.
Should we use customer-managed keys for backups?
Where there are specific regulatory, contractual or policy requirements and the business can manage keys with discipline, yes. Otherwise, provider-managed keys with strong access control and immutability may offer better overall protection with less risk of lockout.
What happens if we lose the encryption key?
The backups encrypted with that key become permanently unreadable. With customer-held or end-to-end encryption, the provider cannot help. This is why escrow, multiple custodians and tested key recovery are essential.
Does encryption protect backups from ransomware?
Partly. It stops attackers reading stolen backup data, but it does not stop them deleting or altering backups. Combine encryption with immutability, access separation and protected keys.
Can attackers delete our encryption keys?
If they compromise accounts with key administration rights and deletion protection is not enabled, potentially yes. Enable soft delete, purge protection or waiting periods, separate key administration from production accounts and monitor key events.
Where should backup keys be stored?
Separately from the production environment and its administrative accounts, with a secure escrow copy that can be reached if main systems are unavailable.
How often should backup keys be rotated?
Follow your policy and provider guidance, commonly annually or when staff with key access leave. Retain older key versions for as long as backups encrypted with them are kept.
Does encrypting backups affect deduplication?
Encrypted data cannot be deduplicated or compressed effectively, so backup software should deduplicate and compress before encrypting. Encrypting data with another tool first can increase storage use significantly.
Is backup encryption required by UK GDPR?
UK data protection law requires appropriate security measures and refers to encryption as an example. Encrypting backups containing personal data is generally expected. Take advice on your specific obligations.
How do we test that we can recover our keys?
Run a restore using only escrowed key material and break-glass access, without the usual administrator or console credentials, and confirm data can be decrypted. Repeat at least annually and after significant changes.
Related reading
More guidance for UK businesses from the Cloudswitched blog:
- Why Microsoft 365 native retention is not a backup
- Private connectivity to Azure and AWS: ExpressRoute and Direct Connect vs VPN
- Azure Kubernetes Service vs App Service: choosing the right compute platform
- Cyber Essentials scope: deciding what is in and out of your certification
- VoIP integrations: connecting your phone system to CRM and helpdesk
Encrypted backups you can actually restore
Cloudswitched designs backup encryption with known keys, protected custody and tested recovery, so your backups stay safe from attackers without locking you out.
Talk to a Cloud Backup Specialist
Cloudswitched
London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.
