OSFI E-21 and B-10: operational resilience and third-party risk for Canadian FRFIs

Canadian federally regulated financial institutions now have to prove that their critical operations survive severe but plausible disruption, including the failure of a third party, not just that they have controls on paper. Two OSFI guidelines carry most of that weight: Guideline E-21, Operational Risk Management and Resilience (issued in 2024), and Guideline B-10, Third-Party Risk Management (April 2023). This guide explains what each one expects, how they fit together, the dated transition milestones and the practical work for security, resilience and vendor risk teams. It is written for CISOs, operational resilience leads, third-party risk managers and the technology teams who have to produce the evidence. Technology and cyber controls themselves sit in Guideline B-13 and are covered in the OSFI Guideline B-13 Guide; this page covers the resilience and third-party layer around it.

Status checked 9 November 2026: OSFI's guideline pages list E-21 as dated 22 August 2024 and B-10 as dated 30 April 2023 (page last modified 20 February 2024). OSFI's E-21 letter set full adherence for the whole guideline by 1 September 2026 and scenario testing of all critical operations by 1 September 2027. The B-10 effective date relies on law firm commentary (Torys and Blakes), because OSFI's guideline page does not state it. Confirm against the official text before relying on it.

Key takeaways

• E-21 is now in full effect: by 1 September 2026 FRFIs were expected to have identified and mapped critical operations, set tolerances for disruption and begun scenario testing, with testing of every critical operation due by 1 September 2027.
• B-10 covers every third-party arrangement: not just outsourcing, but any business or strategic arrangement "by contract or otherwise", scaled by risk and criticality.
• The two guidelines share one spine: critical operations, severe but plausible scenarios and exit or contingency plans appear in both, so one inventory and one dependency map should serve both.
• Accountability does not transfer: B-10 Principle 1 says the FRFI is ultimately accountable for all third-party arrangements, including outsourced services and data.
• Identities are dependencies: the service accounts, API keys and OAuth grants that connect a provider to your systems belong in the critical operation map and in every exit plan.

Who is covered and how the guidelines fit together

Both guidelines apply to all FRFIs: banks, foreign bank branches, trust and loan companies, life insurance and fraternal companies, property and casualty insurers, foreign insurance branches and, for E-21, cooperative credit associations. Branches apply them to the extent consistent with their Canadian legal requirements, with branch expectations set out in Guideline E-4. Both are explicitly proportional: intensity scales with size, complexity, risk profile and, for B-10, the criticality of each arrangement.

E-21 names B-10 in its overview and in Sections 3.2, 4.1.3 and 4.6, and B-10 lists E-21, B-13 and the Corporate Governance Guideline as related guidance. Read them as one system: E-21 tells you which operations matter and how much disruption you can absorb; B-10 tells you how to manage the third parties those operations depend on; B-13 tells you what technology and cyber controls must exist on both sides.

E-21: the operational risk management half

E-21 has four numbered sections after its overview: 1 Governance, 2 Operational risk management, 3 Operational resilience and 4 Key areas supporting resilience. OSFI states three outcomes: operational risk management supports resilience, operational risks stay within approved appetite and limits, and critical operations continue through disruptions.

• Governance (Section 1): senior management is ultimately accountable for the framework and resilience approach and escalates tolerance breaches to the board. The guideline describes business and central functions, independent oversight (1.3) and independent assurance (1.4), which most institutions will recognise as their three lines.
• Risk appetite (2.2): a defined appetite for operational risks, which is typically tighter than the tolerance for disruption.
• Risk management tools (2.3): risk and control self-assessments, key risk indicators, operational risk event data analysis and scenario analysis.
• Monitoring and reporting (2.4): the board receives timely reports on the risk profile, limit breaches, accepted residual risks and scenario test results.
• Key supporting areas (Section 4): business continuity, disaster recovery, crisis management, change management, technology and cyber risk, third-party risk and data risk.

For security teams the practical change is that cyber events become operational risk events in the institution's loss and event data. A credential leak that caused no loss is still an event worth recording, because E-21 expects event data analysis to surface control weaknesses before they cause a breach of appetite.

E-21: the operational resilience half

Section 3 is where most new work sits. It has three parts, and the definitions matter.

OSFI's examples of scenarios include power outages, large-scale technology failures, critical third-party disruptions, cyber incidents, natural disasters and pandemics. For a cyber team, the useful scenarios are specific: ransomware that encrypts the core banking environment and its backups, compromise of a privileged identity provider, loss of a payments processor, or a stolen cloud access key used to delete production resources. Each should test a named critical operation against its tolerance, not a technology component in isolation.

The UK and EU have similar regimes, which helps multinational groups reuse work. See the UK Financial Operational Resilience Guide and the DORA Guide for those layers.

B-10: third-party risk across the lifecycle

B-10 defines a third-party arrangement as any business or strategic arrangement with an entity or individual, by contract or otherwise, excluding customer relationships and employment contracts. That breadth catches SaaS subscriptions, cloud platforms, data feeds, AI model APIs, group affiliates and arrangements with no written contract at all. The guideline sets six outcomes and organises its principles across governance, risk management and technology and cyber.

Contracts, notifications and exit

Annex 2 lists provisions expected in high-risk and critical agreements, including roles and responsibilities for technology and cyber controls, subcontractor parameters and notice, security of records and data, notifications to the FRFI, business continuity and recovery with testing, and termination terms that return assets and data in a usable format without impeding OSFI or resolution authorities. B-10 expects providers' technology and cyber incident notices to support the FRFI's own reporting under OSFI's Technology and Cyber Security Incident Reporting Advisory, and expects OSFI to be notified promptly of substantive issues affecting critical operations because of a third-party arrangement.

Exit and contingency plans (2.3.5) should name triggers, include both a stressed exit playbook (provider failure or insolvency) and a non-stressed one (planned exit), and have enough detail on alternatives, timelines, costs and interim workarounds to run quickly. See the Cloud Exit Plan Template.

Cloud and standard contracts

Sections 4.3 and 4.4 ask for cloud-specific requirements covering data protection, key management and container management, supported by cloud governance and monitoring, and for portability to be considered when entering cloud arrangements, with multi-cloud design named as one way to reduce concentration risk. Where terms cannot be negotiated, Section 3.1 expects the institution to assess and formally accept the residual risk. See the Cloud Concentration Risk and Exit Strategy Guide.

Where identity fits

Neither guideline mentions non-human identities by name, but both require you to map and control the connections that make a dependency real. In most institutions those connections are machine credentials. NHI Mgmt Group recommends treating them as first-class items in both programmes:

• Map identities into critical operations: for each critical operation, list the service accounts, workload identities, API keys, certificates and OAuth grants it depends on, and which provider holds or issues them. An expired certificate or revoked token is a disruption scenario in its own right.
• Put provider access in the B-10 inventory: every third party with standing access to your environment, including support access and integration tokens, should be visible in the inventory with its scopes. See the Third-Party Risk Management Guide.
• Write credential steps into exit plans: a stressed exit means revoking the provider's credentials, rotating any secrets it ever held and reissuing keys for the replacement, all inside the tolerance for disruption.
• Treat AI services as third parties: model APIs and agent platforms are arrangements under B-10, and agent credentials that reach critical systems belong on the E-21 map. See the Non-Human Identity (NHI) Guide.

Implementation roadmap

The 2026 milestone has passed, so most institutions are now in evidence and testing mode. A practical sequence, our recommendation rather than OSFI text:

1. Confirm the critical operations list: check it is board-approved, owned, and still accurate after any 2026 product or platform changes.
2. Close mapping gaps: walk each map end to end and add missing third parties, data flows and machine identities. Use SSO, OAuth consent, firewall and procurement data to find what interviews missed.
3. Reconcile the B-10 inventory with the maps: every third party on a critical operation map should be rated critical or high risk in the inventory, and the reverse check should explain any critical provider not on a map.
4. Express tolerances as metrics: outage minutes, transactions lost or customers affected, tied to recovery time and recovery point objectives in the DR plans.
5. Build a test calendar to September 2027: schedule every critical operation, starting with those that depend on a single provider or a single identity system. Start with tabletop tests and move to technical failover.
6. Refresh critical contracts: on each renewal, check Annex 2 provisions, incident notice times that support 24-hour reporting, subcontractor notice and data return.
7. Test exit plans: run at least one stressed exit tabletop per year for the most concentrated provider, including credential revocation.
8. Report and remediate: send scenario results and tolerance breaches to the board with owners and dates, and track them to closure.

To roll back safely, keep the previous DR and continuity arrangements in force until the new failover path has passed a test, and report any accepted residual risk to the board, as E-21 Section 2.4.2 expects.

Decision guidance

• How many critical operations: fewer, well-mapped operations beat a long list nobody can test. Large banks may need more; a small insurer may have a handful. Proportionality applies.
• Tabletop or live test: tabletops suit early cycles and scenarios too risky to run live (core system loss); live failover proves recovery times. Use both over the cycle to 2027.
• Non-negotiable contracts: where a hyperscaler or SaaS provider offers standard terms, document formal risk acceptance and compensate with monitoring, assurance reports and a stronger exit plan rather than leaving gaps unrecorded.
• Single provider or multi-provider: B-10 names multi-cloud as one option to reduce concentration risk, not a requirement. Weigh the operational complexity and the larger credential estate it brings against portability.

Framework mapping

Detection and measurement

• Mapping coverage: percentage of critical operations with a complete map that includes third parties and machine identities.
• Testing progress: critical operations tested against tolerance, against the 1 September 2027 target.
• Tolerance breaches: number of tests or real events that exceeded tolerance, and time to remediate.
• Inventory accuracy: third parties found through SSO or OAuth discovery that were missing from the B-10 inventory.
• Contract currency: share of critical arrangements with Annex 2 provisions and incident notice clauses in place.
• Provider incident notice time: median hours from provider detection to your notification, compared with your reporting obligations.

Common failure patterns

• Maps that stop at the application: the map shows the core system but not the identity provider, key management service or integration tokens it cannot run without.
• Two inventories that disagree: resilience and procurement keep separate lists, so a critical provider is rated low risk in the B-10 inventory.
• Tolerances copied from RTOs: technology recovery targets are pasted in as tolerances without asking how much customer harm the operation can absorb.
• Testing components, not operations: DR tests prove a database fails over but never show the end-to-end service stays within tolerance.
• Exit plans without credentials: the plan covers data return and a replacement provider but not revoking access and rotating secrets the outgoing provider held.
• Fourth parties ignored: a provider's subprocessor holds your data or keys and is absent from due diligence.

Practitioner checklist

• Confirm the board-approved list of critical operations and an owner for each.
• Complete end-to-end maps including third parties, data and machine identities.
• Set measurable tolerances for disruption and link them to DR objectives.
• Schedule scenario tests so every critical operation is tested by 1 September 2027.
• Reconcile the B-10 inventory with the critical operation maps.
• Check Annex 2 provisions and incident notice terms on every critical contract at renewal.
• Write stressed and non-stressed exit playbooks that include credential revocation.
• Record formal risk acceptance for non-negotiable standard contracts.
• Report scenario results and tolerance breaches to the board with remediation owners.

Standards and references

• OSFI: Guideline E-21, Operational Risk Management and Resilience
• OSFI: Operational Risk Management and Resilience, Letter
• OSFI: Guideline B-10, Third-Party Risk Management
• Torys: OSFI B-10 Third-Party Risk Management
• Blakes: OSFI's New Guideline B-10, Third-Party Risk Management
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev 5, Security and Privacy Controls

Related NHI Mgmt Group resources: OSFI Guideline B-13 Guide · Third-Party Risk Management Guide · Business Continuity and Disaster Recovery Guide · Operational Resilience Executive Briefing. This guide summarises OSFI Guidelines E-21 and B-10 as they stood on 9 November 2026 and is not legal advice.