Can offsite backups be made immutable against ransomware?

Yes, but effective ransomware immutability depends on how the backup repository, retention policy and administrative controls are configured. An immutable copy is one whose contents and retention state cannot be changed through the normal backup management interface before its protection period ends. This is different from simply storing a second copy at another location: an offsite repository may still be vulnerable if an attacker can delete, encrypt or overwrite it.

Immutability is usually implemented in one of three ways:

• WORM storage: data is written once and then treated as read-only for a defined period. The storage system prevents alteration or deletion while the retention rule applies.
• Retention-locked object storage: each backup object has a preservation period enforced by the storage platform. Depending on the governance model, even an administrator may be unable to shorten that period.
• Offline or logically isolated media: a copy is disconnected from the production environment or made inaccessible except during controlled backup and recovery operations. This can provide an additional barrier when network-connected systems are compromised.

These approaches have different operational consequences. WORM and retention-locked storage can support automated backups while preventing routine deletion, but they continue consuming capacity until the retention period expires. Offline copies provide strong separation from live systems, although restoring from them may involve additional handling and coordination. Some organisations use more than one method so that a ransomware incident cannot affect every recovery copy through the same route.

The retention period must reflect the organisation’s risk, not just its backup schedule. Ransomware may remain undetected for some time before files are encrypted or systems are shut down. If immutable retention is shorter than the period between compromise and detection, older clean restore points may have expired. Retention planning should therefore consider the age of the oldest trustworthy copy likely to be needed, the frequency of backups, investigation requirements and the time required to identify the initial attack.

It is also important to distinguish immutable data from immutable backup metadata. Protecting the backup files alone may not protect the catalogue, configuration or recovery information needed to locate and restore them. A resilient design should protect or separately preserve the information that describes backup sets, retention rules and dependencies. Recovery credentials, encryption keys and configuration exports should be handled under separate controls so that losing the backup management server does not make the protected data unusable.

Administrative separation is a key part of the design. The account used by production systems to send backups should not have permission to delete repositories or alter retention rules. Backup administration should use separate credentials from domain administration, with multifactor authentication where supported and permissions limited to the tasks each role requires. Access to the storage account, backup console and recovery environment should be monitored, and changes to retention or repository settings should generate an auditable record.

Immutability does not make a backup automatically safe in every respect. It does not prevent an attacker from corrupting the source data before a backup is taken, nor does it guarantee that every restore point is clean. It also does not replace encryption, access control, malware detection or network segmentation. If encrypted data is backed up after the attack has begun, that copy may be faithfully preserved but of little use for recovery. Multiple restore points and a review process can help identify a clean version.

Testing is needed to confirm that the policy works as intended. A suitable test should verify that an authorised administrator cannot remove or alter a protected backup before expiry, that backup jobs can continue without granting excessive permissions, and that a restore can be completed using the available catalogue and credentials. Tests should include recovery to a clean environment rather than only checking that a backup job reports success. The results should record which restore point was used, what data was recovered and whether any manual steps were required.

Businesses should also define what happens when an immutable copy reaches the end of its retention period. Automatic expiry may be appropriate, but deletion should follow an approved policy and be visible to the responsible administrators. Legal, contractual or regulatory preservation requirements may require a longer hold for particular data. Retention rules should therefore be documented alongside data classification, rather than configured as an isolated technical setting.

A practical ransomware-resilient offsite backup design normally includes several independent layers: a suitable backup frequency, protected retention, a separate administrative boundary, secure handling of recovery information, monitoring of backup activity and regular restore testing. S2 Technology Group can help small and medium-sized organisations assess these controls as part of an offsite backup and wider managed IT strategy, ensuring that immutability is treated as one component of recoverability rather than as a substitute for the complete backup process.