---
title: "Are backups kept offline (disconnected) or immutable / air-gapped?"
url: https://insuranceposture.com/questions/backup-and-recovery/backups-kept-offline-immutable-air-gapped
category: "Backup and recovery"
canonical_key: immutable_backups
evidence_state: partial
updated: 2026-08-24
---

# Are backups kept offline (disconnected) or immutable / air-gapped?

URL: https://insuranceposture.com/questions/backup-and-recovery/backups-kept-offline-immutable-air-gapped
Section: Backup and recovery
Evidence state: Partly verifiable from your tenant

Modern ransomware deletes backups before it encrypts anything. This question exists because carriers paid for the years when that was a surprise.

## What the carrier is actually asking

The carrier is asking whether at least one copy of your data cannot be deleted or altered by someone holding administrative credentials in your environment. Offline means physically disconnected. Immutable means write-once for a defined period, enforced by the storage platform. Air-gapped means separated by something other than a network path an attacker can traverse. Any of the three answers the question; a second copy in the same account under the same credentials does not.

## Why it is underwritten

Attackers now target backup infrastructure first, because destroying recovery options is what makes extortion work. An insured with an immutable copy negotiates from a different position, and the carrier's expected loss changes accordingly. This is the backup question most likely to be treated as a condition of coverage rather than a rating factor.

## Where the answer lives in Microsoft 365, Entra ID, and Azure

Where backups land in Azure storage, immutability is a configuration Insurance Posture can read. Where they land in a backup vendor's cloud or on tape, the evidence comes from that system.

| Platform | Where the setting lives | What has to be true |
| --- | --- | --- |
| Azure | Immutable blob storage with a time-based retention policy, locked rather than unlocked | A **locked** policy. An unlocked immutability policy can be shortened or removed by an administrator, which defeats the entire point |
| Azure | Container and blob soft delete, and versioning | Enabled, as a second layer. Soft delete alone is not immutability, because a sufficiently privileged account can still purge |
| Azure | Resource locks and separate subscription or tenant boundaries for backup storage | Backup storage is not administered by the same identities that administer production |
| Azure | Key Vault purge protection for keys protecting backup data | Purge protection on, so key deletion cannot render an immutable copy unreadable |
| Backup vendor | Vendor immutability or object-lock settings and their lock state | Immutability enabled at the vendor and confirmed locked. Insurance Posture does not read backup vendors, so this is attested |

**Locked versus unlocked is the whole question**

An unlocked immutability policy satisfies an auditor reading a settings page and does not survive an attacker with subscription Owner. Locked policies cannot be shortened by anyone, including you, which is exactly why they count and exactly why people hesitate to set them.

## What a defensible yes requires

- At least one copy is protected by a locked, time-based immutability policy or is genuinely offline.
- The credentials that can administer production cannot delete or shorten the protected copy.
- The retention period on the immutable copy exceeds your realistic detection time, since a dwell time longer than the lock window means the clean copy has already expired.
- Key material protecting the copy is itself protected from deletion.
- A restore has been performed from the immutable copy specifically, not only from the online one.

## How this answer goes wrong

The most frequent overstatement is treating replication as immutability. A second storage account, a geo-redundant pair, or a replicated appliance protects against hardware and regional failure and offers nothing against a credential that can delete both. The second is unlocked policies, which look identical in a screenshot. The third is a lock window shorter than the time it takes you to notice a problem, which produces a technically immutable copy that has already rolled over by the time you need it.

## If this answer turns out to be wrong

Backup immutability and restore testing are trivially checkable after a ransomware loss, which is why an overstated answer here is one of the few that regularly turns into a coverage argument. Whether anything follows from an inaccuracy depends on materiality, on the policy wording, and on the law of the governing state: [what counts as misrepresentation on a cyber application](https://insuranceposture.com/glossary/misrepresentation). The other consequence terms are collected in the [glossary](https://insuranceposture.com/glossary).

## Frequently asked

### Does cloud storage count as air-gapped?

Not by location. It counts when the copy is immutable and administered under separate credentials. Being in a different cloud account is a meaningful separation only if the identity boundary is real.

### Is tape still an acceptable answer?

Yes, and it is the cleanest form of offline. Carriers accept it readily. The follow-up will be about restore testing, because tape estates are where untested restores concentrate.

### How long should the immutable window be?

Longer than your plausible dwell time. Thirty days is common and is short relative to how long intrusions go undetected. Sixty to ninety days is a stronger position.

### What if our backup vendor manages immutability?

That is a valid answer. Get the setting confirmed in writing, including whether it is locked, and keep it with the application file. It is the artefact that supports the answer under review.

## Related questions

- [Are there procedures and tools to back up sensitive data and critical systems?](https://insuranceposture.com/questions/backup-and-recovery/procedures-tools-back-up-sensitive-data-critical-systems)
- [Are backups secured with different access credentials from administrator credentials?](https://insuranceposture.com/questions/backup-and-recovery/backups-secured-different-access-credentials-from-administrator-credentials)
- [Are backups protected by MFA?](https://insuranceposture.com/questions/backup-and-recovery/backups-protected-by-mfa)
- [Have you tested the successful restoration and recovery of key server configurations and data from backups in the last 6 months?](https://insuranceposture.com/questions/backup-and-recovery/you-tested-successful-restoration-recovery-key-server-configurations-data)

---

Insurance Posture by SecValley. https://insuranceposture.com
The question library is written in our own wording to reflect the control topics that recur across US cyber application and ransomware supplemental forms. No carrier form is republished.
SecValley is not a law firm, an insurance broker, an agent, or a carrier, and holds no producer licence. Nothing here is insurance advice, legal advice, or a coverage determination, and no attorney-client relationship arises from reading it. Statements about what a party to a cited case did, knew, or intended are allegations drawn from court filings and contemporaneous reporting, not findings of fact.
Your organization's authorized signer remains responsible for the accuracy of any application. Consult a licensed broker and qualified counsel before binding.
