Severe but plausible scenarios that expose assumptions
A tabletop exercise is useful only if it tests the ability to deliver an important business service within its impact tolerance. A comfortable workshop in which participants read familiar plans and declare success is not evidence of resilience. A good exercise creates a credible failure, lets the decision-makers respond and records where the plan, resources and actual timings diverge.
For in-scope firms, SYSC 15A requires a testing plan and scenario testing across an appropriate range of adverse circumstances. The FCA has also emphasised involving communications arrangements and capturing weak recovery assumptions in its March 2026 observations.
Design from the service and its tolerance
We start with the service outcome: for example, the continued ability to process a specified type of customer instruction. The workshop then establishes the harm threshold and time profile; dependencies that can fail together; people authorised to activate contingency processes; and evidence that could show whether the service stays inside tolerance. The scenario should challenge a real vulnerability rather than a generic “cyber attack” storyline.
Example exercise: cloud provider and authentication unavailable
At 09:15 the customer application is unavailable. By 09:40 the team learns the identity provider supporting emergency administration is also degraded. At 10:20 the alternative contact channel fails because it shares a supplier. The facilitator asks how customer harm is assessed, what communications are authorised and whether an alternate route genuinely works. The timings are illustrative exercise injects, not an assertion about any client’s recovery ability.
Other test conditions can include data corruption, unavailability of specialist staff, inability to use the main office, a settlement dependency failure, or an important supplier’s prolonged outage. One exercise cannot prove all services or scenarios are controlled.
The deliverables after testing
Expect a scenario design and assumptions log, participant list, inject chronology, observed decision record, tolerance assessment, evidence limitations, vulnerabilities, assigned actions and retest criteria. Findings should flow into the wider resilience programme. A test declared “passed” while serious issues remain unowned can create false assurance.
Selecting the right exercise depth
Workshops, simulations and controlled technical tests have different costs and risks. We agree the level appropriate to the service and available systems. Live production disruption and specialist red-team testing require separate controls and competent delivery providers; neither should be implied by a standard tabletop price.
Worked scenario design: loss of an outsourced payments processor
This is a fictional exercise example, not a customer case study. A payment institution depends on a third-party processing gateway, cloud identity provider and internal reconciliation team to deliver an important payment service. In the scenario, the processor first slows, then becomes unavailable. Shortly afterwards the usual incident collaboration system also becomes inaccessible.
| Exercise moment | Inject to participants | Evidence to capture |
|---|---|---|
| Detection | Transaction failures exceed normal levels | Trigger, detection source, time, initial impact estimate |
| 20 minutes | Processor advises uncertain restoration estimate | Supplier escalation record, decision maker, alternatives |
| 45 minutes | Customer contact channels experience a spike | Consumer harm indicators, communications approval, accessibility |
| 90 minutes | Reconciliation backlog grows and a workaround is considered | Control and fraud risks, workaround capacity, rollback criteria |
| After exercise | Supplier restoration is announced | End-to-end settlement/reconciliation validation, unresolved actions |
The timestamps above are exercise injects only, not regulatory deadlines, impact tolerances or proof of acceptable recovery. The exercise designers must set timing and severity against the firm’s own services, risk profile and plausible disruption scenarios.
How to distinguish an exercise from evidence of resilience
Record the assumptions that were simulated, the actions participants actually took, dependencies not exercised, time measurements, confidence limits and disagreements between teams. A tabletop exercise cannot by itself prove recovery time for a real system. An impactful finding could be that fallback communication relies on the same identity provider that failed; the remediation may be to establish independently accessible channels and test them later.
A report should give leadership enough evidence to challenge whether a service could remain within its actual impact tolerance—not merely state that attendees participated successfully.
Practical template to use with your team
- Download the scenario observation log — adapt, verify and approve before operational use.
Frequently asked questions
Is a tabletop enough for FCA operational resilience?
Not necessarily. The mix of testing should be proportionate to the relevant risks, services and rules, and must be sufficient to provide credible assurance.
Does every important service need testing?
In-scope firms must assess their ability to remain within tolerances for each important service. The test plan should explain coverage and scenario selection.
Can a third party run testing for us?
Yes, but the regulated firm remains responsible for the quality and accuracy of its testing evidence.
Full worked example and test arithmetic
Our payments-processor disruption simulation calculates a hypothetical rising instruction backlog at 0, 60, 120, 180 and 240 minutes, examines a limited fallback, and demonstrates how non-technology weaknesses feed into board-level remediation. Every input is explicitly fictional, documented and reproducible in the CSV.
This teaches the format of credible evidence, rather than claiming the firm has tested any actual client’s systems.