ISO 27001 Disaster Recovery Sites: Selection, Testing and Evidence

Select and test an ISO 27001 disaster recovery site using impact, threat, dependency and recovery evidence—not an arbitrary distance rule or assumption.

There is no universal number of kilometres that makes a disaster recovery site safe. A second site can be far away yet share the same power corridor, identity service, cloud control plane, telecommunications route or administrator. It can also be close enough for a regional event to affect both locations.

For ISO/IEC 27001, the defensible question is not “How far away is the site?” It is “Can the recovery arrangement meet approved recovery needs under credible disruption scenarios?”

A recovery site is one possible control arrangement. Depending on the service, an organisation may use another office, colocation facility, alternate cloud region, warm environment, portable equipment, reciprocal arrangement or a combination. The standard does not mandate a particular site type or distance. The design should follow risk assessment, business requirements and selected controls.

Begin with business recovery needs

Do not select a site before understanding what must recover. Use the business impact analysis and service dependencies to define:

critical products and services;
maximum tolerable disruption;
recovery time objectives;
recovery point objectives;
minimum acceptable operating capacity;
priority and sequence of recovery;
people, premises, technology, information and supplier dependencies; and
legal, regulatory and contractual obligations.

The business impact analysis guide explains how impact decisions support availability controls. The separate RTO and RPO article helps prevent those objectives from becoming unsupported numbers.

A recovery site decision should be traceable to these requirements. If a service must resume within four hours, a cold site requiring two days of equipment installation is not adequate, regardless of distance.

Define credible disruption scenarios

Evaluate scenarios that could affect the primary environment and the proposed recovery arrangement. Examples include:

fire, flood, severe weather or structural damage;
regional loss of power or telecommunications;
civil disruption or restricted physical access;
ransomware or destructive administrative action;
cloud-region or provider control-plane failure;
identity, domain-name or certificate-service outage;
supplier failure;
loss of specialist personnel;
corruption replicated to the alternate environment; and
simultaneous demand from several business units or customers.

Avoid designing only for loss of a building. Many modern recovery failures arise from shared logical dependencies rather than geography.

For each scenario, record the assumed event, affected assets, duration, warning time, dependency failures and recovery strategy. Challenge optimistic assumptions through exercises and technical tests.

Map common-mode dependencies

Two sites are not independent if one failure can disable both. Build a dependency map that covers at least:

Dependency	Questions to test
Power	Are the sites on separate utility feeds, and how long can backup power operate?
Connectivity	Do carriers use physically diverse routes and exchanges?
Identity	Can administrators and users authenticate if the primary identity service fails?
Administration	Are recovery credentials, devices and staff available independently?
Cloud	Are regions, accounts and control services sufficiently separated?
Data	Could corruption or malicious deletion replicate to the alternate copy?
Suppliers	Does the same provider support both sites with the same constrained resources?
People	Can staff reach or operate the alternate environment during the scenario?
Security	Are keys, certificates, monitoring and response capabilities available?
Capacity	Can the alternate environment handle minimum required demand?

This analysis often matters more than straight-line distance. Document which dependencies are intentionally shared, the residual risk and any compensating safeguards.

Choose the recovery model

Cold site

A cold site provides space and basic facilities but needs equipment, data and configuration before operation. It may suit lower-priority services with longer recovery objectives. Evidence should show procurement or mobilisation arrangements, installation time and tested setup instructions.

Warm site

A warm site has some infrastructure and replicated components but requires activation and synchronisation. It can balance cost and recovery speed. Testing should prove configuration currency, data restoration and achievable capacity.

Hot site

A hot site maintains a ready or near-ready environment with frequent data replication. It can support demanding objectives but may also replicate errors or compromise rapidly. Strong isolation, controlled failover and recovery testing are important.

Cloud-based recovery

Cloud services can provide geographic options and automated deployment. They do not remove customer responsibilities. Review identity, account separation, quotas, region-specific dependencies, backup immutability, provider commitments and the ability to operate when primary administrative paths fail.

Reciprocal or shared arrangements

Another business unit or partner may provide space or capacity. Confirm priority when both parties are affected, security boundaries, resource availability, access authority and test rights. An untested promise is weak evidence.

A hybrid design may use different models for different services. The correct choice follows business impact and risk rather than a single corporate rule.

Evaluate candidate sites with weighted decisions

Define evaluation criteria before choosing a provider or location. Weight the criteria according to business needs, then preserve the assessment and approval.

Useful criteria include:

scenario independence;
demonstrated recovery time and data currency;
capacity and scalability;
connectivity and access;
physical and environmental protection;
security monitoring and access control;
supplier capability and financial resilience;
contractual service levels and test rights;
data location and legal requirements;
staff safety and accessibility;
activation and operating cost; and
exit, migration and return-to-primary arrangements.

A risk score can support comparison, but it should not conceal assumptions. Use the risk score calculator as an aid, then record the qualitative rationale and accountable decision.

Design activation and authority

A technically sound recovery site can still fail if nobody knows who may declare a disaster or start failover.

Define:

activation triggers and decision criteria;
authority to declare and escalate;
technical and business recovery leads;
supplier contacts and invocation steps;
communications channels independent of affected systems;
safety and access arrangements;
recovery sequence and dependencies;
validation before service release;
customer and regulator communication duties;
fallback if recovery fails; and
criteria for returning to normal operation.

The business continuity activation guide provides a fuller governance model.

Protect the alternate environment

A recovery environment is not allowed to be a weaker copy of production. Apply risk-appropriate controls for:

privileged access and emergency credentials;
encryption and key availability;
network segmentation;
logging and monitoring;
vulnerability and patch management;
secure configuration;
malware protection;
physical access;
media handling;
data retention and deletion; and
supplier access.

Controls may operate differently during an emergency, but any deviation should be pre-authorised, limited and recorded. Recovery urgency should not create an uncontrolled route around security.

Test progressively

A credible testing programme moves beyond discussion.

Document review: Confirm contacts, dependencies, instructions and approvals.
Tabletop exercise: Walk decision-makers through a realistic scenario.
Component test: Restore data, activate connectivity or validate emergency credentials.
Technical recovery test: Start systems in the alternate environment and validate integration.
Business service test: Confirm users can perform priority transactions at required capacity.
Failover and return test: Where risk permits, prove controlled transition and restoration.

Not every organisation can perform a full production failover frequently. The test scope and cadence should be risk-based, and exclusions should be explicit. Rotate scenarios so the programme tests different failure modes.

The official NIST contingency-planning guidance provides practical background on contingency requirements and priorities. ISO 22301 provides a broader business continuity management framework; the official ISO 22301 overview explains its purpose.

Retain evidence that answers audit questions

Implementation evidence can include:

approved business impact analysis and recovery strategy;
site-selection assessment;
architecture and dependency diagrams;
supplier due diligence and contracts;
recovery plans and responsibility assignments;
security design and configuration records; and
acceptance-test results.

Operating evidence can include:

replication and backup monitoring;
site access reviews;
capacity and environmental reports;
maintenance records;
exercise plans, attendance and observations;
measured recovery times and achieved data points;
incident or activation records; and
corrective actions with retest results.

Evidence should show both capability and currency. A successful test from three years ago may not support an environment that has since changed substantially.

Audit sampling that reveals weakness

Select samples based on criticality and variation. Include a high-impact service, a service with complex dependencies and one that changed recently. Trace each from business requirement to recovery design, test result and corrective action.

Ask:

Is the recovery objective approved and evidence-based?
Does the design address relevant scenarios?
Which dependencies are shared with the primary environment?
Can required people and credentials operate independently?
Did the test validate the business service, not just server startup?
Were recovery time and data loss actually measured?
Were exceptions and failed steps corrected and retested?
Can the organisation return safely to normal operation?

Pass, partial and fail examples

Pass: The organisation links recovery objectives to impact analysis, maps common dependencies, tests the alternate environment with representative users, measures outcomes and closes findings.

Partial: The environment starts successfully, but the exercise excludes identity failure and does not measure whether the approved recovery time was achieved.

Fail: Management selected a remote site using an arbitrary distance rule, shares critical dependencies with the primary site and has no recent operating test.

Make recovery evidence a living control

Reassess the arrangement when services, architecture, suppliers, office locations, legal requirements or impact tolerances change. Include recovery readiness in management reporting and track overdue corrective actions.

The objective is not to own a second location. It is to demonstrate that priority services can be restored securely, at the required capacity and within approved limits when credible disruptions occur. Use the ISO 27001 readiness checker to identify missing recovery and audit evidence before relying on the arrangement.