OSFI E-21 Scenario Testing: Severe-But-Plausible for Canadian FRFIs

OSFI E-21 does not ask whether you ran a scenario. It asks whether you can show that your critical operations stay inside their tolerances when something plausible and severe goes wrong — and that you keep testing it.

Most of the noise around Guideline E-21 treats scenario testing as an event: book a room, run a tabletop, tick the box, file the deck. That reading misses what supervisors are actually looking for. The compliance artefact is not the one exercise you ran to clear the effective date. It is a maintained, repeatable programme that produces evidence of testing, breaches, findings and remediation over time. Get that distinction wrong and you can pass the date and fail the review.

What E-21 actually expects of scenario testing

OSFI finalised Guideline E-21, Operational Risk Management and Resilience, on 22 August 2024. Its resilience half rests on three linked constructs. A critical operation is a service or product whose disruption would put the institution’s own continued operation or safety and soundness at risk, or harm other institutions through interconnectedness. A tolerance for disruption is the maximum level of disruption that operation can withstand across a range of severe-but-plausible scenarios — which is not the same thing as risk appetite, and firms that conflate the two usually end up with a tolerance that describes normal conditions rather than a crisis. Scenario testing is how you find out whether the operation actually stays inside that tolerance when it is stressed.

The guideline is explicit that scenarios must be severe but plausible, and it names the kinds it has in mind: power outages, large-scale technology failures, cyber incidents, natural disasters and pandemics. It also expects the hard cases — long-duration disruption, concurrent events, and the loss of a critical third party — because those are exactly the conditions a single-cause tabletop tends to avoid. Testing is expected to grow more sophisticated over time, moving from analysis and tabletop through simulation toward live-systems testing where the risk of doing so is itself managed.

The dates, read precisely

The timeline is phased, and reading it loosely is where programmes go wrong. Sections 1 and 2, on operational risk management, applied immediately on publication. Full adherence to Section 4 — business continuity, crisis, change and data risk management — was expected by 1 September 2025. Full adherence to the guideline as a whole is expected by 1 September 2026: by then you should have identified and mapped your critical operations, set their tolerances, and stood up a scenario testing methodology. Completing scenario testing for all critical operations is then expected by 1 September 2027, with testing under way across the intervening period.

So the September 2026 obligation is not “we ran one scenario.” It is “we have a methodology, tolerances are set, and testing is running.” A single exercise completed the week before the date satisfies neither the letter nor what a supervisor will probe. This is also why ownership matters: the programme has to be answerable to senior management and the board, not parked inside a continuity team, a point worth reading alongside board and senior-management accountability under E-21.

Build the scenario as a definition, not a slide

The practical move that turns E-21 from a document exercise into an engineering one is to treat each scenario as a versioned, machine-readable definition tied to a named critical operation and its tolerance. It carries the disruption, the concurrent stresses, the dependencies in scope, and — the part most tabletops omit — explicit pass/fail assertions on recovery time and data loss. That way a run produces a result, not an impression.

# scenario: core-payments-datacentre-loss.yaml
# Severe-but-plausible disruption used to test a critical operation
# against its impact tolerance under OSFI E-21.

critical_operation: retail-payments-processing
tolerance:
  max_disruption: 4h        # maximum outage the operation can withstand
  data_loss_rpo: 15m        # recovery-point objective

scenario:
  name: Primary data centre loss during month-end peak
  trigger: total-site-failure
  duration: 6h              # deliberately exceeds tolerance to test the edge
  concurrent:
    - key-supplier-degraded       # cloud region impaired at the same time
    - staff-absence-30-percent
  dependencies:
    - identity-provider
    - core-banking-ledger
    - sms-otp-gateway

assertions:
  - recovery_time_actual <= tolerance.max_disruption
  - data_loss_actual <= tolerance.data_loss_rpo
  - failover_invoked == true
  - customer_comms_issued_within: 60m

evidence:
  test_type: live-failover        # not a tabletop
  run_date: 2026-05-14
  owner: head-of-operational-resilience
  findings_ref: OR-2026-014

The value is in the assertions and the evidence block. A scenario whose duration deliberately exceeds the tolerance tells you where the operation breaks; a scenario that always passes was set too soft to be useful. And because the definition is a file under version control, every run is dated, owned and referenced to a findings record. If you already run APRA CPS 230, the pattern is the same one set out in our severe-but-plausible disruption library for APRA entities — the constructs travel across both regimes.

Running it against critical operations

E-21 draws a useful line between scenario analysis — assessing impact at a business-unit level — and scenario testing, which validates that critical operations stay within tolerance across business lines under severe conditions. The programme needs both, but the testing is what evidences resilience. Each run should exercise the full dependency chain the operation relies on, including the third parties, and involve those third parties where you can. When a tolerance is breached, that is not a failed test to bury; it is the finding that justifies the remediation, and the pairing of breach and fix is precisely what a supervisor wants to see recur over successive runs.

This is also where E-21 stops being a standalone exercise. The dependency mapping that scenario testing consumes is the same estate that technology and cyber risk governance covers, which is why it pays to run the two as one programme rather than two — the case we make for treating B-13 and E-21 as a single programme rather than parallel tracks.

The evidence a review will actually ask for

Assume a supervisory assessment and work backwards from what it opens with. Show the list of critical operations and how it was derived. Show each operation’s tolerance and the reasoning behind the number, not just the number. Show the scenario definitions, the run dates, and the results against the assertions. Show the breaches, the findings raised, and the remediation closed or in train. Show that the methodology has been reviewed and that testing has grown more demanding over time. If the trail exists and coheres, you are in a defensible position. If you have one polished exercise and nothing behind it, you have theatre, and OSFI has signalled it will run selective assessments through the phased period rather than wait for the final date.

Treat scenario testing as a standing programme with an owner, a cadence and a record, and the September 2026 obligation is a by-product of running it. Treat it as a date to clear, and you will clear the date and still be exposed the first time a supervisor asks what you did after the last one broke.