OSFI B-13 and E-21 Together: One Program for Tech Risk and Operational Resilience

OSFI did not write B-13 and E-21 to be run by two teams who never speak. Most Canadian FRFIs are about to do exactly that, and the duplicated evidence will cost them more than the compliance ever will.

Guideline B-13, Technology and Cyber Risk Management, has been in force since 1 January 2024. Guideline E-21, Operational Risk Management and Resilience, reaches full effect on 1 September 2026, when institutions are expected to have identified and mapped their critical operations, set tolerances for disruption, and stood up the wider resilience programme. Two guidelines, two publication cycles, two internal sponsors. In most firms that has produced two programmes, two control libraries, and two sets of people documenting the same infrastructure in incompatible ways. That is a design error, and it is fixable before the deadline.

The overlap is not incidental

B-13 is organised around three domains: governance and risk management, technology operations and resilience, and cyber security. E-21 sits a layer up, covering operational risk management, operational resilience, business continuity, crisis management, change management and data risk. Read them side by side and the same objects keep appearing. A cloud provider that B-13 treats as a technology dependency is, in E-21 terms, a third party supporting a critical operation. A cyber incident that B-13 wants detected, logged and contained is, to E-21, a disruptive event that has to be managed within a tolerance and reported to the crisis function. The resilience testing B-13 expects of your technology estate is a subset of the scenario testing E-21 expects across critical operations.

The overlap concentrates in three places: third parties, incidents, and testing. Both guidelines lean on the same underlying third-party regime — OSFI’s Guideline B-10 — so the vendor inventory that feeds one should feed the other. Both require you to detect, respond to and learn from incidents. Both require you to prove, under test conditions, that the firm can keep running or recover when something breaks. If you build those three capabilities twice, you have not doubled your assurance. You have doubled your maintenance and created two versions of the truth a supervisor can hold against each other.

Where two programmes quietly contradict each other

The failure mode is not that a control is missing. It is that the same dependency is described two ways. The B-13 technology-asset register lists a payment processor as a tier-two supplier with a stated recovery objective. The E-21 critical-operations map lists the payment operation it supports as critical, with a tolerance for disruption that is tighter than the supplier’s recovery objective allows. Both documents are internally coherent. Together they say the firm has accepted a recovery target it cannot meet. A supervisor who reads both — and they will read both — finds the contradiction faster than you will, because they are looking across the seam you never joined.

The same thing happens with ownership. If the technology function owns the B-13 evidence and a separate resilience or operational-risk team owns the E-21 evidence, you have two people accountable for the same control and no one accountable for the fact that their answers differ. When the two disagree, escalation has nowhere to go except a committee that meets monthly. This is the reconciliation problem other jurisdictions have already run into — Australian firms have been wrestling with the same seam between CPS 230 operational risk and CPS 234 information security, and the lesson travels: the regulator does not care which of your teams is right, only that the firm speaks with one voice.

One control map, keyed to both

The design that works is a single control environment with a single set of controls, each tagged to the B-13 and E-21 expectations it satisfies. You do not maintain a B-13 control and a parallel E-21 control that happen to overlap. You maintain one control — say, third-party concentration monitoring — and you record that it evidences B-13’s third-party technology-risk expectation and E-21’s critical-operations dependency expectation at the same time. One control, one owner, one piece of evidence, two citations.

Practically, that means three shared foundations. First, one dependency inventory — technology assets and third parties in a single register, each object able to carry both a B-13 classification and an E-21 criticality flag, so the payment processor and the payment operation are linked rather than described in different systems. Second, one incident taxonomy and one incident pipeline, so a cyber event is classified once and flows to both the technology-risk record and the crisis-management process without being re-keyed. Third, one testing calendar, where a resilience test is scoped to satisfy the technology-recovery evidence B-13 wants and the severe-but-plausible scenario testing E-21 wants, rather than two exercises that stress the same systems in the same quarter.

Data risk is the join most firms underweight. E-21 names data risk explicitly; B-13 treats data as a technology asset to be protected. If your model inventory, your data lineage and your critical-operations map are three separate spreadsheets, you will not be able to answer the question both guidelines are circling — what breaks, and what depends on it. This is the same discipline that lets you treat model risk as operational risk rather than a fourth silo: extend the environment you have instead of building another one beside it.

What to have ready before September

By 1 September 2026 the evidence a supervisor can reasonably ask for is concrete. A single dependency register that reconciles technology assets to critical operations, with no orphaned suppliers and no critical operation resting on a dependency whose recovery objective is looser than its tolerance. A named owner for each control, with the B-13 and E-21 citations attached, and a defined path when the two views disagree. An incident that has flowed through one pipeline and shows up correctly in both the technology-risk and crisis-management records. A test whose report answers both guidelines from one exercise. If you can produce those, you have one programme. The detail of the E-21 side, and how it phases into 2027 scenario testing, is set out in our reading of the September 2026 operational resilience provisions.

The firms that struggle in the first supervisory conversation after September will not be the ones missing a control. They will be the ones who documented the same dependency twice and cannot say which version the board actually signed.