How leadership can know, with evidence, whether critical services could continue and recover after a disruption

Authority disclaimer. This page is an executive narrative. It does not establish requirements; the linked corpus governs. It is provided to support understanding, discussion, and decision-making by the governing body and accountable executive leadership (board, ELT, or senior management, as applicable). It creates no obligation, control, or assurance by itself. Its publication approval is an editorial act only and confers no authority over any corpus document. Where it differs from a corpus document, the corpus document prevails.

The corpus states the shape of resilience assurance in one sentence: its business continuity and resilience framework connects business impact, service dependency, recovery objectives, supplier exposure, technology recovery, communication, test evidence, corrective action, and governance reporting (its Purpose section). This page maps the corpus documents along that connected path to a single outcome:

Leadership can state, with evidence, whether the organization's critical services could continue and recover within their approved objectives after a disruption, and can see where that readiness rests on untested assumptions.

The first half of the outcome concerns the recovery capability itself. The second half concerns the coverage of the proof, which the corpus records deliberately: the resilience metrics and testing log register records the coverage of critical services with current plans and approved recovery objectives and the count of recovery tests meeting their applicable objective (its Section 2, as counts or percentages), and the framework's recommended metrics include the share of critical services tested within the required cadence (its Metrics section). The assembly of the corpus documents below into one path, and the reading order, are a composite synthesis across the sources this page lists; the limitations say so.

Each row relates one corpus control to the outcome using exactly one of the narrative layer's four relationship words. A contribution materially advances the outcome without being sufficient for it; a dependency is a condition the outcome requires; a prevention reduces the opportunity for a named failure mode; evidence demonstrates that a control exists or operates. No stronger relationship word appears on this page, by design. Where a row's justification is the cited document's own stated purpose, the row paraphrases it closely; the assignment of exactly one word per row is a composite reading, and the limitations carry that caveat.

• The corpus states the path's couplings document by document: the testing procedure's step 8 updates continuity plans, recovery plans, BIA outputs, risk records, and recovery objectives from test results; the register's use requirements link testing evidence to business impact analysis, recovery objectives, supplier assessments, AI system continuity records, and risk registers; and the board risk report template carries exercise results into oversight (its Section 10). The reading of the seven rows as one ordered path is this page's synthesis, not any single document's statement; the limitations flag it as composite.
• The corpus separates a documented plan from proof that it operates: the policy requires recovery tests to record actual outcomes, failed assumptions, corrective actions, residual risk, and business acceptance (its section 3), and the test record pairs targets with actuals (the testing procedure's Required test record section; the register's Section 1).
• The corpus deliberately does not define an organization's critical services or recovery tolerances: the framework's Limitations state that an adopting organization completes its own business impact analysis, validates technical recovery capability, tests assumptions, and formally accepts residual risk. The IT disaster recovery plan states that the infrastructure it names is an illustrative reference deployment, not a description of any particular organization's environment (its Purpose section).
• Supplier, cloud, and AI dependencies enter the path as assessed dependencies: the policy requires supplier and cloud dependencies to be assessed for continuity commitments, recovery capability, and exit feasibility, and AI system continuity to address model availability, fallback, and emergency disablement (its section 3). The supply-chain and AI corpus documents that operationalize those assessments sit outside this map's scope; the framework's Related Documents route to them.

Each item below is an evidence class leadership can ask management for, for a sampled critical service. Each is evidence for a named layer of the map operating.

• The current business impact analysis and approved recovery objectives for the sampled service, with the approving role, as evidence for the analysis layer in the BIA procedure.
• The continuity plan and the recovery plan covering the sampled service, with their activation criteria and restoration sequence, as evidence for the planning layer in the business continuity and crisis management plan and the IT disaster recovery plan.
• The sampled service's most recent test record, with its recovery target, actual recovery time, actual recovery point, and whether the success criteria were met, as evidence for the testing layer in the continuity and recovery testing procedure.
• The period's resilience metrics, including critical services with a current business impact analysis, services tested within the required cadence, tests meeting their recovery objectives, and open corrective actions, as evidence for the coverage layer in the resilience metrics and testing log register and the framework.
• The lessons-learned report from the most recent significant event or exercise, with the corrective actions it fed and their closure status, as evidence for the improvement layer in the lessons-learned template.
• The resilience and continuity section of the latest board risk report, with its material gaps, as evidence for the reporting layer in the board risk report template.
• Any approved exception to a continuity or recovery requirement touching the sampled service, risk assessed, time bound, and tracked to closure per the policy's section 3, as evidence for the accepted-deviation route in that policy.

• This page creates no compliance and imposes no requirement. The linked corpus documents govern; where this page differs from a corpus document, the corpus document prevails.
• This page carries composite claims. The assembly of the listed corpus documents into a single path, the reading order, the two-part outcome framing, and the assignment of exactly one relationship word per row are synthesized across the sources named above; a control can serve the outcome in more than one way, and the map records the primary relationship. The adopting organization validates that reading against its own resilience model.
• The specific values live with the adopting organization, inside the corpus structures this page links: recovery time and recovery point objectives, maximum tolerable disruption, test cadences, and metric thresholds are the organization's own, recorded in the fields the standard, the BIA procedure, and the register define. This page routes to those documents and reproduces no value.
• Adoption is not presented as effectiveness. Holding the plans and templates this page links, or requesting the artefacts it names, is not evidence that any service can recover in an adopting organization; the framework's own Limitations require validated technical recovery capability, tested assumptions, and formally accepted residual risk, and only the organization's own test records speak to what recovery actually achieved.
• The role names on this page (resilience owner, service owner, governing body, accountable executive leadership) are the corpus's reference vocabulary; an adopting organization maps them onto its own structure.
• This page makes no claim about the likelihood, occurrence frequency, or magnitude of a disruption, a recovery failure, or an outcome, and none of its statements should be read as a probability; the scenario types and testing cadences it points to are the cited sources' own, routed and not reproduced.