Offline, Isolated, Immutable Backups for Cyber Insurance

Offline, isolated and immutable backups are separate claims on a cyber insurance application, and one does not prove another. A copy can be isolated without being offline, immutable without being offline, or offline without any storage-enforced retention lock. Work out which properties each copy actually has, then keep evidence for each one instead of relying on a vendor's marketing label. If you cannot demonstrate a property, do not claim it.

What do offline, isolated, immutable and air-gapped mean?

They describe different things: reachability, separation, enforced retention and a physical or logical gap. These working definitions are for sorting your own evidence, and they do not replace any definition in your form or policy.

• Offline: the copy is not continuously reachable from production systems or ordinary administrative paths. Describe the actual disconnection or controlled connection window. A removable disk, tape or powered-off device is not automatically safe: it may stay attached, be lost, or hold data that was already damaged when written.
• Isolated: architectural, network, identity or administrative boundaries limit a production compromise from reaching the copy. This is a property to demonstrate. A different folder, bucket, tenant label or subnet does not establish it alone.
• Immutable: storage or service controls prevent modification or deletion for a configured retention period, subject to stated limits and privileged paths. Read-only permissions do not prove this, because an administrator may be able to change them. A screenshot of a checkbox alone does not prove it either.
• Air-gapped: use this term cautiously, and only where a physical or logical gap exists and is not continuously bridged. NIST SP 800-209 says strict implementations "should provide full physical and network-level separation," and notes that less strict technologies also get called air-gapping because they open data ports for limited sync windows. It is not a synonym for ordinary cloud backup.

Can a backup have one property but not the others?

Yes, and that is common. Each property answers a different question about the copy, so check each one on its own instead of inferring it from another.

Some examples:

• Isolated, not offline: an always-on repository in a separate account and network, managed with separate credentials and reached only through a narrow backup path.
• Immutable, not offline: a locked object store that remains reachable over an API.
• Offline, not immutable: a rotated drive in a safe. It is disconnected, but anyone who connects it may be able to overwrite it.

A restore test is a separate fact again. A successful restore shows the copy could be recovered, and it says nothing about isolation. Record it using a backup restore test evidence record.

How do insurance forms use these terms?

Wording varies by form, so answer the question in front of you. Public forms show how differently the same terms can be grouped, and none of these examples sets a rule for other carriers.

• The Hartford CyberChoice Underwriting Application (CB 00 H027 03 0824, copyright 2025) asks one Yes/No question: "are backups stored offline and/or isolated from production systems?" Recovery test frequency is a separate question. The form text does not define offline or isolated. If it is unclear which property your copy needs to support that answer, ask the broker or carrier before signing.
• A Hartford CyberChoice Secure supplemental ransomware application (marked copyright November 2021) asks "What best describes the applicant's back-up storage?" separately from how often network fail-over and recovery is tested. The answer choices did not appear in the text extraction reviewed for this article, so read them on your own copy. Do not assume every current applicant sees this form.
• Societies Insurance question 27 (SI CM07 APP 2026.10.08) asks: "Are backups kept offline or immutable, and tested at least twice a year?" It is one Yes/No covering several facts.

General guidance is not carrier wording, but it explains why these questions exist. CISA's #StopRansomware Guide recommends maintaining offline, encrypted backups, because many ransomware variants try to find and delete or encrypt accessible backups. It also says some cloud vendors offer immutable storage, and warns that immutable storage "does not meet compliance criteria for certain regulations and misconfiguration can impose significant cost."

An evidence matrix for each copy

Build one record per backup copy, with one entry for each property you intend to claim. Use these columns: claimed property, configuration or architecture, administrative identity, retention period, deletion or modification path, supporting artifact, last verification, exception and owner. Examples below are possibilities, not a required package.

Offline

• Configuration: media type, disconnection schedule and any controlled connection windows.
• Administrative identity: who can connect, collect or overwrite the media.
• Retention: rotation cycle and age of the oldest usable copy.
• Deletion or modification path: anyone with custody and a connected device.
• Artifact: media rotation and custody records.

Isolated

• Configuration: architecture and network diagrams, firewall rules and access-path documentation.
• Administrative identity: separate administrative accounts and MFA enforcement evidence.
• Retention: record it, though isolation does not depend on it.
• Deletion or modification path: every account or service path that can reach the repository.
• Artifact: dated identity and firewall exports. NIST SP 800-209 recommends managing cyber-attack recovery copies from systems that regular production and backup credentials cannot access, and it recommends auditing isolation at least annually.

Immutable

• Configuration: object lock, WORM, retention lock, deletion protection or immutable repository settings, exported rather than described.
• Administrative identity: who can change the policy.
• Retention: configured duration, and whether it covers the copies you actually need.
• Deletion or modification path: whether privileged users can shorten, bypass or delete.
• Artifact: configuration export, plus the contract or provider documentation showing the exact control and plan.

Restore-tested

• Configuration: recovery point and restore target.
• Administrative identity: tester and system owner.
• Retention: the tier the test copy came from.
• Deletion or modification path: not applicable to this claim. Do not treat a restore as proof of isolation.
• Artifact: the restore-test record and validation results.

Every entry also needs a last verification date, any exception and a named owner.

Why does a retention lock setting need a closer look?

The label alone does not tell you who can still remove the data. Check the mode, the retention period and the privileged paths for your exact product and plan.

Amazon S3 Object Lock shows why, as one product's example rather than a rule for other vendors. AWS says that in compliance mode a protected object version "can't be overwritten or deleted by any user, including the root user," with deletion of the AWS account as the only early path. In governance mode, a user with the s3:BypassGovernanceRetention permission can override the lock. AWS also notes that a simple delete request can add a delete marker while the locked version remains. Both modes could be described as "object lock," yet they support different statements about privileged access.

Do replication and sync make a copy offline or immutable?

Not automatically. A second cloud region, bucket or tenant may improve resilience, but it does not prove any of these properties unless access and retention paths support the claim.

NIST SP 800-209 describes replication as writing the same data to at least two separate locations, which says nothing about who can reach or delete it. CISA warns that automated cloud backups may not be sufficient, because encrypted local files can sync to the cloud and possibly overwrite unaffected data. For sync services specifically, see whether OneDrive or Google Drive counts as backup.

How can you verify immutability safely?

Do not attempt destructive operations against production data or production backups. Use a disposable test object, a non-production repository, a vendor-supported validation method or a documented control review.

If you use a test object, give it the shortest retention you can, because a real lock may not be removable early. Record who ran the check, what happened and which configuration was in effect. A control review is still useful evidence when a live test is not practical, as long as you describe it as a review.

Before you answer

• Read the exact wording, and ask the broker or carrier to clarify undefined terms.
• List each copy separately, and do not let the best copy speak for the others.
• Match each claimed property to a dated artifact.
• Record privileged paths and known exceptions.
• Report the restore test as its own fact.

This is practical training, not legal, coverage or underwriting advice. No architecture, artifact or product guarantees eligibility, pricing, coverage, renewal, limits or claim payment.

Sources

• The Hartford CyberChoice Underwriting Application, CB 00 H027 03 0824
• The Hartford CyberChoice Secure Supplemental Ransomware Application
• Societies Insurance Cyber Liability Supplemental Application, SI CM07 APP 2026.10.08
• CISA #StopRansomware Guide
• NIST SP 800-209, Security Guidelines for Storage Infrastructure
• AWS: Locking objects with S3 Object Lock