Immutable backup: the copy ransomware should not be able to delete
During a ransomware attack, criminals do not focus only on encrypting files and disrupting systems. In many incidents, they also attempt to locate, modify, or delete the organization’s backups.
The reason is straightforward: if the recovery copies are destroyed, the organization loses its main path to restoring data and resuming operations without depending on the attackers.
This is where immutable backup becomes an important layer of protection. It is designed to prevent a backup copy from being changed or deleted for a defined period, even when someone attempts to remove it using administrative credentials.
A backup protects the business only when it remains available, intact, and recoverable after the incident.
What is an immutable backup?
An immutable backup is a recovery copy protected against modification or deletion during a predefined retention period.
While immutability is active, the protected data should not be overwritten, changed, or removed by users, applications, administrative processes, or malicious code.
This protection can be implemented through technologies such as:
- Object lock in cloud storage.
- Protected retention policies.
- WORM storage, where data can be written but not modified.
- Repositories with protected deletion controls.
- Backup environments isolated from production credentials.
The goal is not to make the data unusable. The purpose is to preserve a trustworthy recovery version even when the primary environment has been compromised.
Why does ransomware target backups?
The attacker’s leverage is reduced when the victim can restore systems independently.
For that reason, threat actors may try to compromise the recovery infrastructure before disrupting production. Their actions may include:
- Discovering backup servers and repositories.
- Stealing administrative credentials.
- Disabling protection jobs.
- Reducing retention periods.
- Deleting snapshots and recovery points.
- Encrypting backup files accessible over the network.
- Disrupting services required for recovery.
If backup systems rely on the same credentials, administrative domain, or production environment, an attacker with elevated privileges may reach both the original data and its recovery copies.
Immutability is intended to break this chain. Even if the attacker gains access to part of the infrastructure, selected copies remain locked against modification and deletion until the configured retention period expires.
Immutability is not the same as an offline backup
Immutable backup, offline backup, and isolated recovery copies are related concepts, but they are not identical.
Immutable backup
The copy is protected against modification or deletion for a defined period. It may remain connected and available for authorized read and recovery operations.
Offline backup
The copy remains disconnected from the operational environment for part or all of the time, reducing the likelihood that ransomware or a compromised account can reach it.
Isolated copy
The recovery environment has logical, administrative, or physical separation from production, with independent accounts, credentials, and controls.
A stronger resilience strategy can combine all three approaches. For example, an organization may keep immutable cloud backups, separate administrative credentials, and an additional isolated recovery copy.
Does immutable backup eliminate ransomware risk?
No. No single technology completely eliminates ransomware risk.
Immutability protects recovery copies against certain forms of alteration and deletion, but it does not necessarily prevent:
- Data theft before encryption.
- User credential compromise.
- Server and application downtime.
- Backups containing data that was already corrupted or compromised.
- Incorrect retention configuration.
- A lack of infrastructure or resources required to restore operations.
Immutable backup must therefore be part of a broader strategy that includes prevention, detection, access control, monitoring, incident response, and recovery testing.
Why the retention period matters
Immutability is generally enforced for a specific period. The length of that period directly affects the organization’s recovery options.
A retention window that is too short may not protect the business from a quiet or delayed attack. In some cases, compromise begins days or weeks before the incident is detected.
If all earlier recovery points have already expired when the attack is discovered, the organization may find that only contaminated or encrypted copies remain.
The retention policy should account for:
- The expected time required to detect an incident.
- Backup frequency.
- The number of historical versions required.
- Legal, contractual, and audit requirements.
- The criticality of each protected system.
- Storage costs.
- Business RTO and RPO requirements.
Retention should not be selected only according to the lowest storage cost. It must reflect how far back the organization may need to go to find a reliable version of its data.
The 3-2-1-1-0 approach
A practical reference for data protection is the 3-2-1-1-0 approach:
- 3: maintain at least three copies of the data.
- 2: use two different types of media or storage.
- 1: keep at least one copy outside the primary environment.
- 1: maintain one offline, isolated, or immutable copy.
- 0: aim for zero recovery errors after verification and testing.
This approach should not be treated as an automatic formula. It is a useful framework for evaluating whether every copy could be affected by the same incident.
Essential controls for protecting backups
Immutability is more effective when combined with strong administrative and operational controls.
Separate credentials
Accounts used to administer production should not automatically have permission to delete recovery copies.
Multi-factor authentication
Administrative access to backup and storage platforms should require an additional verification factor.
Least privilege
Every user, application, or automated agent should have only the permissions needed to perform its assigned function.
Protection against retention changes
An attacker should not be able to shorten the retention period and simply wait for protected copies to expire.
Alerts for critical actions
Deletion attempts, policy changes, repeated failures, and administrative modifications should generate alerts.
Continuous monitoring
Protection must be monitored. The organization needs visibility into job results, storage capacity, failures, and repository health.
Immutable backups must still be tested
Immutability protects the copy, but it does not prove that the organization can use it to restore operations.
Recovery tests should validate:
- The integrity of restored files.
- Database consistency.
- The availability of encryption keys.
- The permissions required to access the copies.
- The actual recovery time.
- Compliance with the defined RTO.
- The available recovery point compared with the RPO.
- The team’s procedures and responsibilities.
A copy may be correctly locked against deletion and still fail to support the expected recovery process. Recoverability must be tested and documented.
Common mistakes when implementing immutability
- Applying immutability to only part of the critical data.
- Using retention periods that are too short.
- Keeping every account under the same administrative control.
- Ignoring Microsoft 365, Google Workspace, and other SaaS environments.
- Failing to monitor backup jobs.
- Not testing recovery.
- Not documenting how recovery copies will be accessed during an emergency.
- Assuming immutability replaces cybersecurity, incident response, or business continuity.
Checklist: could ransomware delete your backups?
- Are recovery copies protected against deletion during retention?
- Are backup credentials separate from production credentials?
- Is multi-factor authentication required for administrative access?
- Is there an external, isolated, or immutable copy?
- Do retention policy changes generate alerts?
- Are backup jobs monitored every day?
- Are enough historical versions retained to address a quiet attack?
- Was the most recent recovery test successful?
- Was the actual recovery time measured?
- Are Microsoft 365, Google Workspace, and other SaaS platforms protected?
- Are recovery owners and responsibilities documented?
- Does the organization know which systems must be restored first?
If several answers are “no” or “we do not know,” an attacker may be able to compromise the recovery copies or prevent the organization from restoring operations.
How SafetyOnCloud can help
SafetyOnCloud helps organizations build a protection strategy that goes beyond simply creating copies.
The approach may include:
- Assessment of the current backup environment.
- Identification of critical data and systems.
- Review of backup frequency and retention.
- Cloud backup for servers, files, databases, and SaaS environments.
- Monitoring of backup operations.
- Protection against unauthorized modification and deletion.
- Separation between production and recovery.
- Support for defining RTO and RPO requirements.
- Recovery testing planning.
- Continuous improvement of recovery readiness.
Every environment has different risks, applications, data volumes, timelines, and compliance requirements. Immutability policies must be aligned with the organization’s operational reality.
Conclusion
Ransomware should not be able to destroy the organization’s last recovery option.
Immutable backup adds an important layer of protection by preventing selected copies from being changed or deleted during the retention period.
However, immutability does not replace monitoring, isolation, access control, appropriate retention, and recovery testing. Effective protection depends on combining these elements.
The essential question is not only whether the organization has a backup. It is whether a trustworthy copy will remain available and recoverable after an attack.