What immutability actually means for ransomware

“Immutable” has become a marketing word, which is a shame, because it describes the single most important property a protected copy can have. If your second copy is immutable, ransomware has nothing to encrypt that stays encrypted, and a malicious admin has nothing to delete that stays deleted. If it is not, you have a backup that an attacker can simply destroy along with everything else.

Immutable means WORM, enforced below the admin

True immutability is write-once, read-many (WORM), enforced by the storage layer itself — not by a policy that an administrator can toggle off. In practice that means Object Lock in Compliance mode:

• Once written, an object cannot be overwritten or deleted until its retention date passes.
• Retention can be extended, never shortened.
• No one can override it early — not the account owner, not the storage vendor, not someone who has stolen admin credentials.

That last point is what separates a defence from a false sense of security. “Governance mode” locks that a privileged user can lift are not the same guarantee. For ransomware resilience, you want Compliance mode.

Three questions to ask any vendor

1. Is the lock in Compliance mode, and who can lift it? If the answer is “an admin can,” it is not ransomware-proof.
2. Is the copy in a separate trust domain? If it is governed by the same admins as the tenant it protects, one compromise takes both.
3. Is restore verified? You should get back exactly what was stored — checked against a hash recorded at protection time.

CloudOnBox answers all three the same way: immutable on write, in storage with keys and residency you control, verified on every restore. Immutability is not a nice-to-have. It is the whole point.

See it in action — book a demo.