The question I ask during backup reviews
During most infrastructure reviews, I eventually ask the same thing. The answer tells me more than a screenshot of successful backup jobs ever will.
Most companies have backups. Most also have something offsite. The problem is that the backup console, storage repository, replication target, and cloud copy often trust the same directory. One domain administrator can reach all of them.
That design works until the administrator account is compromised. At that point the attacker does not need to break four different systems. They only need to become the person who already has permission to manage them.
Backups are part of the attack plan
Attackers target backup systems because working backups take away much of their leverage. A company that can restore its systems has far less reason to pay. Veeam's ransomware research has reported that backup repositories were targeted in roughly 96% of attacks, and in about three-quarters of those cases the attackers affected at least some of the repositories.
Veeam's 2026 Data Trust and Resilience research reports that about 90% of organizations believe they can recover from a cyber incident, but fewer than one in three ransomware victims fully recovered their data. The same research found that organizations using controls such as immutable storage and automated backup verification reported full recovery at more than twice the rate of organizations that did not.
Immutability does not guarantee an easy recovery. It does remove one of the simplest ways an attacker can make recovery impossible. What recovery looks like once an attacker succeeds is its own discipline; we wrote that sequence down in the ransomware recovery playbook.
Replication and snapshots are not immutable
These terms get mixed together constantly, and the difference is the whole point.
Ask one question: can any account in your environment shorten the retention period or delete the copy before it expires? If the answer is yes, the copy is not truly immutable. That applies to your internal team, your MSP, your storage administrator, and anyone else with elevated access. The control must still hold when the attacker is operating through a trusted account.
How the platforms lock it
Two platforms we deploy handle this well, in different ways. The mechanics are worth knowing, because the word "immutable" hides real differences in how the lock is actually enforced.
01 Pure SafeMode: the eradication timer
When data is deleted from a FlashArray it first enters an eradication-pending state. It is not destroyed immediately. The default timer is 24 hours. With SafeMode it commonly extends to 14 days, and up to 30 days on FlashArray, with longer options on FlashBlade. If an attacker deletes a volume, the data stays recoverable until the timer expires, which gives the operations team time to notice and intervene.
02 Pure SafeMode: off-box authorization
SafeMode retention cannot simply be shortened or disabled from the array console. The organization designates authorized contacts, at least two and up to five, and changes are verified through Pure Support. A stolen array password is not enough to remove the protection, and one rogue administrator cannot quietly disable it. The destructive action is separated from the person managing the array day to day.
03 NetApp SnapLock: tamperproof snapshots
Tamperproof snapshots use SnapLock technology to retain a snapshot for a defined period. The snapshot cannot be deleted before that period expires, including by an ONTAP administrator. That provides a fast local recovery point without leaving deletion authority in the hands of one administrator.
04 NetApp Multi-admin verification
Multi-admin verification adds approval requirements to sensitive ONTAP operations: deleting volumes or snapshots, or creating new administrator accounts. A compromised account may be able to request the action, but it cannot complete the action by itself. Autonomous Ransomware Protection adds another layer, watching for workload behavior associated with ransomware, including unusual encryption activity.
Pure and NetApp implement these controls differently, but the design goal is the same: one identity should never hold enough authority to destroy every usable recovery point.
Using the 3-2-1-1-0 rule
The traditional 3-2-1 backup rule is still useful, but it does not fully address ransomware. Veeam popularized the expanded 3-2-1-1-0 model.
The final two are where many backup designs fall apart. A company may have several copies across multiple locations, but every copy is still managed through the same identity system. Or the company has an immutable copy but has never completed a clean, timed restore from it.
A successful backup job only confirms that the system wrote data somewhere. It does not confirm that the business can recover its applications, databases, permissions, dependencies, and operations within an acceptable amount of time.
The operational work behind immutability
Buying the feature is the easy part. Keeping it correctly configured is ongoing work.
A lean internal IT team can manage all of this. The challenge is continuing to manage it after the original implementation project is over and the team has moved on to the next priority. That is one of the reasons we built our Backup as a Service offering.
ModernOps provides backup on enterprise storage with immutability included in the operating model. We design retention around the customer's RTO and RPO, maintain the required approval controls, and perform scheduled restore tests with documented results. Customers get an immutable backup design without needing to own and operate the storage platforms behind it. More importantly, someone remains responsible for keeping the design working month after month.
This article describes ModernOps services. The platform details and statistics above are based on vendor documentation and the public research listed in Sources. Validate all settings and capabilities against your own platforms and software versions.
The 60-second immutability check
Sources
Many companies assume Microsoft is backing up their Microsoft 365 tenant. Microsoft expects customers to understand where its responsibility ends. Field Notes No. 05 covers that gap.