Disaster Recovery Policies, Myths and Gaps

Disaster recovery assumptions build up over time, and they’re rarely questioned until an incident puts them to the test.

A written disaster recovery policy is assumed to mean the organisation is prepared. A cloud migration is assumed to bring disaster recovery with it. A nightly backup job is assumed to cover whatever data threat happens next. Each one of these assumptions, particularly when made together, could leave real gaps.

In this blog, we look at some of the most common disaster recovery myths we encounter, and what the reality looks like once each one is tested.

A written disaster recovery policy means you're prepared

A disaster recovery policy and a disaster recovery plan serve different purposes, even though the terms are often used interchangeably. A policy sets out the principles and objectives, such as responsibilities and recovery targets. A plan is the detailed, operational document that puts those principles into action, including step-by-step procedures during recovery and any dependencies that need to be considered. This blog focuses on the policy level and the assumptions that can build up around it.

A disaster recovery policy sets out what should happen in the event of a disruption, who’s responsible, and the recovery targets involved. It’s a necessary foundation, and many organisations will have one, in some form, whether that’s a complete written plan or a less formal document.

What it doesn’t do is prove that any of it works. A document can specify a four-hour recovery time objective (RTO) without anyone having confirmed that four hours is achievable with the infrastructure and processes currently in place. It can also name individuals as responsible without confirming they still hold that role or know what’s expected of them.

Policies can also be written once and often left untouched for years, while the environment they describe keeps changing underneath them. A document drafted eighteen months ago may still reference infrastructure, contacts and dependencies that no longer match what’s actually in production, and nobody necessarily notices until it is needed.

A policy is the starting point for disaster recovery, not the proof of it. The gap only becomes visible once recovery is actually attempted, which is exactly why structured testing exists.

Our blog ‘Creating an IT Disaster Recovery Strategy: From Document to Capability’, highlights what should be covered in a policy, in more detail.

The cloud automatically includes disaster recovery

Depending on your environment, moving infrastructure to the cloud could improve resilience in a number of different ways, including fewer single points of hardware failure and more built-in redundancy than a single on-premises site. Because of these benefits, it's easy to assume that resilience also extends automatically to disaster recovery.

In most cases, a cloud provider is responsible for platform availability, and the customer remains responsible for their own data, configuration and recovery capability, under what's commonly called the shared responsibility model. The National Cyber Security Centre's (NCSC) guidance on cloud security sets this division out clearly, and it holds whether the workload sits in Microsoft Azure, AWS, or a Software as a Service (SaaS) platform such as Microsoft 365.

Knowing where that division falls is the first step in building a disaster recovery strategy that’s fit for purpose.

SaaS platforms like Microsoft 365 handle everything

Business-critical operations increasingly run on SaaS platforms, and many assume that a platform handling your data also protects it, but this often isn’t the case.

Microsoft 365 is a great example of the Shared Responsibility Model. Microsoft's own services agreement recommends that customers back up their content using third-party services. Native features such as recycle bins and retention policies are designed for short-term recovery and compliance, not for the kind of independent, long-term, point-in-time restoration that disaster recovery planning requires.

The practical effect is a gap between platform availability and data recoverability: systems may be accessible, but an organisation may still be unable to restore its own data or configuration in line with its requirements.

If we have backups, we have disaster recovery

This is one of the most persistent misconceptions in IT planning, largely because the two disciplines are often discussed in the same breath. Backups preserve copies of data. Disaster recovery restores an entire operating environment, including infrastructure, applications, identity and network, to a working state within a defined timeframe.

Backups can support a form of recovery, but only as far as the infrastructure behind them allows. Without a secondary site to restore into, a backup is just a copy sitting wherever it was written, which does little to help if the primary environment itself is unavailable. With an offsite or secondary data centre, that same backup offers an alternative path back to operation if the primary site is compromised, because there’s somewhere to restore it.

What’s often labelled Disaster Recovery as a Service (DRaaS) can mean different things depending on what sits behind it. A true DRaaS setup has standby hardware and VM replicas ready to invoke, so failover happens in minutes rather than requiring a full rebuild from backup data. A backup-based approach, even with a secondary site, still means restoring from scratch when something goes wrong, which takes considerably longer.

An organisation can hold years of reliable backup restore points and still be unable to resume operations within an acceptable window, because recoverability depends on sequencing and testing as well as intact data, and on the infrastructure waiting at the other end.

We cover this distinction in full in why backup and disaster recovery are not equal.

Replication is the same as backup

Replication and backup both create copies of data, but they're built for different purposes. Replication maintains a near-live copy of a workload in a secondary location, ready for failover if the primary becomes unavailable. It's fast, but it typically holds only the most recent state - if data is corrupted or deleted, that change can replicate across just as quickly as a legitimate one.

Backup creates distinct, point-in-time restore points that can be rolled back to a moment before something went wrong. Most organisations need both: replication for workloads where downtime is the priority to avoid, and backup for the data-integrity protection replication alone doesn't provide.

DR testing is a once-a-year tick-box

Annual testing made sense when IT environments changed slowly. Most UK mid-market organisations now operate across cloud, on-premises and SaaS infrastructure that changes continuously, often outside the visibility of a single annual review.

Between one test and the next, a lot can move: cloud workloads get migrated or scaled, new SaaS tools get adopted without going through formal change control, staff join and leave with different levels of system access, and firewall rules or network configurations get amended to support a new integration.

None of this needs to happen all at once. It builds up steadily, and each change is a small, reasonable decision taken on its own, and a test performed twelve months ago describes an environment that, in many cases, no longer exists in quite the same form. 

The practical risk isn’t that the previous test was wrong; it’s that its result no longer tells you anything reliable about the environment you’re actually running today.

We explore this in detail in 'how often should you test your disaster recovery strategy', including why testing frequency is better treated as a risk-based decision than a fixed date in the calendar.

Disaster recovery is purely an IT problem

Disaster recovery testing is also increasingly a board-level issue, which brings us to the final myth.

Recovery time affects revenue, customer commitments and regulatory obligations as much as it affects infrastructure. Organisations need to be able to restore access to personal data in a timely manner after an incident, and cyber insurance questionnaires increasingly ask specific questions about backup architecture and recovery testing.

Setting recovery objectives, defining acceptable downtime, and deciding how much investment a given level of resilience justifies are commercial decisions that belong with the board as much as with IT. Treating disaster recovery as an infrastructure task alone is itself one of the more consequential disaster recovery myths.

Where this leaves your disaster recovery policy

Each of these misconceptions is understandable for a fast-paced organisation, as they're the natural result of disaster recovery being complex, with the cost of getting it wrong rarely visible until an incident makes it so. Closing the gap between assumption and capability starts with knowing where your own environment currently stands against reality.

If you'd like help assessing where your organisation sits today, our engineers are happy to talk through your current disaster recovery policy and what testing it would actually reveal. For the wider picture on recovery environments, objectives and provider models, read our strategic guide to disaster recovery services.