What should an outsourced IT department include in its disaster recovery responsibilities?

An outsourced IT department should be responsible for the technical arrangements that allow agreed services to be restored after a major interruption, while the client retains ownership of business decisions, risk acceptance and operational priorities. Those responsibilities should be defined in writing, aligned with the organisation’s continuity plans and supported by evidence that the recovery arrangements work in practice.

Responsibility should begin with clear ownership. The agreement should identify which systems, sites, devices, cloud services, networks and data are covered. It should also state what remains with the organisation, such as approving recovery priorities, maintaining contact details, informing staff and deciding when a business service can be resumed. Without this division, an incident can be delayed by uncertainty over who is authorised to make a decision.

The outsourced provider should maintain an accurate record of the technical environment relevant to recovery. This normally includes:

• servers, endpoints, networking equipment and cloud resources;
• business applications and the data they process;
• dependencies between systems, including identity services, DNS, email, file storage and connectivity;
• licence, subscription and support information needed to rebuild services;
• administrative accounts, recovery keys and configuration information held securely; and
• details of third-party suppliers whose services affect the recovery process.

This information must be protected as carefully as the backed-up data. Recovery documentation that contains privileged credentials or security details should not be left in ordinary shared folders or accessible through a compromised user account. Access should be restricted, monitored and capable of being retrieved when the usual environment is unavailable.

Recovery objectives should be practical and system-specific. The provider should help the organisation define a recovery time objective, meaning the acceptable period before a service is restored, and a recovery point objective, meaning the maximum tolerable gap in data. These objectives should reflect the business process rather than being applied uniformly to every system. For example, a production or order-processing system may have different requirements from an archive or non-essential internal application.

The provider should then confirm that the proposed technical design can meet those objectives. A backup that exists but takes too long to retrieve, depends on an unavailable platform or cannot restore application functionality does not satisfy the requirement. Recovery plans should account for the order in which infrastructure, identity, applications and user access need to be made available.

Backup responsibilities should extend beyond scheduling jobs. An outsourced IT department should monitor whether backups complete, investigate failures, protect backup management interfaces and prevent ordinary user credentials from being used to delete recovery data. It should also consider separation between the production environment and backup copies, retention requirements, encryption, access logging and the effect of ransomware on connected storage.

Where appropriate, recovery arrangements may include more than one form of copy, such as a separate repository or a protected copy that cannot be altered through normal administrative access. The right design depends on the organisation’s systems, risk profile and regulatory obligations. The important point is that the provider should explain the design, its limitations and the circumstances in which each recovery method would be used.

Cyber incidents require a different recovery approach from ordinary hardware failure. The provider should be able to support isolation of affected devices, preservation of relevant evidence and verification that systems are safe to restore. Reconnecting compromised accounts, servers or applications before the cause has been contained can reintroduce the incident. Recovery procedures should therefore include credential resets, malware checks, validation of security controls and a controlled return of services.

The outsourced department should also define how it will work with the organisation’s leadership, insurer, legal advisers, compliance contacts and any specialist incident response provider. It may provide technical evidence and system information, but the client may need to make decisions about notification, disclosure, operational shutdown or communication with customers and regulators. These responsibilities should not be assumed to sit with the IT provider unless the contract expressly says so.

Testing should examine more than whether a backup can be opened. A useful exercise can test individual file restoration, application recovery, a complete server rebuild, loss of a site, loss of administrative access and recovery from a cyber compromise. Tests should use defined success criteria and record:

• which systems were included;
• how long each stage took;
• whether data and configurations were complete;
• which manual workarounds were required;
• where responsibilities or instructions were unclear; and
• what corrective actions were assigned and completed.

A plan that depends on one engineer’s personal knowledge is fragile. The provider should ensure that recovery instructions are understandable to an appropriately authorised member of the support team and that key procedures are available if the primary management platform, documentation system or communication channel is affected. Contact arrangements should include escalation routes, decision-makers and alternative means of coordination.

Business continuity should be addressed alongside technical recovery. Restoring IT does not automatically restore the business. The outsourced department should help identify temporary arrangements where appropriate, such as alternative connectivity, replacement devices, manual processing or access to essential information through a controlled method. It should also make clear which workarounds are approved, how long they can be used and how data created during the disruption will be reconciled afterwards.

Contracts and service reviews should include measurable evidence rather than broad statements that disaster recovery is provided. Useful evidence can include current recovery documentation, backup and monitoring records, test results, outstanding remediation actions and confirmation that important changes have been reflected in the recovery design. The provider should be told when the organisation adopts a new application, changes locations, alters its staffing model or moves data to another platform, because these changes can invalidate previous arrangements.

Finally, the outsourced IT department should support a structured post-incident review. The purpose is not simply to record what happened, but to establish whether the recovery objectives were realistic, whether dependencies were understood, whether controls prevented further damage and which changes are required. A mature arrangement treats disaster recovery as an ongoing operational responsibility with defined ownership, secure information, tested procedures and transparent limitations—not as a document produced once and then left unchanged.