Business continuity starts before disruption

Continuity is a business responsibility

A technology recovery plan is useful only when it supports the work the organization needs to sustain. Begin with essential services, the consequences of interruption and the people able to decide priorities. Include suppliers, communications and manual alternatives alongside systems.

This framework is a practical planning aid. Recovery targets should follow business impact and the actual dependencies of the environment. A document or a completed backup job is not, by itself, evidence that a service can be restored.

Know what must be recovered first

Map each critical activity to applications, data, identity services, connectivity and external providers. Agree a recovery time objective for restoring service and a recovery point objective for the targeted point in time of recovered data.

NIST’s Contingency Planning Guide describes business impact analysis, recovery strategies, exercises and maintenance. Its guidance is useful context for structuring a plan, although the organization must determine its own obligations and operating requirements.

• Reference: NIST Contingency Planning Guide

Connect detection to an authorized response

An alert should lead to an accountable decision. Define who assesses impact, who can isolate a service and who communicates the decision. Include a route for staff to report unusual behavior when monitoring does not detect it.

• Document escalation contacts and an alternative communication channel.
• Define authority to suspend or isolate affected services.
• Record the information needed for investigation and subsequent review.
• Test the response when a key person or supplier is unavailable.

For an illustrative incident affecting a customer portal, the first question may be whether the issue concerns availability, data integrity or unauthorized activity. The response and recovery sequence will differ. A generic “restart everything” instruction leaves that decision unresolved.

Protect the ability to restore

Recovery depends on access to usable data and an environment that can safely receive it. Consider how backups, administrative access and recovery infrastructure are separated from the failure affecting production.

Test restoration with the relevant dependencies and validate the resulting data before declaring the business service available. The application starting successfully is only one checkpoint. Users may still be unable to authenticate, records may be incomplete or downstream interfaces may remain unavailable.

• Identify who can access and authorize use of recovery copies.
• Exercise restoration into the intended recovery environment.
• Validate data integrity and important user journeys.
• Reconcile any work completed through manual alternatives.

Test recovery when ordinary access cannot be trusted

CISA’s #StopRansomware Guide recommends offline, encrypted backups and regular tests of their availability and integrity. It also advises prioritizing critical services during restoration and taking care not to re-infect recovered systems.

• CISA: #StopRansomware Guide

Apply that guidance to a business exercise, not just a backup report. For an illustrative order-processing service, ask responders to obtain recovery access, restore an agreed copy in the intended environment and reconcile an order entered through the manual fallback. The service owner then confirms that staff can use the restored workflow before normal processing resumes.

• Record the recovery copy used, its timestamp and the data checks performed.
• Compare observed restoration time and recovered data with the agreed objectives.
• Assign unresolved access, integrity or reconciliation issues to an owner and retest them.

Communicate through the incident

Assign responsibility for messages to staff, customers, partners and leadership. Messages should distinguish confirmed facts from investigation and give a clear route for the next update. Legal or regulatory notification decisions need the relevant specialist input.

Keep the contact list available outside the systems it is intended to help recover. Practice how the team would communicate if ordinary email, telephony or collaboration tools were unavailable. Include the handover between shifts and the point at which normal service resumes.

Use exercises to expose the gaps

An exercise should test decisions and dependencies, not just whether people can read a runbook. Record what happened, what was assumed and what could not be demonstrated. Assign actions with owners and retest the important gaps.

• Run a scenario grounded in the organization’s environment.
• Measure restoration against the agreed objectives.
• Test communications and supplier escalation.
• Update the dependency map and recovery sequence.
• Review the plan after material changes to systems, people or suppliers.

Keep recovery roles clear, exercise recovery methods and maintain a visible list of remaining weaknesses as part of routine operations.