How to Prove Backup Immutability for Cyber Insurance Renewals
Cyber insurers are no longer asking the backup question at the level of “do you have backups?”
Coalition’s current agency application asks whether the insured maintains at least weekly backups of all sensitive or otherwise critical data and all critical business systems offline or on a separate network.[1] Travelers’ CyberRisk Short Form asks whether the applicant has backup and recovery procedures in place for all important business and customer data.[2] The Hartford’s 2025 CyberChoice underwriting application goes further, asking whether critical data is backed up weekly or monthly, whether those backups are stored offline and/or isolated from production systems, and how often the applicant tests recovery.[3] The Hartford’s ransomware supplemental drills down again: what best describes the backup procedure, what best describes the backup storage, how much of the network could be recovered from backup, and how often fail-over and recovery procedures are tested.[4]
That is the real underwriting shift.
The insurer is not buying your backup vendor logo. It is evaluating whether a ransomware event ends in a contained recovery or an eight-figure business interruption.
For MSPs, that creates a recurring problem. Veeam, Datto, and other BCDR platforms expose plenty of useful data — job histories, repository settings, verification results, screenshots, and recovery points — but they do not package that data into the exact sentence a broker needs to defend on a renewal form:
“Yes. Critical systems are backed up at least weekly, the backup copies are isolated or immutable, and recovery is tested on a documented cadence.”
That translation layer is where renewals get messy.
What carriers are actually asking when they ask about backups
The language differs by carrier, but the underwriting logic has converged.
Coalition — CYUSP-00NA-1022-01, Question 5
Coalition’s backup question is deceptively short. It asks whether the named insured maintains at least weekly backups of all sensitive or critical data and all critical business systems offline or on a separate network.[1]
That means there are really four sub-tests hiding inside one checkbox:
- Frequency — at least weekly.
- Coverage scope — all critical systems and critical data, not just “the file server.”
- Isolation — offline or on a separate network.
- Operational reality — this must be true now, not aspirational.
Travelers — CYB-14203 Rev. 03-19, Question 3d
Travelers asks a broader question: whether the applicant has backup and recovery procedures in place for all important business and customer data.[2]
That sounds softer than Coalition, but it is not a free pass. Travelers’ form is intentionally short. It does not mean Travelers has no opinion about isolation, testing, or recovery discipline. It means those details often move into underwriting conversations, supplements, or the carrier’s broader risk services context.
The Hartford — CB 00 H027 03 0824, Section 6
The Hartford’s current underwriting application is the clearest public expression of where backup underwriting is going.[3]
It asks:
- Is critical data regularly backed up?
- If yes, is it backed up weekly or monthly?
- Are backups stored offline and/or isolated from production systems?
- How often does the applicant test recovering data from backup?
That structure matters. Hartford is not treating backup frequency, isolation, and recoverability as one issue. It is treating them as three distinct underwriting facts.
The Hartford ransomware supplemental — 20-GS-1070836
The ransomware supplemental is even more revealing.[4] It asks what best describes the applicant’s backup procedure, what best describes backup storage, what percentage of the network could be recovered from backup, how many hours restoration would take, and how often fail-over and recovery procedures are tested.
In other words: for ransomware underwriting, “we have backups” is not an answer. It is the beginning of the interview.
Backup success is not the same thing as backup defensibility
This is where MSPs get trapped.
Most backup platforms are designed to answer operational questions like:
- Did the job run?
- Did the VM boot?
- Is the repository reachable?
- Is the cloud copy present?
- Is there a recovery point from last night?
Insurers are asking a different class of question:
- Could a threat actor who compromises production credentials also destroy the recovery path?
- Is there an immutable or isolated copy that survives a domain compromise?
- Has anyone demonstrated that the protected systems can actually be restored in a useful timeframe?
- Is the control true for critical systems, not just a subset?
Those are not the same thing.
A green dashboard does not automatically equal a defensible renewal answer.
What “immutable,” “offline,” and “separate network” actually mean in practice
The cleanest underwriting answers usually come from one of three architectures:
- True offline copies — disconnected media or workflows where the protected copy is not reachable from the compromised production plane.
- Immutable storage — repositories or object storage with write-once / non-deletable controls for a defined period.
- Logically isolated copies — offsite or separate environments with materially different admin paths, credentials, and blast radius.
The weakest answers usually involve a backup target that is technically “elsewhere” but still sits on the same trust boundary as production.
A NAS on the same domain, reachable with the same privileged credentials, is much harder to defend as “offline or on a separate network” than a hardened Linux repository, object storage with immutability, or a cloud platform with meaningful deletion protections and separate control planes.
That does not mean every same-network design automatically fails underwriting. It means the burden of explanation gets much heavier.
What Veeam shows — and what it still does not answer for the carrier
Veeam gives MSPs some of the strongest raw ingredients for a defensible backup answer.
Where Veeam is strong
Veeam’s hardened repository feature lets you specify a time period during which backup files are immutable; during that period they cannot be moved, modified, or deleted.[5] That is exactly the kind of control insurers want to hear about when they ask whether backups are isolated from ransomware.
Veeam also gives you a formal recovery-verification story. SureBackup is designed to test machine backups and confirm that restore points are recoverable,[6] and Veeam’s backup recovery verification tests include predefined tests, backup file validation, and custom verification scripts.[7]
That is strong evidence for two insurer-relevant facts:
- the backup copy is designed to resist modification or deletion for a defined period, and
- the backup is not purely theoretical because it can be verified and tested.
Where the Veeam gap still shows up
The problem is not that Veeam lacks data. The problem is that the data lives in the vocabulary of Veeam, not the vocabulary of underwriting.
A broker or underwriter usually does not want a tour of your Veeam architecture. They want a concise answer to these questions:
- Which workloads count as “critical business systems”?
- Are all of them backed up weekly or better?
- Which repository or copy is immutable?
- For how long?
- Is immutability applied to every relevant job, or only some?
- When was the last meaningful restore test for those critical systems?
- Were the results successful?
That is the Veeam specificity problem.
The console may show repository settings, job outcomes, and verification results. But it does not natively produce a carrier-ready, cross-workload summary that says:
“All critical workloads are covered; immutable copies exist for X days; last successful recovery verification occurred on Y date; exceptions are Z.”
An MSP usually has to assemble that statement manually.
What to capture from Veeam for a defensible renewal answer
If you are answering Coalition Q5 or The Hartford Section 6 from a Veeam environment, the minimum defensibility packet usually includes:
- the repository or object-storage configuration showing immutability,
- the list of jobs protecting critical systems,
- the backup schedule for those jobs,
- the last successful backup timestamp,
- the latest SureBackup or verification results,
- a short exception list for any systems not included.
That is the difference between “Veeam is installed” and “the answer is defendable.”
What Datto shows — and what the insurer still cannot infer automatically
Datto environments create a different but equally common gap.
Where Datto is strong
Datto SIRIS markets an Immutable Cloud Architecture designed to block unwanted alterations or deletions in the Datto Cloud, along with mandatory 2FA and cloud deletion defenses.[8] On the verification side, Screenshot Verification confirms that protected backup points are healthy and working by booting a virtualization and checking the outcome,[9] and Service Verification adds application-aware checks by confirming that selected services have started correctly.[10]
Those are strong operational signals.
If you are running a Datto shop, those features help answer two critical questions:
- Can the copy survive common destruction paths?
- Can the backed-up machine or services actually start?
Where Datto still needs interpretation for underwriting
The insurer’s question is still broader than the product feature.
Screenshot Verification shows that a protected machine can boot into a usable state.[9] Service Verification improves that by checking whether selected services are running.[10] Both are valuable. But neither one, on its own, proves all of the following:
- that every critical system is protected,
- that the protected copy is the one isolated from production,
- that cloud deletion protections are equivalent to full immutability for all copies,
- that the restore process has been tested at the business-process level.
Cloud Deletion Defense is a great example of why precision matters. Datto documents it as a way to regain access to deleted cloud snapshots, but it also notes that it does not protect local data and does not prevent removal through retention expiration.[11]
That makes Cloud Deletion Defense useful, but not interchangeable with a blanket statement that “our backups are immutable.”
What to capture from Datto for a defensible renewal answer
For Datto-backed renewals, the useful packet usually includes:
- proof of offsite/cloud replication and the relevant architecture,
- the Datto cloud immutability / deletion-protection context,
- Screenshot Verification results for protected systems,
- Service Verification results where applicable,
- the list of protected critical workloads,
- the last successful recovery test date,
- a plain-English explanation of what is protected locally versus in the cloud.
Again, the issue is not whether the data exists. It is whether it has been translated into insurer language.
The four most common bad backup answers on renewals
1. “Yes, we back up weekly”
That answer ignores scope and isolation. Coalition is asking about all critical systems and data, and The Hartford splits frequency from isolation and testing.[1][3]
2. “The dashboard is green”
A green dashboard usually means jobs ran. It does not prove that a ransomware actor cannot delete the recovery path.
3. “Screenshot Verification passed”
That is useful evidence, especially in Datto. It is not the same as showing the storage architecture is isolated or immutable, nor is it the same as proving business-level recovery preparedness.[9][10]
4. “We use Veeam hardened repository”
That is a strong start. It is still incomplete unless you can show which critical jobs land there, how long immutability lasts, and whether recoverability has been tested.[5][6]
What a carrier-ready backup evidence pack should look like
If you want to answer backup questions cleanly for Coalition, Travelers, and The Hartford, the evidence package should usually fit on one page with supporting screenshots or exports behind it.
The summary page
Your summary page should answer, in plain language:
- Protected scope: Which systems and data are considered critical?
- Frequency: How often are they backed up?
- Isolation: Where is the recovery copy stored, and what prevents production compromise from deleting it?
- Immutability: If used, what technology enforces immutability and for how long?
- Verification: When was the last restore test or recovery verification?
- Exceptions: Which systems are out of scope, degraded, or pending remediation?
The supporting evidence
Behind that summary, attach the minimum source evidence:
- repository or storage settings,
- latest successful job results,
- verification or restore-test outputs,
- list of protected workloads,
- notes on retention / immutability windows.
The goal is not to overwhelm the broker. The goal is to make the attestation defendable.
The practical rule for MSPs
If the carrier asks whether backups are weekly, isolated, and tested, do not answer from memory and do not answer from brand familiarity.
Answer from a packet.
A packet beats a conversation. A packet beats a screenshot buried in a portal. A packet beats “I’m pretty sure that repository is immutable.”
That is especially true when the insured is signing language that says the statements were made after reasonable inquiry.
The long-term opportunity hiding inside a simple backup question
The reason this matters for BindLedger is straightforward.
Backup verification is a perfect example of the category gap:
- the raw technical evidence already exists,
- the insurer questions are relatively stable,
- the current workflow is mostly manual interpretation,
- and MSPs carry the operational burden without a clean defensibility layer.
MFA is the most obvious control gap in cyber insurance. Backup immutability is the quieter one.
It is also one of the most commercially meaningful, because ransomware underwriting keeps forcing carriers to ask not only whether recovery copies exist, but whether they can survive the same compromise that took down production.
What to do right now
If your renewal is coming up and you cannot yet prove backup isolation and restore testing cleanly, start with what you can prove today.
BindLedger’s public scanner checks the email-security posture carriers and carrier-side scanners can already see from the outside. That will not answer Coalition Q5 or Hartford’s backup questions by itself. But it will give you a defensible baseline on one of the other silent underwriting surfaces.
Primary CTA: Can’t prove your backups are isolated? Start with what you can prove today — scan your domain now at bindledger.com/scan to verify the email-security controls carriers can see silently.
Secondary CTA: Want Veeam and Datto backup verification when it launches? Enter your email on BindLedger to get notified when backup evidence assembly goes live.