A ransomware incident often becomes a recovery crisis for one simple reason: the attacker has not only encrypted live files, but also found and deleted the backups. So, are backups immutable? Some are, but many businesses assume they are when they are merely copied elsewhere. That distinction can determine whether an organisation is back up and running in hours or facing days of disruption.
Immutable backups are a valuable part of modern cyber resilience, particularly for businesses that rely on Microsoft 365, cloud platforms, line-of-business applications and shared files. They are not, however, a switch to tick and forget. Their value depends on how they are configured, protected and tested.
What immutable backups actually mean
An immutable backup is a backup that cannot be changed or deleted for a defined retention period. Once the backup has been written, the system applies a lock. Even an administrator with normal backup access should not be able to alter its contents or remove it before that period expires.
This is different from a standard backup stored in a separate location. A conventional copy may protect you from a failed server, accidental deletion or a local fire, but it can still be vulnerable if an attacker gains control of the backup platform, its storage account or privileged credentials.
Immutability is designed to break that chain. If criminals obtain administrator access and attempt to delete recovery points, the locked copies remain available until their retention date. That gives the business a known-good point from which to restore.
The technology behind this varies. It may involve object storage with a write-once, read-many policy, hardened backup repositories, or cloud retention controls. The commercial outcome is the same: a deliberate barrier between an incident and the destruction of your recovery options.
Are backups immutable by default?
Usually, no. Backups are not automatically immutable just because they are held in the cloud, managed by a backup product or replicated to another site. Cloud storage can be deleted if the right account has sufficient permissions. A backup system can also be compromised where the same credentials, network access and administration processes are used across production and backup environments.
This is why the question is not simply, “Do we have backups?” It is, “Can someone with compromised access change or delete every usable copy?” If the answer is yes, your backup strategy has a significant gap.
A sound approach normally follows the 3-2-1-1-0 principle. Keep at least three copies of data, on two different media types, with one copy held off site, one copy offline or immutable, and zero untested backup errors. It is a useful framework rather than a rigid rule. The right design depends on your systems, data volumes, recovery targets and regulatory obligations.
For example, a manufacturing business may need fast local recovery for operational files and a protected off-site immutable copy for worst-case events. A legal practice may place greater emphasis on long retention, access controls and the ability to prove that client records can be recovered accurately.
What immutability protects against
Immutable backups are particularly effective against ransomware operators who try to make payment appear to be the only route back to normal operations. They also reduce the damage caused by accidental or malicious deletion, failed synchronisation jobs and certain types of insider threat.
They do not stop an attack from happening. They do not prevent a user clicking a convincing phishing email, and they do not replace endpoint security, multi-factor authentication, patching or staff awareness. Think of them as the recovery layer of your security plan: the part that helps you regain control when other defences have been bypassed.
There is another limitation that businesses should understand. An immutable backup can faithfully preserve bad data. If ransomware has been present unnoticed for weeks, or a database has been corrupted over time, the newest restore point may already contain the problem. Retaining a sensible range of recovery points matters just as much as locking them.
The practical trade-offs for UK businesses
Immutability comes with costs and operational choices. Longer retention periods consume more storage. Protecting large datasets can affect backup windows and restoration times. Some systems need specialist configuration, especially where legacy servers, databases or bespoke applications are involved.
There can also be a trade-off between protection and flexibility. The point of an immutable retention period is that it cannot be shortened on a whim. That is reassuring during an attack, but it means retention policies must be planned carefully to avoid paying for unnecessary capacity or retaining data beyond what your business requires.
The answer is not to choose the longest possible retention period for everything. Identify what is business-critical, what can be recreated, and how quickly each service needs to return. Your finance system, design files, customer records and production data may each have different recovery priorities.
For many organisations, a tiered approach is more practical. Critical systems receive frequent backups, protected recovery points and priority restoration planning. Less critical data may have shorter retention or less frequent copies. This keeps the solution commercially sensible without leaving vital operations exposed.
How to make immutable backup protection useful
An immutable backup only helps if it is recoverable when needed. That starts with clear ownership. Someone in the business, supported by your IT provider where appropriate, should know which systems are included, where the protected copies are held, how long they are retained and who can authorise changes.
Separate administrative access is equally important. Avoid using the same highly privileged account for everyday IT administration and backup management. Apply multi-factor authentication, limit access to those who genuinely need it, and review permissions when staff or suppliers change.
Recovery testing is where confidence becomes evidence. A successful backup job confirms that data was copied. It does not confirm that the application will start, the files are complete, users can access what they need or the restore can be completed within an acceptable timeframe.
Test restores should reflect real business scenarios. Restoring a single file is useful, but it is not the same as recovering a server, a Microsoft 365 mailbox, a database or a key application after a cyber incident. Record the result, the time taken and any dependencies discovered. Those findings should feed into your disaster recovery plan.
It is also worth considering where recovery will take place. If your office, servers or internet connection are unavailable, can key staff work elsewhere? Can systems be restored to cloud infrastructure or replacement hardware? Backups preserve information; a recovery plan brings the business back into operation.
Questions to ask about your current backups
A straightforward review can expose assumptions before they become an incident. Ask whether your backup copies are genuinely locked for a defined period, whether an attacker using an administrator account could remove them, and whether all critical systems are included.
You should also establish the recovery point objective and recovery time objective for each important service. Put simply, how much data can you afford to lose, and how long can you afford to be without the system? A backup taken once each night may be suitable for some information, but unacceptable for a busy order-processing platform.
Finally, ask when each important system was last restored successfully. If the answer is unclear, treat that as an operational risk rather than a paperwork issue. Documentation, named responsibilities and tested procedures matter most when people are under pressure.
Immutability is part of resilience, not the whole answer
The strongest backup arrangements combine protected copies with sensible security controls and a rehearsed response. That includes patch management, monitored devices, secure identities, clear escalation routes and a plan for communicating with staff, customers and suppliers during disruption.
For organisations without an internal IT team, this can feel like a great deal to coordinate. A managed service provider can help assess business priorities, configure suitable backup and retention policies, monitor jobs, and carry out regular recovery tests. The aim should be clear reporting and practical assurance, not a collection of technical terms.
At Blowfish Technology, the focus is on making technology decisions support business continuity rather than adding complexity. The right backup design should be proportionate to your risk, your obligations and the real cost of downtime.
The most useful next step is not to wait for a renewal date or a security scare. Ask for evidence that your critical data can be restored, protected from deletion and returned to service within a timeframe your business can live with. That conversation turns backups from an IT task into a credible continuity plan.
The Blowfish Technology team. Managed IT, cloud services, software development and connectivity for North West businesses since 1999.