Disaster Recovery Planning: A Practical ISO 27001 Guide

Share with

Contents

Disaster recovery planning is the work you do before an outage so that your systems, data and people can return to normal quickly after one. A power failure at a data centre, a ransomware attack, a failed database upgrade, a burst pipe above the server room - each of these stops work in much the same way. The difference between a two-hour disruption and a two-week crisis is usually whether someone wrote, tested and maintained a plan.

Disaster recovery planning answers three questions in advance: what must come back first, how fast it must come back, and who does what while it is coming back. It sits inside your wider information security management system and connects directly to backup design, incident handling and risk decisions. Treated as a one-time document, a disaster recovery plan ages badly. Treated as a live process, it becomes one of the most useful controls an IT team owns.

What Disaster Recovery Planning Covers

A disaster recovery plan is focused on technology. It deals with servers, applications, databases, network links, cloud tenants, identity services and the data inside them. Its job is to move IT services from a failed state back to a working state within an agreed time.

Three things sit at the centre of it:

The list of systems that matter, ranked by how badly their loss hurts the business
The recovery targets agreed for each one
The technical steps, access details and decision rights needed to carry out the recovery

Everything else in the plan supports these three.

Disaster Recovery Planning and Business Continuity

The two are related but not the same. Business continuity management covers the whole organisation: staff, premises, suppliers, cash flow and customer commitments. Disaster recovery planning is the IT chapter inside it.

A simple way to separate them: business continuity decides that order processing must keep running from a backup office; disaster recovery decides how the order management system, its database and its integrations get back online to make that possible.

Both need the same input, which is an understanding of what the business cannot do without.

Inputs You Need Before Writing the Plan

Asset and Dependency Mapping

Start with a current asset inventory and classification. List applications, the servers or cloud services they run on, the databases they read from, and the identity and network services they depend on.

Dependency mapping is where most plans quietly fail. Teams often document how to restore an application but not the order of restoration. If the application comes back before the directory service that authenticates it, the recovery stalls and the clock keeps running. Write the sequence, not just the steps.

Impact Analysis and Recovery Objectives

For each system, agree two numbers with the business owners:

Impact Analysis and Recovery Objectives

Recovery Time Objective (RTO): the longest acceptable time a service can stay down
Recovery Point Objective (RPO): the largest amount of data you can afford to lose, measured in time

An RPO of four hours means backups or replication must run at least every four hours. An RTO of two hours rules out restoring 3 TB from tape. These numbers are the bridge between what the business wants and what the infrastructure budget can deliver.

Tier your systems rather than giving everything the same target. A common split is critical (RTO under 4 hours), important (24 hours) and standard (72 hours). Feeding these tiers from your information security risk management work keeps the ranking defensible instead of political.

Recovery Strategy Options

Match the strategy to the tier:

Backup and restore: lowest cost, slowest recovery, suitable for standard systems
Pilot light: core components kept running in a second location, scaled up when needed
Warm standby: a scaled-down copy of the environment, ready to take load
Active-active: full redundancy across sites or regions, used where downtime is not acceptable

Cost rises sharply from top to bottom. Documenting why a system sits at a given tier protects the choice when someone questions the spend later.

Ready to keep your recovery data, tests and evidence in one place? Try Effivity for Free.

Free Trial →

What Goes Inside a Disaster Recovery Plan

A usable plan is short enough to follow under pressure. It should contain:

Scope and the systems covered, with tier, RTO and RPO for each
Activation criteria: who declares a disaster and on what evidence
Roles, deputies and contact details, including out-of-hours numbers
Step-by-step recovery runbooks per system, in dependency order
Location of backups, encryption keys, licences and configuration files
Communication plan for staff, customers, regulators and insurers
Criteria for declaring recovery complete and returning to normal operations

Store a copy outside the environment it protects. A plan saved only on the file server you are trying to restore is not a plan.

The activation link matters too. Most disasters begin as ordinary alerts, so your incident response plan should state the point at which an incident is escalated into a disaster declaration. Without that trigger, teams often spend hours troubleshooting a failure that should already have moved to recovery mode.

Testing the Disaster Recovery Plan

An untested plan is an assumption. Testing turns it into evidence.

Types of Tests

Walkthrough: the team reads the plan together and checks it for gaps. Low effort, good for new plans.
Tabletop exercise: a scenario is presented and the team talks through decisions and timings.
Component test: one system is restored to an isolated environment and checked.
Full simulation: services are failed over to the recovery site and run there.

Test at least annually, and after any major change to infrastructure or applications. Record the actual recovery time achieved against the RTO. That gap is the single most useful metric in disaster recovery planning, because it shows whether the target is real or aspirational.

When a test misses its target, run a root cause analysis rather than adjusting the target. Slow restores usually trace back to a fixable cause: undocumented credentials, missing runbook detail, or a backup that was never verified as restorable.

Pair the technical test with your emergency action plan where the scenario involves a physical event such as fire or flood, so the people side and the systems side are rehearsed together.

Disaster Recovery Planning Under ISO 27001

ISO/IEC 27001:2022 addresses this through Annex A controls, notably A.5.29 on information security during disruption, A.5.30 on ICT readiness for business continuity, and A.8.13 on information backup. Together they expect an organisation to plan for continuity of security controls, to prepare ICT for disruption based on defined objectives, and to back up and test information.

Certification bodies rarely ask for a perfect plan. They ask for a current one, evidence that it was tested, and records showing what happened afterwards. Before an ISO 27001 audit, make sure you can produce the approved plan with a version date, the last test report with results and timings, the corrective actions raised from it, and proof that backup restores were verified.

Weak points auditors flag most often are plans naming staff who have left, recovery targets never agreed with business owners, and backups that are monitored for completion but never tested for restoration.

Keeping the Plan Alive with Software

Disaster recovery planning generates records that need version control and follow-up: the plan itself, test schedules, test results, corrective actions and management review inputs. Spreadsheets handle this until the first audit, then start to break.

ISMS software keeps the plan under document control, schedules and logs tests, links findings to corrective actions with owners and due dates, and holds the evidence trail in one place. It also connects disaster recovery data to the risk register, so a failed test raises the residual risk rather than sitting in an email thread.

Want to see how your recovery plans, tests and evidence fit together in one system? Get a Free Personalized Demo.

Free Demo →

Frequently Asked Questions

Disaster recovery planning is the process of preparing to restore IT systems and data after an outage. It defines recovery targets, responsibilities and step-by-step recovery procedures.

RTO is how long a system can be down before the impact is unacceptable. RPO is how much data, measured in time, you can afford to lose.

Test the plan at least once a year, and again after any major infrastructure or application change. Record the actual recovery time achieved each time.

Yes, through Annex A controls covering ICT readiness, continuity of security controls and information backup. Auditors expect a current plan plus test records.

IT or infrastructure usually owns the technical runbooks, while business owners approve the recovery targets. Both roles should be named in the plan.

Share with