The executive decision at stake is straightforward but often misunderstood: do we approve staged transition (contracted cutover, supplier‑run services or phased go‑live) given the evidence before us? Too often the answer rests on uptime dashboards, integration test reports and an IT service acceptance letter. Senior leaders must instead require demonstrable business continuity under realistic degraded conditions — testable scenarios that prove the service can operate when automation, suppliers or primary datasets fail.
The specific decision SROs and boards must make
When a programme asks for approval to transition a live service in stages, the board is deciding whether residual operational risk is acceptable and commercially manageable. That decision must be based on evidence that the organisation — its staff, suppliers and processes — can sustain critical functions at the levels required by the business case and statutory obligations when things go wrong during or immediately after cutover.
Ask: does the acceptance pack prove the service works only in ideal conditions, or does it prove the service survives degraded modes (partial data loss, supplier unavailability, failed batch jobs, manual process failover)? The difference determines whether the programme is moving risk into operations or actually reducing it.
Why this problem keeps recurring in delivery
Delivery teams focus on technical integration, configuration and green‑path tests because those are measurable and often scheduled. Business continuity — staffed workarounds, cross‑supplier coordination, reconciliation after partial migrations, and human decision points — is treated as a maintenance concern or left to post‑go‑live stabilisation. That disconnect exists because continuity requires system, process and staffing evidence to be composed into operational scenarios; it is harder to automate and harder to contract.
Three systemic causes repeat across programmes: (1) requirements and acceptance criteria are specified for components not for end‑to‑end degraded modes; (2) supplier contracts lack testable obligations for participation in continuity exercises and for reversibility; (3) governance separates the business continuity function from cutover responsibility, so no single team owns the continuity acceptance artefact.
How continuity, systems, people and suppliers interact through the lifecycle
Discovery and design: identify critical services, enumerating the processes, data flows, people and supplier touchpoints that make them work. Map minimum acceptable service levels (MASLs) and identify which elements are single points of failure.
Build and test: include negative and degraded scenarios in the integration test plan — partial data, delayed feeds, missing microservices, database schema rollbacks. Tests must be run end‑to‑end with the teams who will operate the live service.
Cutover readiness and acceptance: acceptance is conditional. For each critical service require (a) continuity scenario scripts, (b) staffed execution plans and trained teams, (c) cross‑supplier runbooks with confirmed contacts and commercial remedies, and (d) one or more live‑data dry runs or shadow runs proving reconciliation and recovery.
Stabilisation and BAU transition: handover artefacts must include audited logs, reconciliation reports, runbooks, and supplier compliance evidence. Acceptance must be reversible — proving the path back to the previous state if essential continuity safeguards fail.
Concrete artefacts senior leaders should demand
Continuity Scenario Ledger: a service‑level ledger listing each critical service, its MASL, ranked failure scenarios, owner for each scenario, and the exact acceptance test for that scenario.
Scenario Test Scripts and Evidence Pack: scripts that include inputs, expected outputs, reconciliation checks, data volumes and timing; test evidence includes logs, reconciliation outputs, and an accountable operations sign‑off.
Staffed Failover Exercise Records: exercise rosters showing staff who executed the manual workarounds, the time taken, error rates and issues raised. Exercises must be observed by independent assurance and be repeatable.
Cross‑Supplier Continuity RACI and Contact‑Backed Runbooks: runbooks showing step‑by‑step actions across supplier boundaries, SLA/SLI references, and contractual clauses that make suppliers participate in continuity exercises and share forensic evidence.
Reversibility and Data Evacuation Proofs: evidence of the ability to roll back changes, and of data evacuation/export tests that include integrity and reconciliation checks.
Decision Gate Checklist: a signed checklist for the board/SRO that maps each MASL to test evidence, outstanding risks, mitigation actions and conditional approvals (for example, “approve stage 1 only if supplier X completes exercise Y within 10 working days”).
Failure modes leaders must spotlight and how to test them
Silent degradation: performance metrics look acceptable but reconciliation shows data drift. Test by injecting delayed feeds and verifying business reconciliations over realistic windows.
Supplier partial failure: a third‑party microservice returns intermittent errors. Test by simulating supplier latency/failure and executing the cross‑supplier runbook including supplier escalation paths and commercial penalties.
Manual handover bottleneck: processes require an unscalable manual step that becomes a single point of failure. Exercise the staffed failover with the rostered team size and measure throughput and error rate.
Data migration incompleteness: subset of records fail mapping rules. Run live‑data dry runs with production‑representative extracts and verify automated and manual reconciliation operations.
Reversibility failure: rollback cannot restore consistent operations. Test rollback in a staged environment with production‑representative data and ensure rollback scripts and runbooks produce an auditable state.
What good governance looks like for this acceptance decision
Boards should require conditional approvals. Approve staged transition only when required scenario tests pass or when the board accepts specific residual risks with explicit mitigations and timelines. The board pack must map each outstanding risk to a named owner, mitigations, and contractual levers.
Evidence must be objective, machine‑readable where possible (test results, reconciliation outputs, runbook versions), and retained in an immutable ledger so post‑cutover incidents can be traced to the acceptance artefacts that approved or deferred risk.
Where statutory or sectoral standards apply (for example ISO 22301 or NCSC CAF outcomes), the board pack should show how scenario tests and artefacts map to those standards rather than asserting compliance in the abstract.
Acceptance is not a single certificate — it is a portfolio of testable, staffed scenarios that prove the organisation can keep the service running when a supplier, dataset or automation fails.
Antares recommended actions
These are Antares's recommended first actions for organisations turning the issues in this article into practical governance and delivery.
- Require a Continuity Scenario Ledger in the acceptance pack: map each critical service to a minimum acceptable service level (MASL), ranked failure scenarios and the exact test that will prove survivability. Do not accept qualitative statements—insist on specific test scripts and measurable success criteria.
- Condition staged transition approvals on at least one full staffed exercise per critical service that uses production‑representative data or a live‑data dry run. If exercises fail, require corrective evidence and re‑execution before the next stage.
- Make suppliers contractual participants in continuity tests and reversibility proofs: require written confirmation of participation, contact‑backed runbooks, and contractual remedies tied to exercise non‑performance. Where suppliers refuse, escalate to the commercial lead for immediate remedial action.
- Map acceptance evidence to standards and decision artefacts: show how each scenario/test maps to ISO 22301 expectations and, where applicable, NCSC CAF outcomes and Green Book value assumptions. Use the mapping to convert audit or regulator questions into test evidence.
- Use conditional board approvals with precise remediation triggers: approve a stage only if specific tests pass OR if named mitigations are in place with fixed deadlines and independent assurance. Record the decision with the decision gate ledger and require monthly evidence updates until mitigation is closed.
Our insights are provided for general information only and reflect the position at the date of publication. They do not constitute legal, financial, regulatory, cybersecurity or other advice tailored to your circumstances and should not be relied upon as a substitute for appropriate professional advice.
While we take reasonable care over our content, we do not guarantee that it is complete, accurate or current. Reading our insights does not create a client relationship with Antares Consultancy. To the fullest extent permitted by law, we accept no liability for decisions made or losses arising from reliance on this content. External links are provided for convenience and do not imply endorsement.
