Are backups kept offline (disconnected) or immutable / air-gapped?
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 |
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.
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
Stop answering this from memory
Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.
Assess your posture