Join our Newsletter — 33% off our NHI Course
Home› Guides› OSFI Guideline B-13 Guide: Three Domains, 17 Principles…
Guide Regulations & Frameworks

OSFI Guideline B-13 Guide: Three Domains, 17 Principles and Supervisory Evidence

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 27 October 2026 12 min read
On this page

OSFI Guideline B-13 sets out how Canada's federally regulated financial institutions are expected to manage technology and cyber risk, and since 1 January 2024 supervisors have assessed banks, insurers and trust companies against its 17 principles. B-13 is short and outcome-based: it does not prescribe controls by number, so institutions have to show how their own frameworks meet each expected outcome. It sits in a set of OSFI guidance that now also includes B-10 on third-party risk, the 24-hour technology and cyber incident reporting advisory and E-21 on operational risk and resilience, whose full adherence date was 1 September 2026. This guide covers scope, the three domains and 17 principles, how the companion guidance fits, supervisory consequences, the identity and machine credential expectations, and a phased compliance plan. It is for CISOs, technology risk, internal audit and identity teams at FRFIs and their technology providers; for other jurisdictions see the Financial Services Cyber Regulation Map.

Status checked 27 October 2026 against the OSFI guidance library. B-13 was last updated on the OSFI site on 20 February 2024 and no newer version was found. This page is not legal advice.

Key takeaways

  • Effective since 1 January 2024: OSFI issued the final guideline on 13 July 2022 and gave institutions until 1 January 2024 to self-assess and comply.
  • Three domains, 17 principles: governance and risk management, technology operations and resilience, and cyber security, each with a stated outcome that supervisors test against.
  • Identity is named explicitly: section 3.2.7 expects risk-based identity and access controls including MFA and privileged access management, with MFA across external-facing channels and privileged accounts and vaulted privileged credentials where feasible.
  • Third parties live in B-10: third-party and cloud detail moved out of the B-13 draft into Guideline B-10 (April 2023), which cross-references B-13 for technology and cyber controls at providers.
  • Incidents go to OSFI within 24 hours: the incident reporting advisory requires written notice within 24 hours, or sooner if possible, to the Technology Risk Division and the Lead Supervisor.

Scope: who and what is covered

ElementPositionSource
InstitutionsAll federally regulated financial institutions (FRFIs): banks, federally regulated trust and loan companies, life and property and casualty insurers, cooperative credit associationsB-13 scope
Foreign branchesForeign bank branches and foreign insurance company branches, to the extent consistent with their requirements in Canada; branch expectations in Guideline E-4B-13 scope
ApproachRisk-based, no one-size-fits-all; read in proportion to size, nature, scope and complexityB-13 purpose; July 2022 letter
Third partiesArrangements governed by B-10; B-13 expectations apply to the institution's oversight of themB-10 section 4

Provincially regulated credit unions and insurers are supervised by provincial regulators, not OSFI, though several provinces reference similar expectations. Pension plans have separate OSFI guidance.

Key obligations

Domain 1: Governance and risk management

PrincipleSectionExpectationEvidence supervisors ask for
11.1 Accountability and organisational structureNamed senior officers accountable for technology and cyber risk, with adequate structure and resourcesMandates, organisation charts, board reporting
21.2 Technology and cyber strategyMeasurable strategy aligned with business strategyStrategy document, KPIs, funding
31.3 Risk management frameworkFramework that sets risk appetite and covers identification, assessment, management, monitoring and reportingRisk appetite statements, risk registers, three lines of defence roles

Domain 2: Technology operations and resilience

PrincipleSectionExpectation
42.1 ArchitectureArchitecture framework supporting secure-by-design and resilience-by-design
52.2 Asset managementCurrent inventory with classification, configurations, secure disposal and technology currency
62.3 Project managementEnterprise governance of technology projects from start to close
72.4 System development life cycleSecurity in every phase, including Agile and DevSecOps; acquired systems assessed
82.5 Change and release managementControlled changes with segregation of duties and traceability
92.6 Patch managementTimely, controlled patching through change and testing processes
102.7 Incident and problem managementIncidents detected, managed and reported; root causes investigated
112.8 Service measurement and monitoringService targets and capacity monitored and remediated
12, 132.9 Disaster recoveryEnterprise DR programme covering dependencies and backups, tested against severe but plausible scenarios

Domain 3: Cyber security

  • Principle 14, Identify (3.1): threats, vulnerabilities, data and risk profiles identified, including through threat intelligence, threat modelling and awareness. Section 3.1.2 expects regular tests and exercises to find vulnerabilities or control gaps, including penetration testing and red teaming with an intelligence-led approach. See the Threat-Led Penetration Testing Guide.
  • Principle 15, Defend (3.2): multi-layer preventive controls: secure design, cryptography, protection of critical assets, data protection, patching, identity and access, configuration baselines and physical access.
  • Principle 16, Detect (3.3): continuous, centralised logging and detection that supports monitoring, alerting and forensics.
  • Principle 17, Respond, recover and learn (3.4): incident response with a taxonomy, playbooks, a response team and forensic and root cause analysis, including incidents at third parties.

Companion guidance

InstrumentDateWhat it adds to B-13
Technology and Cyber Security Incident Reporting advisoryEffective 13 August 2021Report within 24 hours or sooner, regular (for example daily) updates, post-incident review
Guideline B-10, Third-Party Risk ManagementPublished April 202311 principles; inventory by risk and criticality, subcontracting, technology and cyber controls at providers, incident notice from providers, stressed and non-stressed exit playbooks
Guideline E-21, Operational Risk and ResilienceFinal 22 August 2024; full adherence by 1 September 2026Critical operations, tolerances for disruption and the operational resilience frame B-13 and B-10 sit in
Cyber Security Self-AssessmentOSFI toolStructured self-assessment referenced alongside B-13

An incident is reportable under the advisory if it has any one of the listed characteristics, which include impact on other FRFIs or the financial system, disruption of payments or settlement, customer data impact, a critical system outage, disaster recovery activation, reporting to the board, senior management, other regulators or law enforcement, a cyber insurance claim, a high or critical internal severity rating, or a breach of risk appetite. OSFI encourages notice when in doubt. The advisory's examples include an account takeover botnet campaign and a material third-party breach.

Timeline and current status

DateEvent
August 2021Revised incident reporting advisory in effect (replacing the 2019 version)
November 2021Draft B-13 consulted with five domains
13 July 2022Final B-13 issued with three domains
April 2023Final revised B-10 published
1 January 2024B-13 effective
22 August 2024Final E-21 published; governance and operational risk sections apply immediately
1 September 2026E-21 full adherence and operationalisation expected

With E-21 now fully in force, supervisors can be expected to look at B-13 controls through the lens of critical operations and tolerances for disruption: which technology and cyber controls protect each critical operation, and whether recovery testing proves the tolerance can be met. Check the OSFI guidance library for revisions before each annual review.

Enforcement and penalties

B-13 is a guideline: it sets OSFI's expectations rather than statutory duties with fixed fines. Shortfalls are handled through supervision, and the consequences can still be significant.

  • Supervisory findings: deficiencies against B-13 appear in supervisory letters with required remediation and deadlines, and feed the institution's risk rating.
  • Intervention staging: OSFI's Guide to Intervention for deposit-taking institutions (issued April 2026) runs from Stage 0 (normal) through Stage 1 (warning) and Stage 2 (material) to Stage 3 (serious) and Stage 4 (take control). Stage 1 can bring more frequent information requests, independent reviews or an on-site monitor; Stage 2 can include removing directors or senior officers, business restrictions and a direction of compliance.
  • Directions of compliance: the Superintendent can direct an institution to stop unsafe practices or take remedial action; OSFI's own example is directing an institution to engage a third-party expert after a major operational disruption.
  • Administrative monetary penalties: available for late or erroneous regulatory filings and breaches of specific statutory provisions, not for guideline gaps as such.
  • Suitability: OSFI can act on the suitability of directors and senior officers, which matters given Principle 1's named accountability.

What it means for AI agents and non-human identities

B-13 names identity and access management as a defend control, and machine identities are where most FRFIs have the least evidence. The asset, change, logging and third-party principles all depend on knowing which service accounts, keys, certificates and agents exist and who owns them.

  • Privileged machine credentials: section 3.2.7 expects privileged access management and, where feasible, vaulted privileged credentials. That includes service accounts with administrative rights, CI/CD deployment credentials and cloud roles. See the Privileged Access Management Guide and the Service Account Security Guide.
  • MFA where machines cannot use it: MFA across external-facing channels and privileged accounts does not translate directly to workloads; the equivalent is short-lived, federated workload credentials, mutual TLS and conditional access for tokens. Document that rationale for supervisors.
  • Asset management covers identities: Principle 5's inventory should include non-human identities with owner, purpose, privilege and rotation date, linked to the systems they reach. See the NHI Ownership Guide.
  • Change and segregation of duties: Principle 8 expects traceable changes with segregation of duties; an automation or AI coding agent that can both write and deploy code with one credential breaks that.
  • Detection: Principle 16's centralised logging should attribute API calls and agent actions to a specific identity, so that an account takeover campaign, one of the advisory's own examples, can be scoped.
  • AI services as third parties: model APIs and agent platforms are third-party arrangements under B-10; their access tokens are part of the exit plan. For model governance itself see the AI Model Risk Management Guide.

Compliance steps

  1. Map principles to owners: assign each of the 17 principles to an accountable senior officer and a control owner; confirm Principle 1 accountabilities with the board.
  2. Self-assess against outcomes: for each principle, record the expected outcome, your controls, evidence and gaps; use OSFI's Cyber Security Self-Assessment where helpful.
  3. Prioritise identity and logging gaps: MFA on external channels and privileged accounts, vaulted privileged credentials, machine identity inventory and centralised logging are usually the fastest risk reduction.
  4. Align with E-21: link B-13 controls to each critical operation and tolerance for disruption; test DR against severe but plausible scenarios (Principles 12 and 13).
  5. Bring third parties in line with B-10: inventory by criticality, add incident notice clauses that support the 24-hour advisory, and write stressed and non-stressed exit playbooks.
  6. Operationalise incident reporting: map the advisory's criteria into your severity model so reportability is decided automatically, and pre-fill the OSFI reporting form fields.
  7. Test: run intelligence-led red team or penetration tests (3.1.2) and tabletop a third-party breach with a 24-hour OSFI notice.
  8. Report and iterate: board reporting on risk appetite metrics, remediation status and test results; repeat the self-assessment yearly.

Decision guidance

ProfileApproachTrade-off
Small trust company or P&C insurerLean framework mapped to the 17 principles, outsourced SOC and DR testing, strong B-10 oversightHeavy reliance on providers; evidence of oversight becomes the main supervisory question
Mid-size bank or life insurerControl framework (for example NIST CSF 2.0) mapped to B-13, with owner per principleMapping effort; gives one control set for B-13, E-21 and audit
Domestic systemically important bankFull programme with intelligence-led red teaming, automated identity governance and critical operations mappingHighest cost; supervisory expectations scale with systemic importance

Measurement and framework mapping

  • Metrics: percentage of external-facing channels and privileged accounts with MFA; privileged credentials vaulted; non-human identities with owner and rotation date; mean time to patch critical vulnerabilities; DR tests meeting recovery objectives; incidents reported to OSFI within 24 hours of meeting criteria.
B-13 principleNIST SP 800-53 Rev. 5NIST CSF 2.0ISO/IEC 27001:2022 Annex A
1-3 Governance and riskPM-9, RA-3GV.RR-01, GV.RM-01A.5.2, A.5.4
4 ArchitectureSA-8PR.IR-04A.8.27
5 Asset managementCM-8ID.AM-08A.5.9
8 Change and releaseCM-3PR.PS-02A.8.32
9 Patch managementSI-2ID.RA-01A.8.8
12-13 Disaster recoveryCP-4, CP-9RC.RP-01A.5.30
14 Identify (testing)CA-8ID.RA-03A.5.7
15 Defend (identity and access)IA-2, AC-6PR.AA-05A.8.2, A.8.5
16 DetectAU-6DE.CM-03A.8.16
17 Respond and recoverIR-4, IR-6RS.AN-03A.5.26

Common failure patterns

  • Mapping without evidence: a spreadsheet that says each principle is "met" with no test results or metrics behind it.
  • Human-only identity scope: MFA and PAM rolled out for staff while service accounts and API keys keep static, unvaulted credentials.
  • Treating B-13 and B-10 separately: third-party technology controls assessed by procurement, cyber controls by security, with no shared inventory.
  • Reportability decided late: waiting for a full investigation before deciding to tell OSFI, when the advisory expects notice within 24 hours of meeting any criterion.
  • DR tests that avoid hard scenarios: planned failovers rather than severe but plausible events such as loss of an identity provider or a cloud region.

Practitioner checklist

  • Name an accountable senior officer for each of the 17 principles.
  • Run and document a self-assessment against each B-13 outcome.
  • Enforce MFA on external-facing channels and privileged accounts.
  • Vault privileged credentials, including service accounts and pipeline secrets.
  • Add non-human identities to the asset inventory with owners and rotation dates.
  • Centralise logs with identity attribution for people, services and agents.
  • Embed the advisory's reporting criteria in the incident severity model.
  • Contract third parties for incident notice that supports 24-hour OSFI reporting.
  • Link controls to E-21 critical operations and test DR against severe scenarios.
  • Run intelligence-led red team or penetration testing on a regular cycle.

Standards and references

Related NHI Mgmt Group resources: Financial Services Cyber Regulation Map · Financial Services Identity Security Guide · Canada Bill C-8 Guide · Third-Party Risk Management Guide. This guide summarises OSFI Guideline B-13 and related OSFI guidance as of October 2026 and is not legal advice.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 27 October 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org