Immutable Storage: A Practical Ransomware Defence

Ransomware is a data-destruction problem as much as an encryption problem. Once an attacker controls a workstation or identity account, they may delete shadow copies, alter recovery points, and corrupt the repositories administrators rely on. Conventional daily backups can be compromised during the same intrusion. Immutable storage changes the position by making selected copies read-only and undeletable for a defined retention period.

Immutable does not mean invulnerable, and it cannot replace tested recovery. It is one layer in a backup system designed around separate administration, protected credentials and regular restore drills. The aim is to preserve a clean version of critical data even when the production environment and some backup controls are under hostile control. That distinction helps teams judge ransomware readiness by recoverability rather than by the reassuring presence of a green backup dashboard.

Australian organisations add local complications: staff in Sydney, Melbourne and Brisbane often combine office systems with remote phones, Australian cloud regions may be required for certain records, and cyber incidents can coincide with NBN outages or severe weather. A durable strategy therefore needs immutable copies, an offline or disconnected recovery option, and recovery procedures that do not depend on uninterrupted connectivity or a single administrator being available.

Why immutable copies stop destructive recovery

Ransomware operators usually monetise stolen access quickly. Their first goal may be encryption, but deleting or corrupting backups can increase the pressure because restoration becomes slower, more expensive, or impossible. An attacker who can reach the backup server under the same account used for production can also erase volumes, shorten retention, remove snapshots, or terminate protection jobs before the organisation notices.

Protection jobs and snapshots are not automatically immutable. A snapshot may preserve one moment while an administrator can delete it, and cloud synchronisation can propagate a malicious deletion or overwrite to every connected copy. Backups should terminate in repositories with enforced retention, version history, and deletion protection. Where a vendor offers both governance and compliance retention, understand who can bypass each mode before relying on it.

A practical baseline is 3-2-1-1-0: three copies, two different storage types, one copy off-site, one copy offline or immutable, and zero errors in restore verification. For a small Australian business, that might mean a managed workstation service, immutable object storage, and a quarterly restore to clean hardware. For a larger organisation, it may combine enterprise backup software with an isolated appliance and an off-site vault.

Build a layered ransomware-resistant architecture

Start with the workloads that would stop operations if lost: identity services, finance data, customer records, shared files and virtual machines. Route each through backup software or an appliance that writes into a repository with true write-once, read-many controls. Cloud object lock, a WORM appliance and purpose-built immutable backup vaults all serve this role, but they provide different retention and recovery characteristics.

The control plane needs the same protection as the data. Give backup administration a dedicated identity with phishing-resistant multi-factor authentication, remove standing access to deletion functions, and require just-in-time approval for sensitive actions. Store recovery credentials in a password manager or privileged access vault, not in the same email account used for everyday work. If ransomware obtains a domain administrator token, it must not also inherit the right to erase the protected repository.

Maintain a second failure domain as well. An offline disk or tape set, stored securely away from the primary system, blocks attackers who reach every online service. Rotate it on a schedule and document how it is connected during a disaster. For the Australian market, check whether providers offer local support, contractual data residency, and service availability in the relevant Australian cloud region; “Australian hosted” alone does not guarantee rapid access during a local outage.

Endpoint coverage should feed the same protected destination rather than create another loose collection of files. Teams that still keep sensitive messages and photos on staff handsets can use this guide to secure Android backups to create a local copy, then replicate it to the protected repository. A laptop, shared drive or removable device should be inventoried, encrypted where appropriate, and included in the organisation’s retention policy so it cannot become an unmanaged shadow backup.

Set retention and recovery objectives

Set recovery point and recovery time objectives before choosing retention. A recovery point objective states how much data loss the business can tolerate; a recovery time objective states how quickly service must return. If a payroll run must be available within four hours, a daily snapshot created at night may fail the requirement even if it remains perfectly protected. Measure both against the workload and make the backup schedule and repository performance support the promised outcome.

Retention should cover the period needed to detect a compromise, investigate it and recreate missing records. Short retention can help the attacker by making clean history disappear, while indefinite retention without governance creates unnecessary cost. Compliance-mode locks offer stronger protection because deletion cannot be shortened before expiry, although they require careful deletion planning. Governance-mode locks may allow authorised bypass, which can be useful operationally but should be monitored and limited to named custodians.

Protect the entire restore chain, not just the final image. Immutable full points can still be useless if their incremental dependencies or the backup catalogue are deleted. Test restoring a complete set of files, an application database and a whole system, including required licence, key and configuration data. Immutability does not cleanse malware from a backup; combine it with endpoint detection, known-good application images and a process for identifying the last clean recovery point.

Test, monitor and meet Australian obligations

Monitor every change to retention, deletion, vault configuration and administrative access. Alerts should reach more than one responsible person through a channel that is separate from the production domain. Record successful restores as well as failures, and schedule recurring tests on clean hardware or isolated virtual networks. Quarterly exercises are a practical starting point for many organisations, while critical systems may need monthly validation. Document results using Australian date and time conventions so incident evidence remains unambiguous.

Organisations covered by the Privacy Act 1988 must also assess whether an incident is a notifiable data breach under the Notifiable Data Breaches scheme. Immutable backups support containment and evidence preservation, but they do not suspend notification duties. Keep the relevant logs, incident timeline and restoration records, then determine whether affected individuals and the Office of the Australian Information Commissioner must be notified. Legal obligations should shape retention rather than be applied after the backups have expired.

The Australian Signals Directorate’s Essential Eight provides a useful local control framework: backup and multi-factor authentication are core safeguards, while application control, patching and monitoring limit the path to encrypted data. Resilience also needs physical and communications contingencies. After a cyclone, flood or bushfire, internet access may fail and systems may be unavailable for days, so the disconnected copy must be reachable through a documented priority plan rather than stored in a time zone no one remembers checking.

Compare options and activate a resilient plan

Choose a pattern based on recovery speed, retention, operating skill and budget rather than on product claims alone. Evaluate backup utilities from their publisher, an authorised reseller or another verifiable source; check the licence, digital signature, update mechanism and support terms before installation. A polished download page is not evidence that a package is current or trustworthy. Trial the restore process with representative data, because vendor dashboards often measure jobs completed rather than data successfully recovered.

Most resilient arrangements combine two patterns. An immutable cloud repository supports fast, frequent recovery, while an offline vault provides separation from compromised credentials and cloud control planes. Smaller systems may begin with managed object storage and a tested local restore target; larger environments can add WORM appliances or tape. Whichever pattern is chosen, the vendor’s deletion rules, administrator permissions and retention modes must be validated under realistic conditions.

Storage pattern	Best suited to	Ransomware resistance	Main trade-off
Immutable cloud object storage	Cloud workloads needing frequent, rapid recovery	High when retention cannot be disabled	Cloud credentials, ongoing costs and regional availability
On-premises WORM appliance	Organisations with predictable local datasets and strict control	High when administration is isolated	Hardware, maintenance and additional off-site storage
Offline disk or tape vault	Long-term retention and air-gapped recovery	Very high because online deletion cannot reach it	Manual handling and slower restoration
Versioned synchronised storage	Short-term rollback and accidental changes	Limited because deletions may propagate	Low cost and simplicity can conceal weak controls

Run a restore drill before the next reporting cycle. Pick a business-critical service, rebuild it into an isolated environment, verify application functions and measure the elapsed time against its recovery objective. Record missing prerequisites, licence dependencies and the people who made decisions. If the drill exposes an unclear step, resolve it before the incident rather than during extended disruption, and repeat the exercise after material platform or staff changes.

Start now by inventorying every backup, assigning recovery objectives, moving at least one critical copy into enforced immutable retention, separating its administrator credentials, and scheduling a clean restore test. Make the result visible to operational and security owners. Require immutable storage, documented recovery steps and successful restore evidence in each backup service-level agreement, then repeat the process for every critical workload.