Nearly every business we assess has backups. A much smaller number can tell us how long a restore takes, when it was last tested end to end, or whether the backups would survive an attacker who had already been in the network for a fortnight. Those three questions are the entire subject.
Immutable backup, because attackers target backups first
Modern ransomware operators do not encrypt and hope. They find the backup infrastructure, delete or corrupt it, and only then encrypt production — because a victim with working backups doesn't pay. If your backup system can be deleted with the credentials of a domain administrator, and an attacker has spent two weeks acquiring exactly those credentials, it is not a recovery capability.
Immutability changes that. Once written, a backup cannot be altered or deleted for its retention period — not by an administrator, not by us, not by an attacker holding valid credentials. It is the difference between a copy and an insurance policy.
Microsoft 365 is not backed up by Microsoft
This surprises people, and the misunderstanding is expensive. Microsoft guarantees the availability of the service, not the recoverability of your data from your own mistakes. Retention windows are short, and once a deleted mailbox or overwritten SharePoint library ages out, it is gone. Under the shared responsibility model, your data is your responsibility.
We back up Microsoft 365 — mail, OneDrive, SharePoint, Teams — separately from the tenant, so that a compromised account or a bad sync doesn't take your records with it.
Disaster recovery as a service
Backup gets your data back. Disaster recovery gets your business running. Those are different problems: restoring four terabytes to hardware you no longer have is not a recovery plan, it is a shopping list. DRaaS keeps standby infrastructure ready to run your critical systems in the cloud while the primary environment is rebuilt, which turns a multi-week outage into a manageable one.
The drill is the deliverable
An untested backup is a hypothesis. We schedule recovery drills, run them, time them, and write down what actually happened — including the parts that went badly, because those are the valuable findings. Drills routinely surface things no design review would have: an application whose licence is tied to hardware that no longer exists, a database whose restore order matters, a documented procedure whose only author left last year.
Better to discover that on a Tuesday in a rehearsal than during a live incident with the whole company watching.
Setting RTO and RPO honestly
Recovery time objective is how long the business can be down. Recovery point objective is how much work it can afford to lose. Both are business decisions rather than technical ones, and they cost money in proportion to how aggressive they are.
We work them out per system rather than as a single number, because the answers differ enormously. A file share can usually tolerate a day. A practice management system or a production line controller frequently cannot tolerate an hour. Sizing everything to the strictest requirement is how organisations end up paying for protection they don't need on systems that don't need it.
What this protects beyond ransomware
Ransomware gets the attention, but most recoveries we run are more ordinary: a failed storage array, a botched update, a departing employee who deleted a shared folder, a flood in a server room. The controls are the same. The frequency is much higher.
Can you state your recovery time for your most critical system, with confidence, right now?