Cyber insurance applications include a question that catches a lot of small business owners off guard: “Do you maintain immutable, air-gapped, or offline backups of your critical business data?”

Carriers added that question to renewal forms because ransomware operators worked out that the fastest way to force a payout is to wipe the backups first and encrypt everything else after. CISA, the FBI, and the Internet Crime Complaint Center have all documented this pattern as one of the most common moves in current ransomware playbooks. A business whose backup copies can be deleted using the same admin credentials an attacker just stole has no recovery path other than paying the ransom.

This post covers what immutable backup means, three common backup setups that do not qualify, the questions to send your IT provider before you sign the form, and what to do if your honest answer is no.

Immutable backup, defined

An immutable backup is one that cannot be modified or deleted for a fixed period of time, including by you, by your IT provider, and by anyone using stolen admin credentials.

The stolen credentials piece is what carriers care about. Most backup systems can be wiped by anyone with admin access. Immutability means the backup platform itself enforces the lock at the storage layer, and no credentials, however privileged, can override it during the retention window. Some platforms call this object lock, write-once-read-many, or WORM storage. The terminology varies between vendors, but the underlying control is the same.

Three common backup setups that do not qualify

Three setups come up regularly that don’t satisfy the immutability question, even though business owners often assume they do.

A NAS or external drive in your office

A network-attached storage device sitting in your server room is reachable from your network by design. If ransomware spreads across your environment, it can reach the NAS. An attacker with domain admin credentials can wipe what’s on it. An external drive that someone plugs in once a week and leaves connected has the same exposure.

These devices have a role in a broader backup strategy. On their own, they do not satisfy the immutability question.

Microsoft 365 retention treated as a backup

Microsoft 365 includes data retention features, and some businesses use them as their backup solution. They are not a backup in the sense the form is asking about. An attacker with global admin access to your tenant can delete data and purge retention holds.

Under Microsoft’s shared responsibility model, customers retain responsibility for backup and protection of their own data, separate from what Microsoft provides at the platform level.

If your only protection for Microsoft 365 data is what Microsoft provides natively, the honest answer to the immutability question is no.

A cloud backup with immutability switched off

This is the most common gap. Many reputable backup platforms include immutability as a feature, but the setting is not always enabled by default. The capability exists, and someone needs to turn it on. Your business may be paying for a backup solution that looks credible on paper while the immutability toggle sits in the off position. You cannot tell from the outside without checking.

Three questions to send your IT provider before you sign the form

Copy these into an email and send them before you check the box.

Question one: “Are our backups immutable, and if so, how long is the immutability window?”

Carrier guidance has tightened in the past two years. Most insurers want a window of at least 14 days as a floor, with 30 days increasingly cited as the preferred minimum. Attackers sometimes sit in a network for weeks before triggering ransomware, which means a backup from yesterday may already be compromised. The window needs to be long enough to give you clean restore points from before the attacker arrived.

Question two: “If our domain admin account or Microsoft 365 global admin account were stolen tomorrow, could that account be used to delete our backups?”

The correct answer is no. If the answer is yes, or if your provider is not sure, your backups are not immutable in the way the form means.

Question three: “Can you send me a screenshot or vendor documentation showing that immutability is enabled on our account?”

A provider who can send something concrete has done the work. If they come back with verbal reassurance and nothing to show, treat that as a no until they can demonstrate otherwise.

What a qualifying setup looks like

For your backup to honestly satisfy the question on the form, a few things need to be true at the same time.

The backup platform needs immutability turned on, not only available as a feature. Several major vendors including Veeam, Datto, Rubrik, and Acronis offer the capability, along with most cloud storage providers that support S3-compatible object lock. A vendor name on the invoice does not, by itself, answer the question. The setting has to be turned on, scoped properly, and tied to credentials that aren’t shared with the rest of your environment.

The backup credentials need to sit outside your regular administrative accounts. If the same login that manages your Microsoft 365 environment also controls your backup platform, a compromised admin account can reach both. A qualifying setup uses isolated credentials outside your day-to-day identity environment.

The retention window needs to be long enough. A 24-hour backup that overwrites itself daily does not help if an attacker has been in your environment for a week. CISA’s #StopRansomware Guide lists immutable, tested backups as a baseline control, and most insurers now align with that position.

Restores also need to be tested. A backup nobody has tried to restore in the past 12 months is not something you can rely on when it matters. Most carriers now ask for the date of your last successful restore test, and they want to see one.

What to do if your honest answer is no

Declare what you have on the form, and use the renewal process as the reason to fix what isn’t there.

The first step is to ask your IT provider whether immutability can be enabled on your existing platform. In many cases the platform already supports it, and turning it on is a configuration change rather than a new product purchase. If the platform supports it and nobody has switched it on, that conversation can usually be resolved in a few days.

If your provider does not know what you’re asking, or cannot give a clear answer to the three questions above, that response is itself important information. This area needs attention before your next renewal date, even if other parts of your IT setup are handled well.

One thing to avoid: do not check yes on the form to dodge a premium hike. Cyber insurance applications function as warranty documents. If a forensic investigation after a claim finds your backups did not match what you declared, the carrier can rescind the policy. Coverage is then treated as if it never existed, and any prior payouts under the same policy term can be clawed back. Misrepresentation discovered after a claim is one of the most expensive mistakes a small business can make on an insurance form.

Checking no on the form will likely cost you something at renewal, either in premium or in coverage terms. That’s a known cost, and it’s manageable. Take the hit on the application, and use the months between now and your next renewal to close the gap.

Frequently asked questions

What does immutable backup mean in plain English?

A backup that nobody can change or delete for a set period of time, even with administrator credentials. The storage platform enforces the lock at the system level, so user permissions cannot override it.

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

No. Native retention can be bypassed by a global admin or by anyone who steals one. Microsoft’s shared responsibility model places backup of your data on the customer, separate from retention.

How long should the immutability window be?

Most insurers and security frameworks point to a minimum of 14 days. 30 days is increasingly the preferred floor, and some carriers want longer. A longer window gives you more confident recovery if an attacker has been inside your environment for an extended period.

Can my IT provider just turn immutability on?

Often, yes. If your backup platform supports the feature and it has not been enabled, this is a configuration change rather than a new purchase. Ask for written confirmation once it’s done.

What happens if I check yes on the form when I shouldn’t?

The carrier can rescind the policy after a claim, which voids coverage retroactively. Any prior payouts under the same policy term can also be clawed back. Misrepresentation is one of the most common reasons cyber claims are denied.

Sources and further reading

• CISA #StopRansomware Guide — federal guidance on ransomware prevention, including backup and immutability recommendations.
• Microsoft shared responsibility model — Microsoft’s own documentation on which protections sit with the platform and which sit with the customer.
• FBI Internet Crime Complaint Center: Ransomware — current FBI guidance on ransomware threats and recommended controls.

If you’re not sure where your backups stand, that’s worth raising with your IT provider before your next renewal date. They should be able to walk you through the configuration and give you a clear answer to the three questions above. And if you don’t have an IT provider, feel free to reach out to us and we’ll help you sort it.

—

Featured Image Credit

This Article has been Republished with Permission from The Technology Press.

The most time-consuming ticket in your queue is rarely a hardware failure. It’s the PC infection that started when a user installed something they shouldn’t have been able to. Or it’s the broken configuration left behind after someone changed a setting IT can’t trace.

Local administrator rights (the ability to install software, modify system settings, and override security controls) are given to end users far more often than the risk warrants. 

The usual reason is efficiency. 

The practical result is the opposite. Machines that drift from baseline, infections that spread before they are caught, and remediation tickets nobody planned for. Revoking local admin rights directly removes the root cause of most of those tickets.

The Admin Rights and Support Ticket Connection

A standard user account limits what software can be installed, what system settings can be changed, and what processes can run at an elevated level. These limits are not arbitrary friction. They are the boundary that prevents most common problems from ever reaching the helpdesk.

When users have admin rights, those boundaries disappear. 

Software conflicts arise because no approval step exists to catch the incompatibility. Security tools get disabled because a user decided they were slowing things down. Network settings get modified during attempted self-fixes that go wrong. Each of those actions is a predictable support ticket in waiting.

Admin rights are not the cause of every request in the queue. They are the cause of most of the expensive ones.

What the Security Data Shows

The connection between admin rights and security incidents is well-documented, and the numbers make the operational argument clearly.

From 2015 to 2020, the BeyondTrust Microsoft Vulnerabilities Report found that removing administrative privileges could have mitigated 75% of all Critical Microsoft vulnerabilities.

The pattern holds because most critical vulnerabilities require elevated permissions to fully execute. 

An attacker who compromises a standard user account gets access to that user’s data and session. An attacker who compromises an admin account gets the machine, and often the network.

The IBM Cost of a Data Breach Report 2025 found the average US data breach costs $10.22 million, an all-time high for any region globally.

The remediation cost for breaches that originate through compromised endpoints is consistently higher when the affected user holds elevated system privileges. Revoking local admin rights does not eliminate the risk, but it significantly reduces what an attacker or an infected machine can actually do.

The Three Ticket Categories That Disappear

Malware infections and their cleanup

Most ransomware and many Trojan infections require admin-level permissions to install, disable security tools, and spread. A standard user account does not eliminate phishing risk, but it limits what malware can do after it lands. 

An infection on a standard account is typically contained to that user’s profile. On an admin account, the same infection can encrypt shared drives and require a full OS rebuild. 

A contained malware event might mean one ticket and thirty minutes of work. An admin-level infection often means several tickets and multiple hours of technician time.

Self-inflicted configuration breaks

Users with admin rights occasionally try to fix their own problems by changing settings, uninstalling applications, or modifying network configurations. When it goes wrong, IT inherits the result with little visibility into what changed. 

Standard user accounts remove this category of ticket almost entirely, because those changes are no longer possible without an elevation request.

Patch and compliance drift

Endpoints where users have admin rights tend to diverge from the managed baseline over time. 

Software installed outside the approved process does not receive updates through standard management tools. 

Devices accumulate inconsistencies that create additional work during vulnerability scans, audits, and compliance reviews. 

Revoking admin rights and enforcing managed software deployment closes this drift at the source.

But I Need to Install Things

Just-in-time elevation

The concern is legitimate. As a user on your network, you do occasionally need elevated access for specific tasks. 

The answer is not to restore permanent admin rights. It is just-in-time (JIT) elevation, where you get temporary elevated access for a defined task. The request is approved through an automated policy or by IT, and the elevation expires automatically once the task is complete.

This keeps users productive and IT informed. 

Every elevation request is logged. Unapproved actions do not happen silently. The volume and pattern of requests also becomes useful data in its own right, revealing exactly which tasks genuinely require escalation and which ones users were performing only because nothing was stopping them.

What standard users can already do

Standard accounts support normal application use, browser activity, printing, file access, and the vast majority of day-to-day tasks without any escalation at all. 

The friction you may anticipate is usually larger than the friction you actually experience once the change is made and a JIT process handles the edge cases.

What to Do Before You Flip the Switch

Ready to reduce your support ticket volume and tighten endpoint security for your team at the same time? 

Contact us or schedule a consultation to plan a least-privilege rollout that works for your team.

—

Featured Image Credit

This Article has been Republished with Permission from The Technology Press.