What should fully managed IT support include for business continuity?

For business continuity, fully managed IT support must turn the organisation’s continuity requirements into a maintained operating model: identifying which services matter most, defining acceptable disruption, assigning ownership and rehearsing how the business will operate during an incident. The provider should manage the technical environment, but continuity also depends on documented decisions, trained people and clear communication.

Start with business impact analysis. A useful service should examine how each important business activity depends on technology. This may include line-of-business applications, identity systems, file storage, email, telephony, connectivity, devices and access to premises. The analysis should record the effect of losing each dependency, which activities take priority and what minimum capability is needed to continue operating.

This creates a basis for setting recovery objectives. The recovery time objective describes how long a service can be unavailable before the impact becomes unacceptable. The recovery point objective describes how much recent data the organisation could afford to lose. These objectives should be agreed with business owners rather than selected solely by an IT provider, because different systems may have different commercial, legal or operational importance.

Maintain a prioritised service and dependency map. Continuity planning is more reliable when it shows the relationships between systems. For example, restoring an application may not be useful if staff cannot authenticate, connect to the network or access the data it requires. Documentation should therefore link critical applications to servers or cloud services, user accounts, network connections, devices, suppliers and relevant administrative credentials. It should also identify single points of failure and dependencies that could prevent recovery.

The map needs regular review. Changes such as moving an application to the cloud, introducing a new site, changing a supplier or altering how staff work can invalidate an older plan. A managed IT provider should include these reviews within its service governance rather than treating continuity documentation as a one-off project.

Separate continuity from recovery. Recovery procedures explain how technology is brought back to an agreed state. Business continuity planning also needs practical workarounds for the period before normal services are restored. Depending on the organisation, this might involve approved alternative communication methods, manual processing, temporary user access arrangements, replacement equipment or a defined process for prioritising essential transactions.

The plan should state who can authorise a workaround, how information created during that period will be reconciled later and which controls still apply. A workaround that keeps work moving but creates uncontrolled copies of sensitive information can introduce a further security or compliance problem.

Define roles and decision rights. A continuity plan should name the business owners, technical contacts and decision-makers involved in an incident. It should clarify who can declare a major disruption, who communicates with employees, who contacts suppliers, who approves emergency changes and who decides when systems are safe to return to normal operation.

Contact details should be stored in a form that remains available when the main IT environment is inaccessible. The plan should also account for staff changes and make responsibilities understandable to people who may not normally manage technology. If external support is part of the recovery process, the provider’s responsibilities and escalation route should be documented in the service agreement.

Include communication procedures. During a disruption, inconsistent messages can slow decisions and create confusion. A practical plan should identify communication channels, message owners and the information that needs to be shared with staff, customers, suppliers or other relevant parties. It should provide a method for recording decisions and maintaining an incident timeline.

Communication planning should not depend on a single system that may be unavailable. It should also distinguish between technical updates and business decisions, so that users understand what they can do, which services are affected and where to report further issues.

Test the plan in stages. A written procedure has limited value if nobody has checked whether it works in the organisation’s actual environment. Testing can begin with a review of assumptions and a discussion-based exercise, then progress to controlled validation of recovery steps where appropriate. Scenarios should cover more than hardware failure; they may include loss of connectivity, unavailable cloud services, compromised accounts, supplier disruption or loss of access to a business location.

Each exercise should produce recorded findings, named owners and target dates for corrective action. The important measure is not whether a test appears successful, but whether it reveals gaps in documentation, access, dependencies, skills or decision-making. Changes made after an exercise should be recorded and reflected in the next version of the plan.

Control access during an incident. Emergency recovery can require privileged access, but broad or undocumented access increases the risk of misuse. Continuity arrangements should cover the secure storage and controlled release of administrative credentials, approval for emergency changes, logging of activity and removal or review of temporary access afterwards. Recovery procedures should preserve the same security principles as normal operations wherever practicable.

Identity management is particularly important because users may need to access systems from alternative locations or with replacement devices. The continuity design should explain how legitimate users are verified and how compromised accounts are contained without unnecessarily blocking essential business activity.

Review supplier and cloud dependencies. A business may rely on connectivity providers, software vendors, data centres, payment services, outsourced platforms or specialist applications. Fully managed IT support should maintain an accurate record of these dependencies and establish what information is available if a supplier becomes unavailable. This includes service contacts, contractual responsibilities, data export options and any technical alternatives that have been assessed.

Cloud services can improve resilience, but they do not remove the need for continuity planning. The organisation still needs to understand account ownership, administrative access, dependency on internet connectivity, data recovery options and how staff would work if the provider or a related identity service could not be reached.

Use governance to keep continuity current. A suitable managed service should report on continuity-related actions, outstanding risks, material changes and the results of exercises. Reviews should involve both technical and business stakeholders, because IT may identify a recovery dependency that the business has not considered, while operational teams may identify a priority that is not visible from system records.

In practice, the strongest arrangements combine documented priorities, defined recovery objectives, dependency information, workable alternatives, controlled access, tested procedures and accountable follow-up. Fully managed IT support contributes by maintaining the technical estate and the continuity processes around it, while business leaders remain responsible for agreeing priorities and acceptable levels of disruption.