What does "immutable backup" mean in plain English?

A backup copy that nobody can change or delete for a set period, even someone with full administrator access. The storage system enforces that lock itself, so ordinary account permissions can't override it.

Is Microsoft 365's built-in retention a backup?

No. It can be bypassed by a global admin account, including one that's been compromised, and Microsoft's shared responsibility model places responsibility for backing up your own data with you, not with Microsoft.

Can our IT provider just switch immutability on?

Often, yes, if the backup platform already supports it. That's typically a configuration change rather than a new product. Ask for written confirmation once it's done, along with the retention window.

What actually happens if I tick yes on the form when I shouldn't have?

Under the Insurance Act 2015, a knowing or reckless misrepresentation lets the insurer treat the policy as if it never existed and refuse the claim. An honest mistake is treated more proportionately, but it's not a distinction worth relying on. Checking the real setup before you sign avoids the question entirely.

What should a qualifying backup setup actually include?

Immutability that's actually switched on, not just available as a feature; backup credentials kept separate from day-to-day admin accounts, so one compromised login can't reach both; and a restore that's been tested recently, not assumed to work when it's needed.

← Back to blog

30 July 2026

What 'Immutable Backup' Means on Your Cyber Insurance Form

Close-up of hands reviewing insurance policy paperwork with a pen on the table

Photo by Mikhail Nilov via Pexels

Cyber insurance renewal forms have started asking a question that trips up a lot of UK small and mid-sized businesses: "Do you maintain immutable, air-gapped, or offline backups of your critical business data?" It reads like a straightforward yes or no. In practice, it's testing something far more specific than whether backups exist.

Insurers added the question because ransomware groups worked out that deleting or encrypting a victim's backups first is the fastest way to force a payout. A business that can restore its own systems has far less reason to pay. A backup that anyone with the right admin login can wipe, including someone who's stolen that login, doesn't give an insurer much confidence a claim can be avoided.

This post covers what "immutable" actually means, three backup setups that commonly fail the question without the business realising it, what good practice looks like according to UK guidance, and what to do if your honest answer is no. It's one section among several that have grown more detailed on current forms. If you want the wider picture, including MFA, wire transfer verification and vendor risk, see our guide to answering cyber insurance renewal questions without voiding cover.

What "immutable" actually means

An immutable backup is one that can't be altered or deleted for a fixed period after it's created. Not by you, not by your IT provider, and not by anyone using stolen admin credentials. NCSC's guidance on ransomware-resistant backups sets out the same idea for backup systems generally: they should be resilient to destructive actions, and it shouldn't be possible for an attacker to deny access to a backup entirely, whether that's by deleting the individual accounts used to reach it or the whole customer account outright.

The part insurers actually care about is the stolen-credentials scenario. Most backup systems can be wiped by anyone holding the right admin account. Immutability means the storage platform itself enforces the lock, so no set of credentials can override it during the retention window, even a genuinely valid admin login that's fallen into the wrong hands. Vendors use different names for this, object lock, write-once-read-many (WORM) storage, immutable snapshots, but the underlying control is the same.

Three setups that commonly don't qualify

These come up often, and business owners are frequently surprised to learn their existing setup doesn't count.

A NAS or USB drive on the office network

A network-attached storage device, or an external drive that stays plugged in, is reachable from the rest of the network by design. If ransomware spreads across the environment, it can reach that device too, and an attacker with domain admin access can wipe it along with everything else. These devices still have a role in a wider backup strategy, but on their own they don't satisfy the question.

Treating Microsoft 365's built-in retention as a backup

Microsoft 365 includes retention and recycle-bin features, and some businesses rely on them as their only backup. Under Microsoft's shared responsibility model, the customer, not Microsoft, is responsible for backing up their own Microsoft 365 data, and retention isn't a substitute for that. An attacker with global admin access to a tenant can delete data and purge retention holds in the same session. If native retention is the only protection in place, the honest answer to the insurance question is no.

A cloud backup with immutability switched off

This is the most common gap of the three. Several established backup platforms offer immutability as a feature, but it isn't always switched on by default, someone has to enable it. A business can be paying for a backup product that's fully capable of qualifying while the actual setting sits untouched. There's no way to tell from the outside without checking directly with whoever manages it.

What good practice actually looks like

NCSC's principles for ransomware-resistant cloud backups go further than "have a backup somewhere." They call for a backup system that stays reachable even if an attacker manages to delete individual accounts or attempts to lock the whole business out, protection against corrupted data being flooded into the backup store so older, clean versions stay restorable, and alerts triggered by things like mass deletion requests or changes to retention settings, not silence. None of that happens by default in a general-purpose cloud storage account. It needs a backup platform actually built around those principles, configured that way, and checked.

That lines up with what we saw when we walked through how a small business ransomware attack actually unfolds: attackers go after backups early and deliberately, precisely because most businesses assume backups are the one thing that's always safe.

Three questions to ask your IT provider before you sign

Send these over before ticking the box.

"Is immutability actually switched on, and for how long?" A platform that supports the feature but has it turned off doesn't help. Ask for the retention window in writing, not just confirmation that the capability exists, since a lock that expires after a day or two doesn't help much if an attacker has already been sitting in your systems for longer than that.
"If our admin login were stolen tomorrow, could that account delete our backups?" The answer needs to be no. If your provider isn't sure, treat that as a no until they can show otherwise.
"Can you send me something that shows immutability is switched on for our account?" A screenshot or a line from the vendor's own admin console is worth more than a verbal assurance.

This is exactly the kind of gap our backup & disaster recovery work is built to close before a renewal form catches it, not after. If you'd like a second opinion on where your current setup actually stands, book a call with our team and we'll take it from there.

If your honest answer is no

Answer honestly on the form, and use the renewal as the reason to fix the gap rather than something to talk your way around.

Start by asking your IT provider whether immutability can simply be switched on within the platform you already have. In a lot of cases that's a configuration change rather than a new purchase, and it can be resolved within days.

What to avoid is checking yes to dodge a higher premium when the honest answer is no. Cyber insurance for UK businesses falls under the Insurance Act 2015's duty of fair presentation, and the remedy available to an insurer depends on how the misrepresentation happened. A knowing or reckless "yes" on a question like this counts as deliberate or reckless non-disclosure, and the Act allows the insurer to treat the policy as if it never existed, refusing the claim and keeping the premium already paid. An honest mistake, genuinely believing the setup qualified when it didn't, is treated more proportionately. Neither is something to find out about partway through a claim, which is exactly why it's worth checking the real answer before you sign, not after.