640 hours, 22 units, one failed recovery test

First, price the request. 640 hours across 22 units is roughly 29 hours per unit including planning, supervision, workpaper review and reporting. That buys a document review per unit and no testing. Breadth here produces false comfort, which is worse than an acknowledged limitation.

Risk-rank, don't enumerate. Criticality (impact) x uncertainty (likelihood that the arrangement fails). Include:

• The four Tier 1 units, weighted heavily toward merchant settlement: 8-hour RTO, 25-month test failure - that combination is the single highest-likelihood failure in the universe.
• The shared card-network gateway as a concentration, tested horizontally across both dependent units rather than twice vertically. Correlated failure of two Tier 1 services is not captured by unit-by-unit scoping.
• The cloud migration as a change-driven risk: seven months in, runbook still referencing retired cages, so recovery capability post-migration is unproven by default.
• Programme-level elements: BIA currency, exercise programme, third-party continuity management.

Defer Tier 2/3 units with no change and low impact; document the rationale and the reliance on management self-assessment, having first tested the reliability of that self-assessment on a small sample.

Sampling logic: Tier 1 plans are a population of four - test all, no sampling. Use attribute sampling only where populations are large (contact data, backup job records), with the confidence and tolerable deviation stated up front.

Answer to management: cover risk, not unit count. Offer a rolling three-year cycle, or a light questionnaire plus walkthrough across all 22 if the board needs a statement about the whole estate, while deep testing stays on the five. Rotation auditor must be supervised and their work reviewed before conclusions are drawn.

Criteria must be suitable (relevant, objective, measurable, understandable) and agreed with management before fieldwork - otherwise every finding is arguable.

Source hierarchy I would use:

1. Binding external requirements - the 99.95% contractual availability commitment, customer contract RTOs, regulator expectations on operational resilience. These are non-negotiable criteria; deviation is a finding.
2. Internal policy and standards - the BCMS policy, plan template, RTOs agreed in the BIA. Internally adopted, therefore binding on management even without any external standard.
3. External frameworks as benchmark only - ISO 22301:2019 clauses on BIA, strategy, plans, exercising and improvement, plus supporting guidance. Use these where internal criteria are silent.

The judgement that matters: I must not grade an organisation against a standard it never adopted as though it were a requirement. Two labels, used precisely:

• Nonconformity - a binding criterion is not met.
• Observation against good practice - the organisation's own criteria are silent and a recognised framework suggests a better approach.

Every test in the programme maps to a named criterion with a source, so a finding can be defended line by line. If management is pursuing certification, the standard becomes binding from that decision, and the criteria set should shift accordingly.

Finally, the stale BIA is a planning risk, not just a finding: if it is unreliable, the criticality ranking underpinning my scope is provisional. Validate criticality independently (dependency maps, contract SLAs, revenue data) before locking scope, and tell the audit committee that scope was set on validated rather than inherited criticality.

Diagnosis: continuity documentation is not linked to change management. A migration of the core platform should have triggered a mandatory review of recovery documentation and a post-change recovery test. Neither happened, so the drift is probably not confined to this runbook.

Programme consequence - widen horizontally. Do not treat this as a single documentation defect. Test every Tier 1 plan for currency against current architecture: technology inventory reconciliation, plan-review dates against change records for the last 12 months, and evidence of a successful recovery test after each material change. The likely finding is a design gap in the change/BCM interface, with individual stale documents as symptoms.

Testing recovery capability, not plan appearance:

• Inspect the runbook against an independent source of current architecture (CMDB, cloud console export) - not against the plan's own appendices.
• Obtain or witness an executed failover, with timings measured against the 2-hour RTO.
• Interview the engineers who would execute it and ask them to locate the steps; plan navigation is part of operability.
• If no post-migration test exists and none can be scheduled before the report date, say precisely that recovery capability is not evidenced, not that it is absent. The two conclusions carry different remediation and different management responses.
• Assess whether the migration contract or cloud provider gives any test rights or published resilience evidence, and whether reliance on it is documented.