Who is responsible for your disaster recovery plan?

Responsibility for disaster recovery has two layers: a senior person in the organisation remains accountable for the business outcome, while designated technical and operational owners carry out the recovery activities. The IT provider may design, manage or execute technical procedures, but it should not be treated as the sole owner of decisions about which services the business must restore first, what level of disruption is acceptable or when normal operations can resume.

A clear structure prevents important tasks from being assumed rather than assigned. It also ensures that recovery decisions reflect business priorities, not just the order in which systems happen to be listed by the IT team.

The board or senior management team should provide overall governance. Its responsibilities normally include:

• recognising disaster recovery as a business risk rather than solely an IT issue;
• appointing an accountable owner with sufficient authority to make decisions;
• approving recovery priorities, acceptable disruption levels and the resources required;
• ensuring that critical suppliers and outsourced services are included in planning; and
• reviewing test results, unresolved weaknesses and changes in business risk.

The accountable owner does not need to perform technical recovery work. Their role is to make sure the plan exists, remains suitable and is acted upon when an incident affects the organisation. They should also have authority to approve difficult choices, such as suspending a non-essential service, prioritising one department over another or authorising expenditure during a recovery.

Business service owners are responsible for explaining what each important service needs in order to operate. For example, the owner of a finance process may identify the applications, records, integrations and staff needed to raise invoices or process payments. A manufacturing or logistics owner may need to document dependencies involving production systems, scheduling, communications and third-party platforms.

Service owners should define:

• which activities are critical to the organisation;
• the consequences if a service is unavailable, incomplete or operating with old data;
• the order in which related systems and processes must be recovered;
• who can confirm that a recovered service is usable; and
• any manual workaround that can be used while technology is being restored.

Data owners should determine the importance, sensitivity and retention requirements of the information used by each process. They need to confirm which data must be recoverable, who may access it during an incident and how its integrity will be checked after restoration. This is distinct from simply backing up files: a backup may exist, but the business still needs to know whether it contains the right information and whether the restored data can support the relevant operation.

The IT team or managed IT provider is normally responsible for translating those business requirements into workable technical controls. Depending on the agreed arrangement, this can include:

• documenting the systems, dependencies and recovery sequence;
• configuring and monitoring backup and replication arrangements;
• protecting recovery credentials and backup infrastructure;
• maintaining recovery runbooks and technical contact details;
• restoring infrastructure, applications, accounts and data in the agreed order;
• recording test findings and technical limitations; and
• advising senior management when the plan, technology or business requirements change.

The IT provider should be accountable for the services it has agreed to manage, but the contract must make the boundaries explicit. A business should establish who owns backups, who checks that backup jobs are completing, who authorises restoration, who supplies application support and who contacts software or infrastructure suppliers. Vague wording such as “the provider manages disaster recovery” can leave gaps when a system is hosted by a separate supplier or when the recovery decision depends on a business process.

Incident leadership should also be assigned separately from routine IT administration. During a major outage, someone must coordinate decisions, maintain an incident record and provide a consistent position to employees, customers, suppliers and other stakeholders. This person may work with the technical recovery lead, but the roles are different: the technical lead concentrates on restoration, while the incident lead manages priorities, approvals and communications.

Other roles may be needed for particular organisations:

• Information security or data protection leads can assess whether the incident involves unauthorised access, data loss or notification obligations.
• Facilities or premises managers can coordinate building access, replacement equipment, utilities and physical safety where the primary site is affected.
• Human resources and communications teams can manage staff instructions and approved internal messaging.
• Procurement or supplier managers can coordinate external providers and check contractual dependencies.
• Departmental deputies can provide cover when a named decision-maker is unavailable.

These responsibilities should be recorded in a role and responsibility matrix. A simple matrix can identify who is accountable for the outcome, who is responsible for completing a task, who must be consulted and who must be informed. Every critical activity should have one clearly accountable role, even if several people contribute to it.

The plan should also identify authority limits. It should state who can declare a disaster, approve a failover, isolate a compromised system, release restored data to users and return to normal operations. Without these decisions being assigned in advance, recovery can be delayed by uncertainty or conflicting instructions.

Responsibility does not end when systems have been switched back on. The relevant owners should confirm that applications work, data is complete, integrations are functioning and users can perform essential tasks. A post-incident review should then record what happened, which assumptions proved incorrect, what controls failed and who is responsible for each corrective action.

S2 Technology Group can support businesses by helping document recovery responsibilities, map technical dependencies, manage backup arrangements and test whether recovery procedures work in practice. The business should nevertheless retain ownership of its priorities and approvals. A well-managed disaster recovery plan is therefore a shared operating arrangement with one clearly accountable business owner, defined technical duties and named decision-makers for each critical stage.