What are the signs that a resilience programme is still only a plan?

A resilience programme is still only a plan when teams can describe recovery objectives but cannot show tested results. Another warning sign is silence when asked whether restoration can be proved to boards or insurers. If recovery timing, clean recovery points, and service-specific outcomes are not documented, the programme lacks evidence and remains largely theoretical.

When a resilience programme still lacks proof

A resilience programme stops being theoretical only when it can show evidence, not just intent. If teams can name recovery targets but cannot demonstrate that systems were restored within them, the programme is still a plan. The same is true when recovery point expectations, service-specific outcomes, or decision records exist only as assumptions.

What proof should exist beyond the plan

The strongest indicator is operational evidence that the organisation has tested the recovery path it claims to rely on. That includes documented recovery timing, clean recovery points, dependencies that were actually restored in sequence, and proof that the recovered service behaved as expected. Without that, resilience is being described, not validated.

Boards, auditors, and insurers usually care less about the wording of the objective than about whether the organisation can show repeatable restoration under realistic conditions. A resilience programme becomes credible when the evidence trail connects the declared objective, the test result, and the service outcome.

How to recognise a programme that is still mostly aspirational

A programme is still mostly a plan when recovery statements are generic, test results are absent, and exceptions are not tracked to closure. Another warning sign is that recovery is discussed at a portfolio level, but no one can show what happened for a specific critical service. If the programme cannot prove one service end to end, it usually cannot prove the rest at scale.

Silence is also informative. If teams avoid the question of whether restoration can be proved to boards or insurers, the programme likely has a documentation gap, a testing gap, or both. In practice, the issue is often not a lack of ambition but a lack of measurable recovery evidence.

Risk and Threat Considerations

A resilience programme without tested evidence creates exposure in both operational continuity and assurance. The risk is that leadership believes recovery is available when the organisation has only articulated recovery intent, which can leave outages, incidents, and claim or assurance conversations unsupported.

Failure mechanism: Recovery objectives remain unvalidated, clean recovery points are not demonstrated, and service-specific restoration outcomes are not documented, so the organisation cannot prove that recovery will work when needed.

Impact: Failed recovery can extend downtime, weaken incident response decisions, undermine confidence from boards or insurers, and expose gaps only after a real disruption.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 sets the technical controls, while ISO/IEC 27001:2022 and DORA define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	RC.RP-01 — Recovery Plan Execution	Recovery claims need tested restoration, not just documented intent.
	RC.RP-02 — Recovery Communications	Boards and insurers need proof that recovery outcomes can be communicated and demonstrated.
	GV.OV-01 — Oversight of the Cybersecurity Risk Management Strategy	Programme credibility depends on oversight that can verify recovery evidence, not assertions.
Recommendation — Test and execute recovery plans so restoration evidence exists for critical services. Document recovery outcomes and keep evidence ready for assurance conversations. Review resilience evidence at oversight level before accepting maturity claims.
ISO/IEC 27001:2022	A.5.30 — ICT readiness for business continuity	This control directly requires readiness that can be evidenced through continuity and recovery capability.
Recommendation — Verify and test ICT continuity arrangements for critical services.
DORA	Digital operational resilience testing	The subject centers on proving operational resilience through testing rather than plans.
Recommendation — Use resilience testing to confirm services can recover within stated objectives.

Practitioner Guidance

What to verify: Require evidence for each critical service, not just programme-level statements. The minimum useful artefacts are a tested recovery time, a verified recovery point, and a recorded outcome showing the service actually returned to an acceptable state.

Decision rule: If a team cannot produce the last successful restoration evidence for a service, treat the control as unproven and prioritise testing before expanding the programme’s scope or claiming resilience maturity.

Practitioner takeaway: A resilience programme is real only when recovery can be demonstrated under test, attributed to a specific service, and repeated with evidence that stands up to scrutiny.