By Ryan Windt | Head of Growth Marketing | Updated April 2026
If you have read anything about qualifying for cyber insurance in the last two years, you have seen the phrase “immutable backups” somewhere in the requirements list. It appears in underwriting questionnaires, in policy conditions, in carrier declination letters, and in post-incident forensic reports explaining why a company could not recover without paying a ransom.
What it rarely appears with is a clear explanation of what it actually means, what counts, what does not, and what documentation an underwriter expects to see when they ask about it.
This guide covers all of that. By the end you will know exactly what immutable backups are, why carriers treat them as a near-mandatory control, what architectures satisfy underwriting requirements, and how to document your backup posture so it supports your application rather than raising questions.
Why Backups Became an Underwriting Control
For most of cyber insurance’s early history, backups were treated as a technical best practice that reduced the severity of a loss. Carriers assumed that most businesses had some form of backup in place and priced accordingly.
Then ransomware groups started targeting backups deliberately.
Modern ransomware operations do not simply encrypt production systems and demand payment. They identify and encrypt backup repositories first, specifically to eliminate the victim’s ability to recover without paying. The playbook is consistent: gain access, move laterally until backup systems are found, encrypt or delete backups, then deploy the main payload across production.
The result was a wave of claims where businesses had backups, their backups were destroyed or encrypted alongside their production data, and the only path to recovery was paying the ransom or rebuilding from scratch. Carriers paid those claims and adjusted their underwriting accordingly.
The requirement for offline or immutable backups is a direct response to that pattern. An immutable backup is one that cannot be encrypted, deleted, or modified by a ransomware payload — or by an attacker operating through compromised credentials — because the backup storage itself is protected against modification for a defined retention period. If production systems and all network-accessible storage are encrypted, an immutable backup remains intact and recoverable.
That is why it is now a first-tier underwriting control alongside MFA and endpoint detection. It is not about whether you have backups. It is about whether your backups survive the attack.
What “Immutable” Actually Means
Immutability is a property of storage, not a property of backup software. It means data written to a storage target cannot be modified or deleted for a defined period, regardless of what credentials are used to attempt the modification.
This is the critical distinction most businesses miss. Having cloud backups does not mean having immutable backups. Having daily backups to an offsite location does not mean having immutable backups. Having backups that require a separate login does not mean having immutable backups.
Immutability means the storage layer itself enforces a retention lock that cannot be overridden by any user, including administrators, during the retention period. An attacker with full admin credentials to your environment cannot delete or encrypt an immutable backup because the deletion request is rejected at the storage layer, not at the application or credential layer.
There are three primary mechanisms through which storage immutability is implemented:
Object lock (WORM storage)
Write-once, read-many storage is the cloud-native implementation of immutability. AWS S3 Object Lock, Azure Blob Storage immutability policies, and Google Cloud Storage retention policies all implement WORM semantics at the storage layer. Once data is written and the lock is applied, it cannot be deleted or overwritten until the retention period expires — even by the account owner, even by root credentials.
Object lock is the most commonly accepted form of immutable backup in cyber insurance underwriting. It is built into the major cloud providers, it is verifiable through configuration screenshots, and it has a clear audit trail.
Air-gapped backups
An air-gapped backup is physically or logically disconnected from the rest of your environment. A tape backup stored offsite is the classic air-gap. A backup copy written to media that is then physically removed from the network is an air-gap. Some backup vendors implement a logical air-gap through a purpose-built cloud vault that is not directly accessible from the customer’s environment during normal operations.
Air-gapped backups are accepted by underwriters and are particularly valued because they have no network-accessible attack surface. Their weakness relative to object lock is operational: they require physical or procedural discipline to maintain, and restoring from tape or physically isolated media takes longer than restoring from cloud-accessible object lock storage.
Backup vendor vaulting
Several backup vendors offer proprietary vaulting or immutability features built into their platforms. Veeam’s Hardened Repository, Datto’s cloud immutability, Acronis Cyber Protect’s immutable backup option, and similar features implement immutability either through Linux immutable file attributes, cloud object lock under the hood, or purpose-built WORM storage in the vendor’s infrastructure.
These are accepted by underwriters when the immutability is implemented at the storage layer (not just a software-level flag that admin credentials can override) and when the vendor can provide documentation of how the immutability is enforced.
The 3-2-1-1-0 Rule: What Underwriters Mean When They Say “Backup Architecture”
When underwriters ask about your backup architecture, they are evaluating whether your backup design survives a scenario where everything on your network is compromised. The framework most commonly referenced is 3-2-1-1-0:
3 — three copies of your data (production plus two backups)
2 — stored on two different media types (e.g., local disk plus cloud, or local disk plus tape)
1 — one copy stored offsite
1 — one copy that is either offline (air-gapped) or immutable (object lock)
0 — zero untested restore processes (every backup path has been verified through an actual restore test)
The fourth and fifth digits are what separate modern backup standards from legacy ones. The “1 offline/immutable” requirement is the direct response to ransomware destroying network-accessible backups. The “0 untested restores” requirement is the direct response to businesses discovering at recovery time that their backups were not actually working.
Underwriters evaluate your architecture against this framework. An architecture that meets 3-2-1 but not 3-2-1-1-0 — meaning no immutable or offline copy and no documented restore testing — is increasingly treated as inadequate coverage for ransomware scenarios.
What Does Not Count as Immutable Backups
This is where most misrepresentation issues arise. Businesses attest to having immutable or offline backups and a post-incident forensic investigation reveals that what they had did not survive the attack. Understanding what does not qualify is as important as understanding what does.
Cloud sync services (OneDrive, Google Drive, Dropbox, SharePoint)
Cloud sync is not a backup. When ransomware encrypts files on a device that is synced to OneDrive, the encrypted versions of those files sync to the cloud and overwrite the clean versions. Most sync services retain version history, which can help recover some files, but version history has retention limits, sync is not immediate for all file types, and this is not a recoverable backup architecture for a full ransomware event.
Underwriters do not accept cloud sync services as backup coverage.
Backup targets on the same domain with the same credentials
If your backup repository is accessible using the same Active Directory credentials that an attacker has compromised, your backups are accessible to the attacker. A ransomware group operating with domain admin credentials can reach any storage target that is mounted to the domain, including NAS devices, backup servers, and cloud backup accounts connected to the same identity infrastructure.
The backup target needs to use credentials that are separate from your production environment. This is a distinct requirement from immutability — a backup can be on separate credentials but still be mutable, and a backup can be immutable but still be on the same credentials. Best practice is both: separate credentials and immutability.
Snapshots without immutability
VM snapshots and storage snapshots are valuable for rapid recovery from non-ransomware events, but they are typically stored on the same storage infrastructure as production data. A ransomware payload or attacker with storage admin access can delete snapshots. Snapshots without a separate immutable copy are not a qualifying backup architecture.
Backups that have never been tested
This is the most common gap and the one that causes the most damage when discovered post-incident. A backup that has not been tested may not actually be recoverable. Backup jobs complete without errors every night and produce unusable or incomplete data sets more often than most IT teams realize. Underwriters ask about restore testing specifically because they have seen enough claims where backups existed and were not recoverable.
A backup you have never successfully restored from is not a backup in any operationally meaningful sense.
The “we back up to the cloud” statement without specifics
Saying you back up to the cloud on an insurance application does not tell an underwriter whether your cloud backups have object lock enabled, whether they are on separate credentials, what your retention period is, or whether you have tested restoration. Vague backup attestations are flagged for follow-up and can result in coverage conditions or sublimits if the specifics do not satisfy underwriting standards.
The Restore Testing Requirement
Restore testing is the zero in 3-2-1-1-0 and it is underweighted by most businesses relative to how seriously underwriters treat it.
An immutable backup with no verified restore capability is operationally worthless. You will not discover that your backup encryption keys are missing, that your backup catalog is corrupted, that your retention policy did not apply correctly, or that your RTO assumption was off by a factor of ten during a live ransomware event. You will discover it during a restore test, when the cost of the discovery is a few hours of IT time rather than days of operational downtime.
What underwriters want to see from restore testing:
Quarterly restore tests at minimum. Annual testing is not sufficient for a control this critical. Most carriers now ask about restore test frequency and look for quarterly as the standard. MSPs managing client backups should be running restore tests on a per-client basis.
Documentation of the test. A restore test that is not documented did not happen from an underwriting perspective. The documentation does not need to be elaborate — a log entry, a ticket in your PSA, a spreadsheet row — but it needs to record the date, what was restored, whether the restore was successful, and how long it took.
Testing to RTO. A restore test that successfully recovers data in 72 hours does not satisfy a business whose RTO is 4 hours. Your restore tests should be timed so you know what your actual recovery time looks like and whether it matches the assumptions in your IR plan and business continuity planning.
Testing from the immutable copy specifically. Many businesses test restores from their local or primary backup and never test the immutable copy. The immutable copy is the one that will be used after a ransomware event destroys everything else. That is the copy that needs to be tested.
MSP-Specific Backup Requirements
MSPs have a more complex backup posture requirement than standard SMBs because they are managing backups for multiple client environments simultaneously, and because a compromise of the MSP’s backup infrastructure is an aggregation event affecting every client.
Underwriters writing MSP policies look for:
Separation of client backup environments. Client backups should be isolated from each other so that a ransomware event in one client environment does not propagate to backup targets for other clients. Shared backup infrastructure with client-segmented vaults is acceptable; a single unsegmented backup target for all clients is not.
Immutability on the MSP’s own systems, not just clients’. MSPs sometimes focus on documenting client backup architecture and overlook their own. Your RMM, PSA, documentation platform, and internal systems need the same immutable backup coverage you are providing for clients.
Documented restore testing across the client base. Underwriters ask MSPs for evidence of restore testing and expect it to cover client environments, not just the MSP’s own internal systems. Your PSA should have a cadence for per-client restore tests and the tickets to prove they happened.
Backup credentials that are not part of the managed tenant. If your backup platform uses credentials from the client’s Active Directory domain, a domain compromise compromises backup access. Backup service accounts should be outside the managed tenant wherever the backup platform supports it.
For a full treatment of the MSP-specific controls that underwriters require, see our MSP RMM Hardening guide and the Minimum Controls Checklist.
Building Your Backup Evidence Package
The documentation required to satisfy underwriters on backup posture is more involved than for most other controls because there are more variables to verify. Here is what a complete backup evidence package looks like:
Immutability verification:
- Screenshot of object lock configuration in your cloud storage (AWS S3, Azure Blob, GCS) showing lock mode (governance or compliance) and retention period
- Or screenshot of backup vendor immutability settings (Veeam Hardened Repository configuration, Datto immutability policy, etc.) showing immutability is enabled and the retention period
- Or documentation confirming air-gap procedure (for tape or physically isolated media)
Architecture documentation:
- A brief backup topology diagram or written description showing: backup frequency, backup targets, which copy is immutable/offline, retention periods, and whether backup credentials are separate from production
- Confirmation that backup targets use credentials separate from your production Active Directory or identity provider
Restore testing documentation:
- Log of restore tests for the last 12 months showing date, what was restored, success/failure, and time to restore
- Evidence that the immutable copy specifically has been tested (not only the local or primary copy)
- Restore test results showing actual RTO compared to target RTO
Coverage confirmation:
- RMM agent or backup console report showing backup jobs are running successfully across all covered systems — not just workstations, but servers, domain controllers, and any system containing critical data
Organize this in a folder labeled “Backup Evidence” alongside your MFA and IR plan documentation. Together these three packages cover the controls that receive the most scrutiny in cyber underwriting.
The Backup Underwriting Self-Assessment
Before your next application or renewal:
- At least one backup copy uses object lock, WORM storage, or a physically air-gapped target
- Backup storage credentials are separate from production Active Directory or identity provider
- Backup targets are not mounted to the production domain or accessible via compromised domain credentials
- Backups run at a frequency appropriate to your RPO (daily minimum for most businesses, more frequent for high-transaction environments)
- Retention period covers at least 30 days (longer is better — some ransomware sits dormant before deploying)
- Restore tests are conducted quarterly and documented in your PSA or IT ticketing system
- The immutable copy specifically has been tested in the last 12 months
- Server backups are included — not workstations only
- Cloud sync services (OneDrive, SharePoint, Google Drive) are not counted as backup coverage
- For MSPs: client backup environments are segregated from each other and from the MSP’s own infrastructure
A complete “yes” on every line with supporting documentation is one of the strongest signals you can send an underwriter that a ransomware event will not result in a total loss.
How SeedPod Cyber Evaluates Backup Posture
Because SeedPod underwrites directly, we review backup architecture at application rather than at claim time. When we see gaps — missing immutability, untested restores, credentials that share the production domain — we tell you before binding. That is how the coverage you receive reflects the protection you actually have, and how the terms you receive reflect a risk we have actually evaluated.
If you want to understand how your current backup architecture looks through an underwriter’s eyes before your next renewal, contact us.
Related resources:
- Cyber Insurance Requirements: The Minimum Controls Checklist for SMBs and MSPs
- MFA Implementation Guide for SMBs and MSPs
- Cyber Incident Response Planning: The SMB and MSP Guide to Building a Plan That Actually Works
- Does Cyber Insurance Cover Ransomware Payments?
- Ransomware Costs and Coverage: What Happens After an Attack
- Cyber Insurance Renewal Checklist
This guide is for informational purposes only and does not constitute legal or insurance advice. Coverage terms, eligibility, and underwriting requirements vary by carrier and risk profile. Consult a licensed insurance professional for guidance specific to your situation.