A cyber resilience business case should fund the recovery bottleneck

The backup proposal is cheaper and faster. The last recovery exercise, however, lost most of its time waiting for access to the application and reconciling transactions. Buying the proposal may improve storage economics without materially changing when the business can resume work.

For an infrastructure director defending a resilience budget, this is a question of causality. What exactly does the spending change, and why should that change improve service recovery? A persuasive business case follows the observed bottleneck through to the proposed investment.

Separate the stored copy from the working service

A backup is an important dependency in many recovery paths. It is not the whole path. Administrators need trusted access, infrastructure must be available, applications must be configured and the business may need to reconcile work before accepting the result.

CrowdStrike’s July 2024 incident account describes a Windows disruption caused by a faulty content update. For resilience planning, the relevance is the dependency: recovery requirements can be created by operational change as well as malicious activity.

The business case should therefore start from the services the organisation needs to restore and the failure conditions it has examined. A narrow component benchmark can support that case, but should not stand in for an end-to-end result.

Show what an improvement would actually change

Consider a hypothetical serial recovery exercise. Regaining administrative access takes two hours, restoring data takes three hours, and application validation and transaction reconciliation take another three. The total is eight hours.

A proposed change halves the restore stage to one and a half hours. If the other stages remain unchanged, the new total is six and a half hours, not four. That may be worthwhile, but the business should approve the benefit it can reasonably expect.

Now consider a different investment that makes administrative recovery available sooner and improves the reconciliation process. Its effect may be larger, smaller or less certain. Compare it against the same service outcome and test the assumptions that drive the difference.

Real recovery tasks can overlap, so use the actual critical path rather than adding every task duration mechanically. The example is a way to expose the logic, not a universal recovery model.

Compare credible alternatives

Include process and operating capability alongside products. A rehearsed emergency access route, clearer supplier escalation or better application ownership may address a demonstrated delay. These options still have costs: staff time, maintenance, exercises and the effort needed to keep them usable.

Conversely, do not assume process improvements can replace infrastructure the service genuinely requires. If capacity, clean recovery environments or data availability are the constraint, the investment must address them. The exercise should inform the choice rather than justify a preferred purchase after the fact.

Use RTO and RPO evidence to distinguish the target, the observed result and the conditions under which it was achieved.

Make financial uncertainty visible

Describe plausible disruption scenarios and their business consequences. Explain which costs are included and which are difficult to estimate. A range can help leadership compare options without pretending the organisation knows the exact probability and cost of a future incident.

Avoid counting every delayed transaction as permanently lost revenue. Some work may be recovered later, while other consequences may persist beyond restoration. Let finance and the service owner challenge those assumptions before turning them into a headline return.

The decision may still be compelling where precise avoided-loss estimates are unavailable. A required service cannot meet an agreed recovery expectation, and the proposed change has a defensible path to closing that gap. That is a stronger argument than an impressive but unsupported multiplier.

Fund the proof as part of the improvement

Reserve time for a repeat exercise with the relevant dependencies and a business acceptance step. The investment is incomplete until the team can establish whether the bottleneck actually moved.

If the test disappoints, use the result to revise the plan rather than quietly redefining success. The technology investment framework connects that review to the next spending decision. Resilience is a capability to demonstrate, and the budget should buy both the improvement and the evidence that it works.