Cyber resilience starts with the business service that must return

The hardest recovery decision is often a commercial one: which part of the business gets scarce people and working infrastructure first? A CIO can have a detailed inventory and still lack an agreed answer. If every service is labelled critical, the plan has postponed the choice until the moment least suited to making it.

Cyber resilience connects that choice to technical capability. It asks what the business must continue doing, what it can temporarily do less well, and what dependencies must recover together. The result should be a credible operating sequence, not simply a list of systems to restore.

A common dependency can overturn the priority list

The CrowdStrike incident report from July 2024 describes a faulty content update that crashed affected Windows systems. For CIOs, its relevance is the reach of a shared dependency: a control intended to protect services can itself become a source of simultaneous disruption.

That changes the planning question. Ranking applications individually is insufficient if the highest-ranked services depend on the same unavailable identity, endpoint or network capability. Trace those common dependencies and ask whether the recovery team can work when they are missing.

Also examine the people and authority shared across recovery paths. Two teams may each have a credible plan that depends on the same specialist being available at the same time. The conflict is a capacity decision for leadership, rather than a technical detail to leave in separate runbooks.

Decide what reduced operation is worth

A service does not always have to return at full capacity to provide useful value. A business owner may prefer a limited, reconciled operation sooner to a complete restoration later. The choice depends on transaction volume, error consequences and the work needed to clear the backlog.

Make that reduced mode explicit. A manual workaround that can support a few urgent transactions is different from one expected to carry normal demand for several days. Test the constraint before assigning the workaround an important place in the recovery plan.

Start with the service people need

A business service is an outcome people rely on: taking an order, dispatching a delivery, paying staff or answering an urgent customer request. Its recovery may depend on several applications, a shared identity service, external suppliers and a person with the authority to approve a workaround.

Use the service as the unit of planning. Ask its business owner what minimum useful operation looks like, how long a disruption is tolerable and what harm develops as the interruption continues. Record the assumptions behind the answers. A target agreed in a workshop is an aspiration until the organisation can demonstrate it.

Prevention and recovery answer different questions

The NIST Cybersecurity Framework 2.0 includes recovery alongside protection, detection, response, identification and governance. That breadth is useful: buying stronger preventive controls does not settle the separate question of how the organisation will resume a service after those controls fail.

Our recommended planning test is straightforward: can the service owner describe the first useful business transaction after recovery, and can the technical team identify everything that must work to complete it? If either answer is vague, start there before debating a new resilience platform.

An illustrative recovery decision

Consider a distributor whose warehouse system and reporting platform are both unavailable. Restoring the reporting platform first might make a dashboard look healthy while orders remain stuck. Restoring the warehouse application alone may also be insufficient if staff cannot sign in or the carrier integration cannot generate labels.

A useful recovery sequence might therefore begin with controlled administrator access and the minimum warehouse dependencies, followed by a test dispatch and reconciliation of queued orders. The sequence must be agreed with operations: IT should not assume that a technically convenient restoration order is commercially acceptable.

Test the assumptions that are easiest to overlook

Choose an exercise that makes one important dependency unavailable. Ask how administrators obtain trusted access, where recovery instructions are kept and whether the required supplier can respond. Measure the elapsed time to a successful business task rather than stopping the clock when a server starts.

Keep a record of the environment, data volume, people involved and shortcuts used. An exercise using a prepared test environment does not demonstrate the same recovery capability as rebuilding under a compromised production identity system. Both can be useful, but they answer different questions.

When an exercise exposes a gap, record the decision it requires. That might be funding a secondary dependency, changing a service target or accepting a documented period of reduced capacity. A list of technical actions without an owner and a business consequence will be difficult to prioritise.

The recovery sequence is a leadership decision

Bring a one-page service record: owner, impact over time, minimum operating level, dependencies, recovery sequence, evidence from the last exercise and unresolved decisions. It should make trade-offs visible without pretending that an untested target is a guarantee.

The strongest first improvement may be a clearer dependency or a rehearsed handover. Let the exercise identify the investment requirement, rather than selecting a product and hoping it defines the recovery plan.

Use recovery-target testing to turn the priority into evidence. The CIO’s role is to ensure that the service sequence, shared dependencies and business acceptance fit together before the next exercise exposes their disagreement.