OSFI E-21 Accountability: Board and Senior-Management Ownership of Operational Resilience

OSFI Guideline E-21 makes operational resilience a governance obligation, not an operations task. That single shift is what most implementation programmes have failed to price in, and it is the part a supervisor will test first.

Guideline E-21, Operational Risk Management and Resilience, was finalised on 22 August 2024. Its governance and operational-risk sections took effect on publication; full adherence to the guideline is expected by 1 September 2026, by which point a federally regulated financial institution should have identified and mapped its critical operations and set tolerances for disruption. Scenario testing across all critical operations is expected to be complete by 1 September 2027. Those dates are the visible part. The part that catches boards out is quieter: E-21 does not treat resilience as something the technology function does and reports upward. It treats it as something the board and senior management are answerable for, by name.

What E-21 actually assigns, and to whom

Read the guideline carefully and the accountability split is more precise than the headlines suggest. Senior management holds ultimate accountability for an effective operational risk management framework and approach to operational resilience — that it is properly governed, documented and implemented. The board’s role is oversight: it comes through OSFI’s Corporate Governance Guideline, which puts the board over risk appetite, strategy and the supervision of senior management and internal controls. So the accurate statement is not “the board owns resilience.” It is that senior management owns it operationally, and the board owns whether senior management is doing so competently.

That distinction matters because it determines what a director is on the hook for. A director is not expected to have set a tolerance for a payment rail personally. A director is expected to be able to show that the tolerances exist, that they were set deliberately rather than reverse-engineered from current capability, that testing has challenged them, and that the board saw the results and did something when they were breached. If your board minutes cannot demonstrate that chain, the guideline’s governance expectation is not met, whatever the operations team has built underneath.

Three questions a board should be able to answer cold

The useful test of whether a board genuinely owns resilience is whether its directors can answer three questions without turning to management for the answer.

1. Who owns each tolerance for disruption? A tolerance is the maximum level of disruption the institution can withstand under a range of severe-but-plausible scenarios. There should be a named accountable executive for each critical operation’s tolerance, not a committee and not “IT”.
2. Who signs off the testing, and against what? Scenario testing has to assess whether critical operations can be kept within tolerance during a severe disruption. Someone has to attest that a given test was severe enough and that its result is credible. That sign-off is a decision right, and it should be documented as one.
3. How does the board see resilience posture between incidents? Not after a failure — routinely. If the only time resilience reaches the board is in an incident post-mortem, the board is not overseeing it.

These are the same three questions a supervisor works towards in an engagement, arriving from a different direction. Getting them settled internally before September is considerably cheaper than settling them under examination. The mapping of who holds which right is the substance of the September 2026 operational resilience provisions, and it is worth doing as an explicit exercise rather than assuming the existing org chart already answers it.

A tolerance is a board-level decision, not a technical output

The most common failure I see is a tolerance set by the people who run the system rather than the people who bear the consequences of it failing. When engineering sets the tolerance, the number quietly becomes a description of what the system can currently do — recovery in four hours because that is what the current architecture achieves. That is not a tolerance. It is a status report wearing a tolerance’s clothes.

A real tolerance is a statement of how much disruption to a critical operation the institution — its customers, its counterparties, the financial system it sits in — can absorb before the harm becomes unacceptable. That is a judgement about risk appetite, and risk appetite belongs to the board. The technology function’s job is to tell the board, honestly, how far current capability sits from that tolerance and what closing the gap costs. When the two diverge, that gap is precisely the thing the board is meant to own the decision about: invest, accept, or reduce the criticality. Setting the tolerance to match current capability makes the gap disappear on paper and leaves it entirely intact in reality.

The evidence a supervisor will ask for

OSFI expects senior management and the board to receive the results of scenario analysis and testing, including analysis of deficiencies and an assessment of whether critical operations can be maintained within tolerance. “Receive” is doing real work in that sentence. It implies a reporting cadence, a format the board can actually interrogate, and a record that the board considered it. In practice a defensible position looks like this:

• An inventory of critical operations with mapped internal and external dependencies, dated and version-controlled.
• A tolerance for each, with the accountable owner and the board or committee approval recorded.
• Scenario testing results showing where operations held within tolerance and where they did not, with the severity assumptions stated.
• A remediation trail for every breach — what was decided, by whom, by when.
• Board or committee minutes showing the above was seen and challenged, not merely tabled.

The reporting design is the hard part, and it is the same problem EU firms have been working through since DORA — turning resilience into something a board can genuinely oversee rather than nod through. The shift DORA forced in board reporting is a useful reference precisely because it exposes how much of what boards previously received was reassurance rather than evidence. The severe-but-plausible testing standard is where the reporting either earns its place or is exposed as theatre.

Why the accountability framing is not a formality

Supervisors across jurisdictions have been steadily moving resilience and cyber from a collective operational concern to a named-individual one, and the personal-liability direction of travel for boards is unlikely to reverse. E-21’s governance section sits squarely in that current. The point of naming an accountable owner for a tolerance is not bureaucratic tidiness; it is that a control with no owner is a control nobody maintains, and a supervisor who cannot find the owner concludes there is no control.

By 1 September 2026 the tolerances and mapping are expected to be in place; by 2027 the testing that proves them. A board that spends the intervening time deciding, honestly, what it is willing to withstand will be in a defensible position. A board that waits for management to hand it a finished framework to approve will discover, too late, that approving is not owning — and that under E-21 the distinction is the whole point.