Nicolas Blank | CTO | NBConsult | mail me |
Backup, disaster recovery, and operational resilience are often used interchangeably in boardroom conversations. However, they are three distinct disciplines. Each carries its own risk if organisations leave it unaddressed. Organisations that conflate the three are frequently the ones caught out when ransomware strikes.
Backup protects recoverable copies of information. Recovery defines how applications, identities, configurations and dependencies are rebuilt. Resilience determines whether the business can keep operating while all of that happens.
Every critical service needs an agreed recovery point objective, recovery time objective, restoration sequence and accountable owner. Without that, a recovery plan is just a hope. Confidence is not evidence. Organisations need tested processes that demonstrate whether their recovery capabilities will work when they need them most.
Beyond 3-2-1 – building for ransomware resilience
Best practice has traditionally started with the 3-2-1 rule. The rule requires three copies of data, on two different media, with one copy held off-site. In today’s threat environment, he argues that organisations need to extend this rule.
For modern ransomware resilience, I recommend extending this to 3-2-1-1-0: one copy must be offline or immutable, with zero unverified backup errors. Most importantly, a backup is only a backup when you have successfully restored it. Recovery tests must prove that the data is intact. They must also prove that the required recovery time objective can be achieved. Finally, the organisation must know how to perform the restore under pressure.
Blank points to research from Veeam’s 2026 Data Trust and Resilience study. The study found that nearly 90% of security leaders believed they could recover quickly following an attack. However, only 28% actually achieved a full data recovery after a ransomware incident.
Confidence is not evidence, but a tested restore is. The distinction matters because an organisation can feel prepared without having demonstrated that its recovery process works. Confidence is not evidence when teams have not tested their ability to restore critical services under pressure.
Designing backups to survive the attacker, not just the outage
Microsoft’s own ransomware guidance asks a pointed question of every organisation: are backups of the application, configuration and data available? It also asks whether organisations regularly verify those backups through restore exercises.
This framing matters because a recovery plan that restores files but cannot restore identity, application configuration or business operations remains incomplete. Backups have to be designed on the assumption that an attacker will actively try to find, encrypt, or delete them.
Organisations should use immutable or offline copies. They should also separate backup administration from production administration. Furthermore, they should protect backup accounts with phishing-resistant multi-factor authentication and privileged access controls.
Organisations must also ensure that compromised production credentials cannot modify retention policies or delete recovery points. Backup deletion and unusual administrative activity should themselves be treated and monitored as security events.
This discipline needs to extend to Microsoft 365 and other SaaS platforms. Organisations should apply the same rigour they use for on-premises infrastructure. Microsoft’s shared-responsibility model is clear that customers retain responsibility for their data, identities, configurations and data protection decisions, including when using SaaS services such as Microsoft 365.
Microsoft 365 Backup, or an appropriate third-party service, can protect Exchange Online, SharePoint and OneDrive data. Microsoft’s own platform uses append-only storage and immutable recovery points designed to resist malicious overwrite.
Where AI helps and where it can’t
Artificial Intelligence (AI) is increasingly being layered into backup and recovery operations. However, Blank is careful to frame its role. AI can improve a backup policy, but it cannot rescue a fundamentally weak one.
AI has several useful applications. These include detecting abnormal deletion or encryption patterns and identifying unexpected changes in backup size or duration. AI can also predict failed jobs and prioritise systems according to business impact. In addition, it can automate evidence collection from restore tests.
AI can also help model recovery scenarios. It can identify dependencies that traditional asset inventories have missed. However, AI recommendations must remain governed by documented retention requirements, recovery objectives and human approval. The danger is allowing automation to create a false sense of assurance. An AI dashboard reporting healthy backups is still not proof that the organisation can recover.
That distinction reinforces the central lesson. Confidence is not evidence when an organisation relies on dashboards instead of tested recovery outcomes. The final measure of readiness must remain a clean, timed and independently verified restoration of the business service. It should not be merely the successful completion of a backup job.
