Funding the Bad Day: A Recovery-First Cyber Budget for UK Boards

Most board cyber papers are built around the next threat. They report phishing simulations completed, endpoint coverage, patch compliance, vulnerability closures and the number of alerts triaged. These are useful indicators. They are not, however, the measures that determine how quickly a UK business recovers when a serious incident lands. The worst day is not an abstract scenario. It is the morning when production systems are unavailable, the backup catalogue is incomplete, the insurer's loss adjuster asks for restoration evidence, and customers expect service to resume before the board has agreed its next statement.

Prevention is not a recovery plan

Prevention lowers the probability of an incident. Recovery lowers its duration and severity. Boards need both, but the budget line often reveals a different priority. Spending on prevention and detection is easier to justify because it maps to tools, scans and dashboards. Recovery is harder: it requires engineering, rehearsal and uncomfortable evidence about what does not work. That is precisely why it belongs in the boardroom.

A recovery-first budget does not mean abandoning prevention. It means treating restoration, continuity and tested backups as outcomes that deserve named owners, approved tolerances and recurring funding. The test is simple: if the board can describe its detection coverage but not its restoration capability for the top five business services, the balance is wrong.

The UK pressures making recovery a board issue

Regulatory expectations have moved. Financial services firms subject to FCA and PRA operational resilience requirements must identify important business services and set impact tolerances; that work is incomplete if restoration has not been tested against those tolerances. UK GDPR breach reporting creates a 72-hour clock to the ICO in many cases, but the practical obligation to understand what has happened, what data is affected and what customers need is far shorter. NCSC guidance has long emphasised tested backups and incident response exercises. Insurers now ask harder questions about backup isolation, restoration times and dependent suppliers. A policy that assumes recovery capability the business cannot demonstrate is a false comfort.

Operational reality adds pressure. UK organisations rely on managed service providers, cloud platforms and SaaS tools that concentrate risk. Hybrid working has distributed identity and endpoints. Many mid-market firms do not have the in-house depth to rebuild complex estates at speed. Ransomware actors target backups first. The result is that recovery is no longer an IT chore; it is a commercial capability that affects customers, cash flow, regulatory standing and reputation.

What a recovery-first budget should fund

A recovery-first budget should be organised around four buckets rather than around product categories.

• Recoverability engineering: immutable and isolated backups, clean-room restoration, automated rebuilds, identity recovery, key management and secure configuration baselines.
• Continuity by design: documented manual workarounds, out-of-band communications, alternative payment routes, paper-based processes and temporary operating models for the top five business services.
• Exercise and assurance: end-to-end restoration tests, executive tabletop exercises, supplier failover tests and independent validation of recovery claims.
• Incident response capacity: retainers for legal, forensics, communications and negotiation, plus the internal staff time to use them.

Boards should also budget for the unglamorous costs of a bad day: overtime, temporary staff, expedited hardware, customer remediation and the management attention that disappears from other projects. These costs are predictable enough to plan for, even if the incident itself is not.

A director's challenge checklist

Before the next incident, directors should be able to answer the following questions without relying on reassurance from a single function.

• Which business services have documented recovery time and recovery point objectives, and who owns them?
• When was the last end-to-end restoration test for each critical service, and what failed?
• Can critical data be restored from an isolated backup without the production environment being available?
• What manual workaround exists for the top five services, and how long could it operate before customer harm becomes unacceptable?
• Which suppliers are single points of failure, and what recovery commitments have they made in contract?
• Has the incident response plan been exercised with executives, insurers, legal advisers and communications teams in the room?
• Do the conditions attached to the cyber insurance policy match the recovery capability the business actually has?
• What proportion of cyber budget is allocated to recovery, continuity and testing rather than prevention and detection alone?
• Who is accountable for recovery outcomes, and what evidence does the board receive each quarter?
• What would the board need to see to know that recovery claims are not merely aspirational?

Reporting recovery to the board

The board does not need a technical dashboard. It needs a recovery scorecard that shows, for each important business service, the approved tolerance, the last test result, the open remediation actions and the date of the next exercise. It should show supplier dependencies and the evidence received from those suppliers. It should also show the funding decision: what has been deferred, what risk that creates and who accepted it.

A recovery-first budget is not pessimistic. It is a clear-headed recognition that some incidents will get through. The organisations that cope best are not those that promise prevention will never fail. They are those that have funded the bad day in advance, tested the assumptions and given the board enough evidence to challenge them.