"We're backed up to the cloud" is one of the most dangerous things a NZ business owner can say. It signals a false sense of security built on a misunderstanding of what cloud synchronisation actually does. When ransomware encrypts files on a device, and those files are synced to OneDrive or Google Drive, the encrypted versions sync too — and the originals are gone.
CERT NZ and incident response firms consistently find that the backup situation is the biggest determinant of ransomware recovery outcome. Businesses with genuine offline backups recover without paying. Businesses whose only "backup" was a cloud sync service face a choice between paying and losing the data.
---
Why Cloud Sync Is Not a Backup
OneDrive, Google Drive, and Dropbox are synchronisation services. They keep a current copy of your files in the cloud, mirroring what is on your device. When a file changes on your device, the change synchronises to the cloud. When ransomware encrypts a file, the encrypted version synchronises to the cloud.
Most synchronisation services retain version history — you can roll back to a prior version of a file. This provides some recovery capability, but:
- Version history retention varies by plan — typically 30-180 days
- Rolling back thousands of files individually is not a practical recovery process
- Version history can be deleted by an attacker who has access to the cloud account — and in many ransomware incidents, the attacker has compromised the Microsoft 365 or Google account before deploying ransomware
- Volume shadow copies and local version histories are often deleted by the ransomware payload before encryption begins
Version history is a partial safety net for accidental deletion. It is not a ransomware recovery mechanism.
What an Actual Backup Looks Like
A backup that survives ransomware has three properties:
Isolation. The backup copy is not connected to the systems it backs up at the time of encryption. An external hard drive that is unplugged between backups, a tape that is removed from the drive, or a cloud backup service that uses a separate authentication credential that is not accessible from the production environment.
Immutability. The backup cannot be overwritten or deleted by ransomware or by an attacker with access to the production environment. Cloud backup services that support immutable or write-once storage (AWS S3 Object Lock, Azure Immutable Blob Storage, dedicated backup platforms with immutability) meet this requirement.
Testability. The backup has been restored successfully, recently, and the result has been verified. A backup that has never been tested is a hypothesis, not a recovery capability.
The 3-2-1 backup rule remains the standard: three copies of the data, on two different media types, with one copy offsite. The "offsite" copy in 2026 is typically an immutable cloud backup — but it must be a purpose-built backup service with its own credential, not a sync service using the same Microsoft 365 or Google account.
The Ransomware Groups Know Your Backup Situation
Modern ransomware operators conduct reconnaissance before deploying their payload. They look for:
- Connected backup drives that can be encrypted alongside production data
- Cloud backup credentials stored in the environment that can be used to delete backups before encryption
- Version history settings they can clear
- Shadow copies they can delete — most ransomware payloads include vssadmin delete shadows /all as a standard step
A backup that is always connected and uses credentials stored in the environment is a backup that ransomware operators will destroy before you have a chance to use it. The isolation and separate-credential requirements are not theoretical — they are responses to documented attacker behaviour.
Microsoft 365 Backup
Microsoft 365 includes some version history and retention capabilities, but Microsoft's shared responsibility model is explicit: Microsoft maintains platform availability, not your data backup. Microsoft 365 Backup (the paid add-on) provides immutable backup for Exchange, SharePoint, and OneDrive with point-in-time recovery. It is a material improvement over relying on version history alone.
For businesses that store critical data in Microsoft 365, either Microsoft 365 Backup or a third-party backup tool (Veeam, Dropsuite, AvePoint) with immutable storage is the appropriate control.
Testing Backups
The most common backup failure in a ransomware incident is not that the backup does not exist — it is that the backup cannot be restored at the speed or granularity needed for recovery.
Testing requirements:
- Restore a sample of files from the most recent backup — not just verify that the backup job completed
- Time the restoration process for a realistic recovery scenario — how long does it take to restore 100GB of file data?
- Confirm that database backups restore to a consistent state, not just that the backup file exists
- Test the restoration process when the primary IT person is unavailable — the person who knows how to restore it should not be the only person who knows
Quarterly restoration testing is the recommended cadence. Annual is the minimum. Monthly for businesses with high data change rates or significant ransomware exposure.
What Good Looks Like
A NZ SME with a defensible backup posture:
- Daily automated backup to an immutable cloud backup service with a separate credential
- Weekly backup to an external hard drive that is disconnected and stored offsite after each backup
- Microsoft 365 Backup or equivalent for cloud-hosted data
- Monthly tested restoration of a sample of files
- Documented recovery time objective — how long can the business operate without IT systems?
- Documented recovery point objective — how much data loss is acceptable?
The incident response steps if ransomware does deploy are covered in ransomware: what to do in the first 24 hours.
Practical Takeaway
- Audit your current backup setup — is it isolated, immutable, and tested?
- Stop treating OneDrive/Google Drive sync as a backup
- Set up a purpose-built immutable cloud backup with a separate credential
- Add Microsoft 365 Backup or a third-party equivalent for cloud data
- Keep at least one offline copy — external drive stored offsite after each backup
- Test restoration quarterly — actually restore files, do not just check the job log
- Document RTO and RPO and verify your backup setup can actually meet them
Start your free SecureAZ trial to train your team on backup hygiene, ransomware awareness, and the controls that mean you never have to make a payment decision.
External references: