Which systems and data fall outside your disaster recovery scope?

A disaster recovery scope is the defined boundary of what an organisation can restore, using which recovery method, within which agreed recovery objectives. Anything not mapped to an owner, recovery method, retention requirement and restoration test should be treated as outside scope or subject to confirmation, rather than assumed to be recoverable.

Scope is not limited to data files. A system may depend on identity services, databases, network configuration, encryption keys, licences, certificates, application settings and specialist hardware. If one of these dependencies is absent from the recovery design, restoring the main application may not make it usable. A sound review therefore considers the complete service chain rather than checking whether a backup job has completed.

Common categories that may fall outside an agreed disaster recovery scope include:

• Non-production environments: development, testing, demonstration and training systems may be excluded where they can be rebuilt from source code or standard configuration. This should be documented, particularly if test environments contain live customer or operational data.
• Temporary and generated information: caches, working files, reports that can be regenerated, processing queues and other short-lived data may not be retained. The business should confirm that recreating them will not affect financial records, compliance or customer service.
• Obsolete or dormant information: historic archives, duplicate datasets and records beyond the agreed retention period may sit outside the recovery set. Exclusion must not conflict with legal, contractual or regulatory retention duties.
• Specialist operational technology: machinery controllers, building-management systems, telephony equipment, warehouse devices and other technology linked to physical operations may require separate recovery arrangements. A standard server backup will not necessarily restore the firmware, configuration or physical equipment on which these systems depend.
• Infrastructure dependencies: domain services, authentication, DNS, network routing, firewalls, certificates, encryption keys and software licences can be omitted when scope is defined only around application servers. Their recovery requirements should be recorded separately or included as prerequisites.
• Custom software and integrations: bespoke applications may require source code, build instructions, databases, interface credentials and specialist knowledge. An image of the hosting server may not be enough to recreate an integration with a supplier, payment service or internal system.
• Data held under another organisation’s responsibility: a contract may assign recovery to a supplier, parent company, hosting provider or software publisher. This is not the same as proving that the data is recoverable. The responsible party, service commitment and evidence of testing should be recorded.
• Information subject to access restrictions: encrypted, privileged or legally restricted data may be backed up but unavailable to the recovery team without the relevant keys, permissions or approvals. Access arrangements form part of the recovery scope.

There is also a difference between an item being excluded and an item being conditionally recoverable. A conditionally recoverable system might depend on a replacement device, a valid software licence, a supplier’s involvement, a particular version of an application or a manual reconstruction step. These conditions should be visible in the plan, with an owner responsible for meeting them.

The scope should also state what the service does not restore. For example, a technical recovery may return a database to an available state without correcting corrupted records, recreating a lost business process, investigating the cause of an incident or validating every transaction. Data cleansing, application reconfiguration and operational decisions may remain the responsibility of internal teams or specialist suppliers.

A practical scope document normally records each system or dataset, its business owner, location, dependencies, recovery priority, recovery point objective, recovery time objective, retention period, backup or replication method and latest test result. It should identify whether the item is included, excluded or conditional, and explain the reason. This prevents assumptions such as treating a successful backup as proof that the full service can be restored.

Review the exclusions whenever the organisation adopts a new application, changes supplier responsibilities, introduces new compliance requirements, retires infrastructure or changes its recovery objectives. A recovery exercise should include enough of the surrounding dependencies to reveal whether an apparent exclusion creates a material gap. S2 Technology Group can help businesses assess these boundaries and align disaster recovery arrangements with their wider IT and security requirements.