Most NZ businesses that believe they have good backups discover, during a ransomware event, that their backups are encrypted too. Or that their restoration process takes two weeks. Or that the backup didn't include the critical system they need first. Here's what makes a backup ransomware-proof.
Having a backup strategy and having a ransomware-proof backup strategy are two different things. The difference comes down to three properties: immutability, isolation, and tested recovery.
1. Immutability: Backups That Cannot Be Encrypted
Modern ransomware is designed with backup awareness. Before deploying encryption, ransomware operators spend days or weeks in a compromised network — mapping the environment, identifying backup systems, and deleting or encrypting backups first to prevent recovery. If your backups are on network-attached storage that's accessible from the Windows network, a connected external drive, or a cloud sync service (OneDrive, SharePoint) that syncs the encrypted files over the originals — your backups will be encrypted along with everything else.
Immutable backups are backups that cannot be overwritten, deleted, or modified by anyone — including an attacker with admin credentials. True immutability requires either: an air-gapped backup that is physically disconnected from the network after each backup run, or a cloud backup service with object lock (write-once, read-many) storage where not even the backup admin can delete backup data within the retention window.
Optimyze uses backup platforms with object lock storage for all managed backup clients. The backup data is written to cloud storage with a retention lock that prevents modification or deletion for the configured retention period — regardless of what happens to the source systems or the backup admin credentials.
2. Isolation: Backups on a Separate Identity Plane
Immutable storage is necessary but not sufficient if the backup admin account is compromised. A savvy ransomware operator who has obtained admin credentials for your Microsoft 365 tenant can — if the backup service uses the same identity — disable backups, change retention settings, or delete backup data before deploying ransomware.
Backup systems should use dedicated service accounts with credentials that are completely separate from your main business identity infrastructure. The backup admin account should not be a member of any business Active Directory or Entra ID, should use a strong unique password stored offline, and should have no other access to business systems.
3. Tested Recovery: Knowing It Works Before You Need It
A backup that has never been tested is not a backup — it's a hope. The only way to know a backup will restore successfully is to test the restoration. This means periodically restoring data from backup to a test environment and confirming that restored files are complete, readable, and match the expected state.
Testing should also cover Recovery Time Objective (RTO) — how long the restoration process actually takes. A backup that theoretically contains all your business data but takes three weeks to restore provides very different operational resilience than one that can be restored within four hours. Knowing your RTO before an incident means you can make informed decisions about business continuity during recovery.
Optimyze schedules quarterly backup restoration tests for all managed backup clients, providing a test report confirming restoration success, file integrity, and measured RTO.
Three questions to answer about your backup right now: Can it be encrypted by ransomware? Are the admin credentials part of the same identity system the ransomware could compromise? When did you last test a full restoration?
