Immutable and Offline Backups: Keep One Copy Out of Reach

Published October 23, 2026 · Last reviewed October 23, 2026

An immutable backup cannot be changed or deleted until a retention period you set has passed, even by an administrator. An offline backup is physically or logically disconnected so ransomware cannot reach it. CISA advises keeping offline, encrypted backups of critical data and testing them, because many ransomware variants try to find and delete or encrypt accessible backups.

Why backups are targeted first

A victim with a working backup does not need the attacker’s decryption key. So intruders who have gained administrator access look for backup servers, backup consoles and network shares, and remove or encrypt them before they trigger the main attack. The CISA #StopRansomware guide states this directly and recommends maintaining offline, encrypted backups of critical data. The aim of this guide is a single copy that survives a fully compromised administrator account.

Your options, from simplest to most capable

Rotated offline disks. Two or more external drives used in turn: one connected for the backup, the other stored off-site. Low cost, manual, and entirely dependable if the discipline holds.
Cloud object storage with a retention lock. Major storage services offer a write-once mode, for example Amazon S3 Object Lock and Azure immutable blob storage, among others. Data written under a lock cannot be altered or deleted until the retention period ends.
Backup software with an immutable or hardened repository. Many backup products can write to storage in a way that blocks deletion from the console. Ask the vendor how the lock is enforced and who can override it.
Tape or other removable media where the volume of data justifies it.

Pick one that your team can operate when stressed. A simple rotation that is followed beats an elaborate design that is not.

Set it up

Action: Choose the immutable or offline target and put it under a separate account from your daily administration. In a cloud service, create the storage in a separate subscription or account, enable the lock feature following the provider’s documentation, and protect the account with multi-factor authentication. Menu names differ by provider and plan; consult the provider’s documentation for the exact steps.
Why it helps: The lock only helps if an attacker cannot simply close the account, switch the lock mode off or move the data elsewhere using the same stolen login.
Verification: Sign in to the storage with your usual administrator account. You should be unable to delete the account, shorten the lock or remove the data.
Fallback if delayed: Until a locked repository exists, use the rotated-disk method and keep the off-site disk unplugged.

Action: Set the retention period longer than you would take to notice an intrusion. A lock that expires in a week protects nothing if the attacker was inside for a month. Choose the period with the business owner and write it down.
Why it helps: Attackers can be present before they act. Backups taken during that time may already contain their tools, so you need older restore points to choose from.
Verification: Open the storage’s properties or backup console and read the retention date on a recent backup. Confirm it is later than today by at least the period you chose.
Fallback if delayed: Keep monthly disks for several months in addition to the weekly rotation.

Action: Use the strictest lock mode and understand the mode names. Some services offer a mode that privileged users can override and a stricter mode that nobody, including the account owner, can override before expiry. Use the stricter mode for the copy that matters most, once you have tested with a short period.
Why it helps: A lock that an administrator can lift protects against accidents and not against an attacker who holds administrator rights.
Verification: Write a test object with a short retention period, try to delete it with the highest-privilege account you have, and confirm the attempt is refused.
Fallback if delayed: If you cannot use the strict mode, require two people and a documented approval for any change to the lock.

Action: Keep the keys and the recovery instructions outside the systems being recovered. Store encryption keys, backup-console recovery codes and a printed restore procedure somewhere that survives the loss of every computer: a safe, or a separately held password vault.
Why it helps: Encrypted backups are useless without their keys, and a recovery procedure stored on the failed server cannot be read.
Verification: A person who did not set up the backups can find the keys and the procedure and say what each is for.
Fallback if delayed: Print one copy now and put it in a sealed envelope with the owner.

Common failure mode

Immutability is often switched on in a mode that a privileged account can reverse, or for a retention period shorter than the time an intruder might stay hidden. The second frequent error is protecting the backup data but leaving the backup server, its credentials or its encryption keys reachable from the same network and administrator login. An attacker then cannot delete the data but can still lock you out of it.

How it works

A retention lock works at the storage layer: the service records an expiry date for each object and refuses delete and overwrite requests until that date, whoever sends them. Offline copies rely on distance instead: a disk in a drawer cannot be reached by software running on your network.

Both achieve the same property: the last good copy stays out of reach of the credentials an attacker is most likely to steal. That is why the account that controls the lock must be separate from the one you use every day, and why the test is simply to try to delete something with your most powerful login.

Worked example

This is a hypothetical example with invented figures. A 60-person accounting practice backs up to a cloud repository managed by its IT provider. The owner asks the provider to demonstrate immutability: sign in as a senior administrator, upload a test file with a one-day lock, and attempt to delete it. The attempt fails, and the owner records the date and the screen.

Then the owner asks the harder question: can the provider’s own staff turn the lock off? The answer is yes, by a single administrator. The practice asks for two named approvers on any lock change and a retention period of several months. The conversation costs an hour and removes the weakest link.

Frequently asked questions

What is the difference between immutable and offline backups?

Immutable backups stay connected but cannot be altered or deleted until a retention date. Offline backups are disconnected from the network, such as a disk in a drawer. Both keep a copy out of an attacker's reach; offline relies on distance and immutable relies on the storage service enforcing a lock.

Does cloud backup protect me from ransomware automatically?

Only if the copy cannot be deleted or overwritten by the credentials an attacker can steal. A cloud backup with no lock, managed by your main administrator account, is still reachable.

How long should the retention lock last?

Longer than the time you might take to notice an intrusion. Choose a period with the owner, write it down, and revisit it yearly. Several months of restore points is a common starting conversation, not a requirement.

Are encrypted backups necessary?

CISA recommends encrypted offline backups of critical data. Keep the keys and recovery instructions in a separate place so the backup can still be opened after a major incident.

What if I only have a small budget?

Two external drives rotated weekly, one always off-site and unplugged, give a genuine offline copy for the price of the drives and a calendar reminder.

Want checks like this in your inbox?

The briefing is published on this site every morning. The email edition is not sending yet — leave your address and you’ll be among the first told when it starts. Nothing is sent in the meantime.