What Goes Into an IT Disaster Recovery Policy

An IT disaster recovery policy sets out how your organisation gets its systems and data back after a serious failure: a ransomware attack, a server failure, a cloud outage, a fire or a flood. It decides what is restored first, how quickly, from which backups and by whom.

Most businesses only find out whether their recovery plan works on the worst day of the year. A written policy, tested before it is needed, is what turns a crisis into an inconvenience.

We write IT disaster recovery policies from £65 per document. This page explains what a good one contains.

Disaster Recovery Policy at a Glance

Element	What it settles
Scope and critical systems	Which systems and data the policy covers, in priority order
Recovery time objective (RTO)	How long each system can be down before the impact is unacceptable
Recovery point objective (RPO)	How much data, measured in time, you can afford to lose
Backups	What is backed up, how often, where, and how backups are protected
Roles	Who declares a disaster, leads recovery and communicates
Testing	How often restores and full recovery are tested, and how results are recorded
Review	When the policy and recovery plans are updated

Disaster Recovery and Business Continuity

Business continuity is the wider plan for keeping the organisation running through any disruption, including loss of staff, premises or suppliers. Disaster recovery is the IT part of it: restoring the technology the business depends on.

The two need to agree. If the business continuity plan says customer orders must resume within four hours, the disaster recovery policy has to deliver the systems that make that possible. Our page on business continuity plans covers the wider plan.

Recovery Time and Recovery Point Objectives

The recovery time objective is the maximum time a system can be unavailable. The recovery point objective is the maximum period of data you can afford to lose, which sets how often you back up.

If the RPO for your finance system is one hour, backups or replication must run at least hourly. If the RTO is four hours, you need a way to restore within four hours, which a backup held only on tape in another city may not provide.

Set RTOs and RPOs system by system, with the business owners of each system, not by IT alone. Then check the technology can actually meet them.

Backups

Backups are the foundation of recovery. The NCSC's guidance on backing up data recommends identifying what is essential, keeping backups separate from your main systems, and making backing up part of everyday business.

• What. Business data, system configurations and the information needed to rebuild, such as licence keys and network settings.
• How often. In line with the RPO for each system.
• Where. At least one copy held separately from the main network, so an attack or fault cannot reach it.
• Protection. Encrypted, access-controlled, and protected against deletion or alteration.
• Retention. How long each backup is kept, matched to your data retention schedule.

Cloud services need the same thinking. Many software-as-a-service providers keep your data available but do not promise to restore what you delete or what ransomware encrypts, so check the contract and back up separately where needed.

Ransomware

Ransomware is now the most likely reason a small or medium business will invoke its disaster recovery plan. Attackers often look for and destroy backups before encrypting systems.

The policy should require at least one backup that is offline or immutable, and a tested process for rebuilding systems from clean images. The NCSC's ransomware guidance explains why offline backups matter and how to recover safely.

Recovery from ransomware also needs a decision process: who decides whether systems are safe to restore, how the infection is cleared first, and how evidence is kept. That links the disaster recovery policy to your incident response policy.

Suppliers and Outsourced IT

Most small and medium businesses rely on an IT support company or managed service provider for recovery. The policy should say what the supplier is contracted to do, how fast, and how you will reach them out of hours.

Check the contract against your RTOs. A support contract that promises a response within one working day cannot deliver a four-hour recovery, however good the backups are.

Ask your supplier for evidence that they test restores of your data. A backup job that reports success is not proof that the data comes back. Our page on policies for IT companies and MSPs covers what a well-run provider should have in place.

Working From Anywhere

Recovery does not always mean restoring the office. Laptops, cloud email and remote access may let staff keep working while core systems are rebuilt, provided accounts and devices are themselves secure.

Write down how staff will work during a recovery: which systems they can use, how they will be told, and what they must not do, such as storing customer data on personal devices as a workaround.

Roles and Responsibilities

Name who can declare a disaster, who leads the technical recovery, who makes business decisions about priorities, and who communicates with staff, customers and suppliers. Give each role a deputy.

Keep contact details for key staff, IT suppliers, your cloud providers and your insurer somewhere you can reach when your own systems are down. A printed copy and a copy in a separate cloud account are common.

The Recovery Plan

The policy sets the rules; the recovery plan sets the steps. For each critical system, the plan should list the recovery order, the technical steps, the people involved, and how to check the system is working correctly before users return.

Include dependencies. A finance system cannot come back before the network, identity services and the database it runs on.

Testing

An untested plan is a guess. Test restores of individual files and systems regularly, and run a fuller recovery exercise at least once a year.

A tabletop exercise, where the team talks through a realistic scenario, is a low-cost way to find gaps in roles and communication. Technical tests prove that backups restore and that RTOs are achievable.

Record each test, what failed and what was changed. Auditors and insurers will ask for that evidence.

Legal and Standards Links

Article 32 of the UK GDPR requires appropriate security for personal data, including the ability to restore its availability and access in a timely manner after a physical or technical incident, and regular testing of security measures. A disaster recovery policy is part of how you meet it.

ISO 27001 includes controls on ICT readiness for business continuity, information backup and redundancy. Our ISO 27001 documents list shows where disaster recovery fits in the documentation set.

Cyber Essentials focuses on preventing common attacks rather than recovering from them. The two work together: our Cyber Essentials checklist covers the prevention side, and a disaster recovery policy covers what happens if prevention fails.

Regulated Sectors

Some organisations face specific resilience rules. FCA-regulated firms must identify important business services and stay within impact tolerances, operators of essential services fall under the NIS Regulations 2018, and managed service providers are expected to come into scope of the planned Cyber Security and Resilience Bill. Our guide to the Cyber Security and Resilience Bill for MSPs covers the latter.

Reviewing the Policy

Review the policy at least once a year, after every test or real incident, and whenever you change a critical system, move to a new cloud provider or change IT supplier.

Check the contact list every quarter. Out-of-date phone numbers are one of the most common reasons recovery starts slowly.

Common Gaps We Find

• RTOs and RPOs set by IT without input from the business.
• No backup held offline or protected from deletion.
• Backups that have never been test-restored.
• Cloud services assumed to be backed up by the provider.
• Recovery steps that depend on systems that will be down.
• No link between disaster recovery and incident response.

Disaster Recovery Policy and Procedure Writers

We write IT disaster recovery policies and recovery plans built around your systems, suppliers and risk, with RTOs and RPOs agreed with your business leads. They sit within our wider IT security policies service.

If you already have a plan, our policy review service checks it against ransomware risk, your cloud services and current NCSC guidance. Get a quote to start.