6 Disaster Recovery and Business Continuity

Continuity and recovery

Cyberattacks, equipment failures, power outages, and facility damage can interrupt essential operations. Business continuity is the organization's ability to continue or resume critical work during a disruption. Disaster recovery (DR) focuses on restoring information systems, infrastructure, and data, and a DR plan supports business continuity by explaining how technology services will be recovered.

Assess recovery requirements

Begin recovery planning with a Business impact analysis (BIA). It identifies critical business processes, the systems and people they depend on, and how the effects of interruption change over time.

Consider dependencies such as applications, identity services, networks, facilities, staff, vendors, and data. Rank processes by importance and determine which temporary workarounds, such as manual procedures, are practical.

The BIA helps establish recovery requirements:

• Recovery time objective (RTO): the target maximum time to restore a system or process after disruption.

• Recovery point objective (RPO): the maximum acceptable amount of data loss, expressed as time. An RPO of four hours means the organization aims to restore data to a point no more than four hours before the disruption.

• Maximum tolerable downtime (MTD): the longest interruption the organization can withstand before the impact becomes unacceptable.

Set objectives for business processes and their supporting systems, rather than choosing them solely within IT. For example, if order processing must resume within eight hours and can tolerate at most one hour of lost transactions, its targets might be an eight-hour RTO and a one-hour RPO. The backup schedule and recovery design must be capable of meeting those targets.

Develop the recovery plan

Turn recovery requirements into clear actions. A useful DR plan identifies:

1. Activation and authority: who can declare a disaster, activate the plan, and approve recovery priorities.

2. Roles and contacts: response team responsibilities, contact methods, and escalation paths, including relevant vendors.

3. Recovery priorities and dependencies: which systems must be restored first and what each requires. For example, network connectivity and identity services may be needed before business applications.

4. Recovery procedures: step-by-step instructions for rebuilding or switching systems, restoring data, checking security, and validating that services work.

5. Communication and workarounds: how staff, leadership, customers, and suppliers will receive updates, and how critical work can continue while systems are unavailable.

6. Return to normal operations: how recovered services are transitioned back, data is reconciled, and temporary arrangements are closed.

Make procedures specific enough to follow under pressure. Review them when systems, personnel, vendors, or business needs change, and keep accessible copies securely outside systems or facilities that could be affected. Contingency planning includes requirements analysis, recovery strategies, plan development, testing, and maintenance.

Protect and verify backups

Backups need to be recoverable and protected from the event that damages production systems. Back up data and the system information needed to rebuild services, including configurations, software, and relevant documentation. Set backup frequency according to the RPO, and protect backup confidentiality, integrity, and availability.

Use access controls and encryption where appropriate. Keep copies isolated from ordinary network access, such as offline or otherwise segmented copies, so an attacker who compromises production systems cannot readily alter or delete every backup. Monitor backup jobs, protect recovery credentials, and retain copies in a separate location when the recovery design requires it.

A successful backup job alone does not prove that data can be restored. Verify backup integrity and test retrieval and restoration. Offline, encrypted backups and regular recovery testing can help reduce ransomware risk.

Test recovery and improve the plan

Exercises reveal whether the plan, people, facilities, and backups can meet stated objectives. Use different kinds of tests:

• Tabletop exercise: participants discuss a scenario and their decisions without changing systems.

• Walk-through: responders follow documented steps and identify gaps or unclear instructions.

• Technical restoration test: restore selected data or systems in a controlled environment and verify their integrity and operation.

• Full recovery exercise: recover services at an alternate environment or site. Use carefully controlled scenarios to avoid harming live operations.

Measure actual recovery time and the age of restored data against the RTO and RPO. Check that essential dependencies work, staff can access procedures, and recovered services are secure and usable. Record findings, assign corrective actions, update the plan, and test again. Restoration tests can sample backup information to confirm that selected functions operate as intended.