Boards approve resilience budgets on the strength of a recovery plan they have not seen tested, against objectives whose derivation nobody has explained. That is not negligence; it is an information problem. The papers that reach the board describe activity rather than capability, and the questions that would surface the difference are technical enough that few non-executive directors feel able to ask them. A disaster recovery risk assessment done properly closes that gap by producing evidence a board can interrogate. This article sets out the ten questions worth asking before the 2027 budget is approved, what a good answer looks like, and what each weak answer tends to cost. Our note on whether NESA-aligned backups survive ransomware covers the backup dimension.

Key Takeaways

• An untested recovery objective is a hypothesis. The board question is not what the target is but when it was last demonstrated and what the test measured.
• Most recovery gaps trace to three places: the identity platform, backup isolation, and third-party dependencies that no internal test can exercise.
• Budget requests should be framed as risk coverage with a named exposure, not as infrastructure line items, so the board can compare resilience spend against other risk spending.

Question One to Three: Are the Objectives Real

A disaster recovery risk assessment opens with the question of where the recovery time and recovery point objectives came from. A good answer traces each one to a business impact analysis that quantifies loss per hour of outage for the service concerned. A weak answer describes what the infrastructure can currently achieve, which means the targets were reverse-engineered from capability and the analysis is decorative.

The second question is when each objective was last demonstrated. Demonstrated means an actual failover, timed, with the service operated in the recovery environment long enough to prove it works rather than merely starts. A tabletop discussion, however well attended, does not answer this question and boards should be comfortable saying so.

The third question is what the last test found. A test that produced no findings almost always means the scenario was too easy or the scope too narrow, because genuine failover of a complex estate surfaces something every time. A candid list of findings with owners and closure dates is a stronger signal of maturity than a clean report.

Where objectives were set per service rather than as a single institution-wide figure, that is a good sign. A single number applied across every service means the analysis was not granular enough to be useful, and it usually results in over-investment in low-impact systems alongside under-investment in the ones that matter.

Structured guidance such as NIST SP 800-34 on contingency planning gives a defensible structure for this chain, and asking whether the programme aligns to a recognised standard is a reasonable board question in its own right.

Question Four to Six: Where the Gaps Usually Are

The fourth question every disaster recovery risk assessment should force is whether the identity platform has its own recovery tier and its own test. Directory services, certificate authorities and privileged access systems are usually classified as infrastructure, receive no service tier and no objective, and then every other recovery stalls waiting for them. This is the single most common structural gap we see.

The fifth is whether backups are isolated or merely replicated. Replication propagates corruption and ransomware to the secondary copy at machine speed. The board question is whether there is an immutable copy that a compromised production administrator cannot alter or delete, and when a restore from that copy was last performed end to end.

The sixth is what evidence exists for third-party dependencies. Cloud providers, payment processors, core banking vendors and intragroup service companies all sit on the critical path, and none of them is exercised by an internal test. A good answer holds each provider's recovery objectives, evidence those were tested, and an exit plan that does not require the provider's cooperation.

These three account for the majority of findings in the reviews we support, and none of them requires new technology to close. They require a decision about ownership and a test calendar that includes the uncomfortable scenarios.

Question Seven to Ten: Governance and Realism

The seventh question is who decides to invoke recovery, and whether that person can be reached at three in the morning on a public holiday. Invocation authority is frequently undefined, and the hours lost while an organisation decides whether it is having an incident are hours added to every recovery objective in the plan.

The eighth is how customers, regulators and staff are informed, and whether that communication path survives the outage. Plans that depend on the corporate email system to coordinate a recovery from a failure of the corporate email system are more common than they should be.

The ninth is what has changed since the last assessment. New services, migrations, acquisitions and vendor changes all invalidate parts of the plan, and a disaster recovery risk assessment that has not been refreshed since a core platform migration is describing an estate that no longer exists.

The tenth is what the institution would actually lose. Not the theoretical maximum, but the realistic figure for a defined scenario: a four-hour outage of the primary payments channel on a working day, a ransomware event affecting the core platform, a regional cloud failure. Boards make better decisions against three concrete scenarios than against a generic risk statement.

Response process guidance such as the NCSC incident management collection is a useful benchmark for questions seven and eight, which are process rather than technology questions and are usually the cheapest to fix.

Framing the Budget Request

Resilience budgets fail at the board not because the amount is wrong but because the framing invites the wrong comparison. A request for storage, replication licences and a secondary site reads as an infrastructure project competing with other infrastructure projects. The same request framed as reducing the exposure of the payments channel from a defined figure to a lower one reads as risk management.

Build the request from the assessment rather than from a vendor proposal. Each line should name the gap it closes, the scenario in which that gap becomes a loss, and what residual exposure remains afterwards. Boards are considerably more willing to fund a partial improvement that is honestly described than a complete solution that is not.

Present the do-nothing option properly. Every risk paper should state what happens if the budget is not approved, in the same terms as the recommendation. This is not a pressure tactic; it is the information a board needs to accept a risk deliberately, which is a legitimate outcome and one that should be recorded.

Sequence multi-year work explicitly. Resilience improvements rarely complete in a single budget cycle, and a plan that shows what each year buys, with a checkpoint at the end of each, is easier to approve than a single large number with a distant completion date.

Our note on building enterprise resilience in the data centre covers the infrastructure choices that sit behind these requests.

What the Board Should See Routinely

Between budget cycles the board needs four things at a defined interval. The current recovery posture by service, showing objective, last demonstrated performance and the date. The testing calendar for the next twelve months. Open findings from completed tests with owners and dates. And any material change to dependencies since the last report.

Deferred tests should appear explicitly rather than quietly slipping. A test postponed for good operational reasons is a decision the board should see, because a pattern of deferrals is the clearest early indicator that a recovery capability is drifting away from its stated objectives.

The accountable executive should be able to describe the posture without reading from the document. This is not a formality; a plan that only its author understands will not be executed under pressure, and the ability to summarise it is a reasonable proxy for whether it has been genuinely internalised.

Add a standing item on lessons from sector incidents. When another institution in the region experiences an outage, the useful board question is whether the same scenario has been tested here, and that discussion is far more productive shortly after the event than at the next annual review.

Effective disaster recovery management is a governance rhythm as much as a technical capability, and the rhythm is what keeps the technical capability current between assessments.

Turning the Answers Into a Plan

After the questions have been asked, sort the weak answers into three groups. Those that need a decision, such as who holds invocation authority. Those that need a test, such as an identity platform recovery that has never been attempted. And those that need investment, such as an immutable backup copy the estate does not currently have.

The first group costs nothing and should be closed within the quarter. The second group costs time and disruption but no capital, and it usually reveals whether the third group is as large as assumed. Running the tests before the budget request produces a considerably more accurate number.

Only the third group belongs in the budget paper, and by then each line has evidence behind it. This sequence, decide then test then fund, is what separates a resilience programme that improves from one that renews the same request each year with a slightly larger figure.

Set the next assessment date before the current one closes, and tie it to the change calendar rather than to the anniversary. A migration or acquisition should trigger a refresh regardless of when the last one happened.

If you want an independent review of your current position against these ten questions, our resilience team can run the assessment with you and produce the evidence pack. You can also see how our infrastructure and data platform practice supports recovery objectives in regulated estates, and our note on recovery as a service for BFSI ransomware scenarios.