Immutable Backup in the Cloud: Object Lock, WORM Storage, and Protection Against Admin Deletion

A backup is only useful if it can be restored after an incident. If a backup can be deleted with the same permissions used to manage the production environment, it does not protect against a serious attack. In a ransomware incident, attackers often look not only for databases and files, but also for recovery points.

Historically, this problem was often solved through physical separation: companies wrote backups to tape, placed them in a safe, sent them to an off-site storage facility, and destroyed them only after the required retention period had passed. This model worked, but it was mostly associated with larger organizations because it required equipment, procedures, storage logistics, and regular handling. Cloud immutability brings a similar idea to a much wider range of businesses: protected copies can now be created without tape libraries, dedicated vaults, or complex physical storage processes. 

Immutable Backup solves this problem through immutability. A copy is written to storage with a policy that prevents the object from being deleted or overwritten before the defined retention period expires. This is usually implemented through Object Lock, WORM storage, locked retention, or similar mechanisms provided by a cloud provider.

However, immutable backup is not a single switch in the settings. Protection only works as an architecture where several elements are designed in advance:

• A separate cloud account or project for backups;
• WORM/Object Lock for protected objects;
• A retention period that cannot be shortened with ordinary permissions;
• Separation of roles between the backup admin, cloud administrator, and security team;
• Auditing of deletion attempts, retention policy changes, and legal hold removal;
• Regular recovery testing in an isolated test environment.

The main question of this article is: what exactly prevents the backup from being deleted before its retention period expires? If the answer is just “we have copies in another bucket,” the protection is weak. If deletion is blocked at the storage layer, permissions are separated, changes are audited, and recovery is tested regularly, the system starts to look like a real immutable backup architecture.

Why a Regular Backup Is No Longer Enough

Imagine a B2B service for accounting and document management. It stores customer databases, contracts, invoices, completion certificates, exports, activity logs, and access settings. As long as everything works, backups look like a technical routine: the schedule is configured, copies are created, and storage space is being used.

The problem begins during an attack. An attacker gains access to a server, an administrator account, or the backup system. They encrypt production data and then look for anything that would allow the company to roll back quickly: old copies, object versions, retention policies, and backup jobs. If all of this is managed with the same permissions as the production environment, the copies can be deleted or corrupted before recovery begins.

This is where a regular backup stops being enough. It answers the question “Do we have a copy?” but not the more important question: “Can it be deleted before its retention period expires?” To protect against ransomware, administrator compromise, and accidental deletion, immutability is needed — a technical restriction that prevents a copy from being deleted or overwritten before a defined date.

Immutable Backup is built around this idea. A copy must not simply be written to the cloud. It must be placed into an environment where the retention period is enforced by policy, dangerous permissions are limited, deletion attempts are logged, and recovery is tested in advance.

Next, we will look at how immutable backup differs from a regular backup, object versioning, and soft delete. After that, we will move on to the protection architecture: where copies should be stored, who can change retention policies, and how to verify that recovery actually works.

What Is Immutable Backup, and How Is It Different from a Regular Backup?

A regular backup answers one question: whether there is a copy of the data available for recovery. Immutable Backup adds a second, stricter question: can this copy be deleted or overwritten before the defined retention period expires?

Immutable Backup is a backup copy with an immutability policy. A retention period is defined for the object in advance, and until that period expires, the object cannot be overwritten or deleted using ordinary backup management permissions. A separate folder, another bucket, object versions, or a “trash bin” do not make a copy immutable on their own.

WORM stands for Write Once, Read Many: data is written once and read many times, but it cannot be changed or deleted before the specified date. In object storage, this model is often implemented through Object Lock — a mechanism that locks objects for the retention period.

Sometimes an isolated copy — an air-gapped copy — is added to this model. In the cloud, it is not always literally offline, but it should be separated from the primary infrastructure by network, account, or procedural barriers.

To avoid mixing different mechanisms, it is important to compare them by what they actually block in the event of an error, attack, or permission compromise:

The conclusion is straightforward: versioning and soft delete are useful, but they do not replace WORM. For a business, the difference is fundamental: “a copy exists” is not the same as “the copy cannot be deleted.” True immutability begins when the retention period is technically enforced and cannot be shortened using ordinary backup management permissions.

Immutable Backup Architecture in the Cloud

Immutable Backup should be designed as a separate environment, not as a folder with backups stored next to production data. The core idea is simple: even if the production environment or an administrator account is compromised, the attacker should not gain direct control over protected copies.

For a B2B accounting and document management service, this is especially important. If an attacker encrypts production databases, contracts, and invoices, the company must still have a recovery point that cannot be deleted with the same permissions used to manage production data.

It is useful to think of this architecture as two connected layers. First, the copy must be written to protected storage with minimal permissions. Then, the company must control access, policy changes, and the ability to recover from those copies.

Basic Protection Chain

Production environment → backup software with minimum required permissions.

The backup system should collect data from the production environment, but it should not become a “super administrator” for the entire infrastructure. It needs permissions to create copies and read data for recovery, but it should not have the ability to disable immutability, shorten retention periods, or delete protected objects.

Backup software → separate cloud account or project for backups.

Copies should be stored separately from the production infrastructure. If production servers, databases, and backups all live in the same account, compromise of a privileged identity may expose everything at once: the data, storage settings, retention policies, and the recovery points themselves.

Separate account → bucket or container with Object Lock / WORM policy.

Backups should be written to storage where deletion and overwriting are blocked until the retention period expires. It is important to enable this protection before the first copies are written: objects that already exist do not always receive immutability retroactively.

WORM policy → retention policy.

The retention policy defines the storage period — for example, 30, 60, or 90 days for a certain type of backup. Until this period expires, the protected object cannot be deleted using ordinary permissions. This is the practical meaning of immutable backup: the copy does not merely exist; it is technically retained until a defined date.

At this stage, the copy is already better protected than a regular backup. But writing it to WORM storage still does not answer every question: who can change policies, who sees deletion attempts, who verifies recovery, and what happens if the backup admin is compromised. That is why the second layer of the architecture is control and verification. 

Control, Auditing, and Recovery

Retention policy → auditing and alerts.

If someone attempts to delete a protected object, change the retention period, remove a hold, or grant themselves dangerous permissions, the event should be logged and sent to a monitoring or security system. A blocked deletion attempt is not just a “failed operation.” It may be an indicator of an attack against the backup environment.

Auditing → access change control.

Permissions for backup storage must be separated. A production environment administrator should not manage WORM policies. A backup admin may run backup and recovery jobs, but should not be able to remove protection from objects. Changes to critical policies should be handled through an approved request and a separate role.

Protected storage → isolated recovery test environment.

A backup cannot be considered usable until it has been tested through recovery. A test environment is needed to restore a database or files outside the production environment, verify integrity and checksums, start the application, and confirm that dependencies are available.

In this architecture, each layer addresses a separate risk. Account separation limits the power of the production administrator. The WORM policy blocks object deletion and overwriting until the retention period expires. Auditing reveals bypass attempts. Test recovery proves that the copy is not just sitting in the cloud, but is actually suitable for a real rollback.

The key principle is that production environment administrators should not have direct control over backup storage. Immutable Backup only works when permissions, retention policies, and recovery are designed as a single system.

How Object Lock and WORM Policies Prevent Early Deletion

In the previous section, we covered the overall immutable backup architecture: a separate environment, separate roles, protected storage, auditing, and recovery testing. But this architecture still does not answer the main technical question: what exactly prevents a backup from being deleted before its retention period expires if someone tries to do it anyway?

This is where Object Lock and WORM policies come into the architecture. They are not there as a “nice checkbox” in the settings, but for a very practical effect: if a copy is written with immutability enabled, the cloud storage platform must reject any attempt to delete or overwrite it before the retention period expires.

How the Deletion Ban Works

The mechanics are straightforward. When the backup system writes an object to protected storage, a retention period is attached to it: either a specific date or a time window during which the object cannot be deleted or modified.

From that point on, the logic is enforced by the storage platform itself. If an administrator, script, or malicious program tries to delete this recovery point ahead of time, the platform should not merely “warn” the user — it should reject the operation. This is the key difference between immutable backup and regular backup: protection does not rely on the administrator’s good behavior, but on enforcement at the storage platform level.

For a B2B accounting and document management service, this means the following: even if an attacker reaches the production environment or compromises an account with broad permissions, the protected copy itself should remain unavailable for ordinary deletion until the retention period ends.

This raises the next important question: if object versioning or soft delete is already enabled in the storage system, is that enough? No — and this distinction is worth spelling out separately.

Why Versioning Does Not Replace WORM

Object versions are useful: they allow the system to roll back to a previous state and recover from some types of mistakes. But versioning by itself does not make a copy immutable. If an administrator or attacker has permission to clean up versions, they can delete both the current and previous versions of an object.

That is why immutable backup cannot be built on versioning or soft delete alone. These mechanisms help with accidental errors, but they do not provide a hard answer to the scenario: “What happens if someone deliberately tries to delete recovery points?”

A WORM policy exists for a different level of protection. It enforces the rule that an object is written once and must be retained until the specified date, even if someone wants to delete it earlier.

This is also where another common confusion appears: the retention period and legal hold are often treated as the same thing. In practice, they are different mechanisms.

Retention Period and Legal Hold: What Is the Difference?

A retention period follows a predefined rule: the object is retained until a specific date or for a specified period. Once that period ends, the copy can be deleted according to normal lifecycle and access control rules.

Legal hold works differently. It is not tied to a predefined end date. The object is retained until the hold is explicitly removed. This mechanism is useful when a copy must be preserved for the duration of an investigation, legal dispute, or internal review, and it is impossible to know in advance exactly when that requirement will end.

A simple way to distinguish them is:

• Retention period — “retain until this date”;
• Legal hold — “do not delete until explicitly allowed.”

For backup, this means that the retention period is usually used for regular protection policies, while legal hold is used for specific cases where a copy needs to be retained beyond the standard schedule.

Once this distinction is clear, it becomes easier to evaluate cloud platforms as well. What matters is not so much the feature name, but its actual behavior: where the retention period is enforced, whether it can be shortened, and who has the authority to affect the policy.

What to Check in a Cloud Platform Beyond the Feature Name

Object Lock is most often associated with AWS, but the underlying principle is broader. Different cloud platforms use different names, but the core idea is the same: the platform must enforce a retention period and prevent deletion until that period expires.

When choosing a service, it is more important to look beyond the marketing name and answer four practical questions:

1. At what level does the protection apply — bucket, container, object version, or the object itself?
2. How is retention configured — as a retention period, legal hold, or both?
3. Can the retention period be shortened or protection removed with ordinary permissions?
4. What happens during a real deletion attempt — a warning, a log entry, or a hard denial?

Below is a short comparison that can be used as a design reference:

The conclusion is simple: check the actual behavior, not the feature name. For the business, it matters less whether the service is called Object Lock, Immutable Storage, or Bucket Lock. What matters is whether the retention period is technically enforced, who can change it, and what happens if someone tries to delete a protected copy.

This is where the next practical problem becomes visible: even with a WORM policy in place, the architecture can still remain weak if roles and permissions are distributed incorrectly.

Protection Against Admin Deletion: Roles, Modes, and Limits

Object Lock and WORM policies cover an important part of the problem: they prevent a protected object from being deleted before its retention period expires. But immutability alone does not solve the issue of overly broad permissions.

The main risk is a situation where a single administrator can manage the production environment, change IAM permissions, shorten the retention period, remove a hold, and delete object versions. In this case, the entire protection model depends on one account. If that account is compromised, the attacker gains a path not only to production data, but also to the backup environment.

IAM is the cloud model for managing users, roles, and access permissions. For immutable backup, IAM should not be used as a formality, but as a mechanism for separating responsibilities.

Separate Roles So One Account Cannot Control Everything

In a reliable architecture, different roles are responsible for different actions. A production environment administrator should not have direct control over backup storage. A backup admin should not be able to remove WORM protection. Changes to critical policies should go through a separate control process.

The minimum separation logic looks like this:

• The production environment administrator manages servers, databases, and applications, but not backup retention policies;
  
• The backup admin runs backup jobs, configures schedules, and performs recovery, but does not delete protected objects or shorten retention periods;
  
• The storage administrator configures buckets, containers, policies, and auditing, but does not operate without oversight;
  
• The security team approves changes to critical policies, reviews event logs, and responds to attempts to bypass protection.

For a B2B accounting service, this is especially important. If the backup admin can both run backups, delete protected objects, and change retention periods, then compromise of that role can deprive the company of recovery points. The backup role should therefore be powerful enough to write copies and perform recovery, but not powerful enough to disable protection.

In practice, protection against administrative deletion usually combines several measures at once:

• A separate cloud account or project for backups;
• A ban on deleting protected object versions for the backup admin and service account;
• A ban on shortening the retention period after the policy has been applied;
• Separate roles for writing, recovery, storage configuration, and auditing;
• MFA for privileged operations;
• Logging of deletion attempts, retention policy changes, and legal hold removal;
• Alerts to monitoring or SIEM;
• WORM policy changes only through an approved request.

It is important not to reduce everything to MFA. Multi-factor authentication lowers the risk of a stolen password being used, but it does not remove a dangerous permission by itself. If a role has the right to delete protected versions or bypass a soft protection mode, MFA only makes the attack harder — it does not prohibit the action at the architectural level.

Examples of Retention Policies for Immutable Backup

A retention policy must be specific. It is not enough to write “store backups for 90 days”: different types of data require different retention periods, backup frequencies, and protection levels. A critical product database, corporate files, a financial system, and an investigation archive serve different purposes, so they should not live under one generic policy.

For a B2B accounting and document management service, this is especially visible. A database with customer transactions may require fast rollback after an attack. Documents and attachments may require longer retention. Investigation logs may need to be held until the review is complete. Configurations and secrets are needed to restore not only the data, but also the environment itself.

The following logic can be used as a reference:

This table does not define universal retention periods. It shows that the retention period should depend on data criticality, recovery requirements, and the threat model. If a product database can be encrypted by ransomware, a short retention period may not be enough: corruption is not always detected immediately. If copies of financial documents are needed for audit, the retention period is defined not only by IT logic, but also by internal or regulatory requirements.

Storage cost should also be reviewed separately. The longer the immutability period, the harder it is to quickly delete unnecessary data and the higher the risk of overpaying for a poorly chosen policy. Strict WORM should therefore be applied where deletion protection is truly needed, rather than turning every copy into a long-term archive.

The practical purpose of a retention policy is to answer three questions in advance: which data is critical for recovery, how many generations of copies must be retained, and who is allowed to change the retention period. The higher the risk of administrator or backup system compromise, the less reason there is to rely only on soft modes and manual agreements.

Ransomware Protection Scenarios

Immutable Backup does not stop ransomware in the production environment. Its role is different: to preserve usable recovery points when an attacker has already gained access to servers, accounts, or the backup system.

For a B2B accounting and document management service, this is critical. After an attack, the company needs to restore not just files, but also customer databases, contracts, invoices, completion certificates, activity logs, and access settings. That is why it is important to understand which scenarios immutable backup actually covers.

Production Data Is Encrypted, and Old Copies Are Targeted for Deletion

An attacker gains access to file servers or virtual machines, encrypts data, and then looks for backups. If the backups are stored in a regular bucket without a WORM policy, the attacker can delete old recovery points and leave the company without a usable rollback option.

With Immutable Backup, deletion of protected objects is rejected by the storage platform until the retention period expires. The team selects a recovery point from before the encryption started, restores it in an isolated environment, verifies integrity, and only then returns the data to production.

The Backup Admin Is Compromised

An attacker obtains the backup administrator’s account. They may stop new backup jobs, change schedules, or try to delete existing recovery points through the backup system interface.

If the backup admin does not have permissions to shorten the retention period, remove legal hold, or delete protected versions, previously written copies remain intact. The compromise may affect new recovery points created after the attack, but the existing WORM-protected set remains available.

Corrupted Data Gets into New Backups

Ransomware or another malicious process does not always act instantly. It may gradually encrypt some files, corrupt database records, or delete reference data. If this is not detected immediately, corrupted data will be included in new backups.

Immutability does not repair the contents of a backup. It only guarantees that previously written recovery points cannot be deleted before their retention period expires. That is why the retention period should cover not only incident response time, but also the possible dwell time of the attacker. The later an attack is detected, the more important it is to have multiple generations of protected copies.

The Attacker Tries to Change the Retention Policy

Sometimes an attacker does not delete objects directly. Instead, they try to shorten the retention period, disable Object Lock, remove a hold, or grant themselves permission to bypass the policy. This is a typical path when the attack goes through the cloud management plane.

Protection is built through strict roles, a ban on shortening an already applied policy, auditing, and alerts. Even if the operation is blocked, the event must be sent to monitoring: an attempt to change a retention policy is not an ordinary administrative mistake, but a possible indicator of an attack on the backup environment.

These scenarios show the key point: immutable backup does not replace antivirus, EDR, network segmentation, or access control. It serves as the last line of defense — so that after the production environment is compromised, the company still has a verified recovery point.

Checklist: How to Verify That a Backup Cannot Be Deleted Early

After configuring Immutable Backup, protection should be verified through practical tests, not just by reading the service description. It is important to confirm that the object is actually retained until the required date, dangerous permissions have not been granted to unnecessary roles, and recovery works beyond the architecture diagram.

Immutability and Retention Period

This check answers the main question: does the storage platform block deletion by itself, without relying on the administrator’s caution? If a test object can be deleted with a regular role or the retention period is not visible, immutability is only partially configured.

Permissions, Auditing, and Recovery

If even one of these checks fails, the backup may be only partially immutable. The most dangerous areas are the ability to shorten the retention period, bypass Governance mode, remove legal hold, and the absence of recovery testing. These are the paths through which administrative deletion before the retention period usually becomes possible.

Conclusion

Immutable backup is not just a bucket with Object Lock enabled or a separate bucket with backup copies. It is an architecture in which a backup cannot be deleted before its retention period expires using ordinary administrative permissions, and attempts to bypass protection are logged and reviewed.

Reliable protection is built from several elements: WORM policies, a separate backup environment, role separation, restrictions on dangerous permissions, auditing, alerts, and regular recovery testing in an isolated environment.

The main criterion is simple: if the backup admin, cloud administrator, or a compromised account cannot shorten the retention period, remove a hold, or delete a protected copy, the architecture is actually working.

FAQ

Does Immutable Backup fully protect against ransomware?

No. It does not prevent production data from being encrypted, but it helps preserve recovery points that cannot be deleted or overwritten before the retention period expires. It is also important to verify that already corrupted data has not been included in the backup.

How is Object Lock different from regular versioning?

Versioning stores multiple versions of an object, but those versions can still be deleted if the required permissions exist. Object Lock adds a restriction that prevents a version from being deleted or overwritten until the defined retention period expires.

Can an administrator delete an immutable backup?

It depends on the mode and permissions. In softer modes, an administrator with special privileges may be able to bypass the policy. In strict WORM modes, deletion before the retention period expires is blocked at the storage level, but the account, roles, and policies still need to be protected.

How should the retention period for immutable copies be chosen?

Daily copies are commonly protected for 14–30 days, while weekly and monthly recovery points may be retained for 90–180 days. Critical systems may require 180 days to 1 year or longer. For archival or legal scenarios, retention may last several years, or legal hold may be used.

What must be checked after enabling immutability?

You need to verify that immutability is enabled before copies are written, the retention period is actually applied to objects, it cannot be shortened with ordinary permissions, auditing and alerts are enabled, and recovery is regularly tested in an isolated environment.

Sources

1. AWS Documentation — Amazon S3 Object Lock

2. Microsoft Learn — Immutable storage for Azure Blob Storage

3. Google Cloud Documentation — Bucket Lock

4. CISA — #StopRansomware Guide