What Is OSFI Guideline B-13?
OSFI Guideline B-13, Technology and Cyber Risk Management, is the framework the Office of the Superintendent of Financial Institutions uses to set its expectations for how federally regulated financial institutions manage technology and cyber risk. It came into effect on January 1, 2024, and it applies across the full technology lifecycle — from governance and architecture through operations, resilience, and incident response.
B-13 is principles-based rather than prescriptive. It does not hand institutions a checklist of controls to tick off. Instead, it describes outcomes OSFI expects an institution to achieve and leaves room for each institution to implement those outcomes in a way that is proportionate to its size, complexity, and risk profile. That flexibility is useful, but it also creates a common question: what does “implementing the security requirements” actually look like in practice? This guide answers that.
Who Must Comply
B-13 applies to all federally regulated financial institutions (FRFIs), including:
- Banks and authorized foreign bank branches
- Insurance companies (life, and property and casualty)
- Trust and loan companies
- Cooperative credit associations
If your institution is supervised by OSFI, B-13 applies to you. Provincially regulated institutions are not directly subject to B-13, but many adopt it as a recognized standard of practice, and some provincial regulators have issued closely aligned guidance.
The Domains of B-13
B-13 organizes its expectations into several domains that, together, cover the technology and cyber risk lifecycle:
- Governance and risk management — clear accountability, a technology and cyber risk management framework, and reporting that reaches senior management and the board.
- Technology operations and resilience — secure design and configuration, change and patch management, asset management, and the ability to recover from disruption.
- Cyber security — identifying and protecting critical assets, detecting threats, and responding to and recovering from incidents.
Security testing — vulnerability assessments, penetration testing, and threat-led red team exercises — sits across these domains. It is one of the primary ways an institution demonstrates that the controls it has designed actually work.
Security Testing Expectations Under B-13
OSFI expects institutions to maintain a risk-based security testing program. In practice, that program is built from a few complementary activities:
- Vulnerability assessments to continuously identify known weaknesses across the technology estate.
- Penetration testing to validate, by controlled exploitation, that controls hold up against a realistic attacker. This is where automated scanning stops and human expertise begins — business logic flaws, chained vulnerabilities, authentication bypasses, and privilege escalation paths are found by testers, not tools.
- Threat-led / red team testing for larger or more significant institutions, using current threat intelligence to emulate the adversaries most likely to target the organization. This is the model behind OSFI’s Intelligence-Led Cyber Resilience Testing (I-CRT).
OSFI does not mandate a fixed testing frequency. The expectation is risk-based: at minimum, test annually, and more frequently for critical systems, after significant infrastructure or application changes, and following major incidents. The depth and scope of testing should track the criticality of the assets involved.
Implementing the Security Requirements: A Practical Sequence
“Implementing the security requirements” is less a single project than an ongoing program. A practical way to stand it up:
- Map your critical technology assets. You cannot protect — or meaningfully test — what you have not inventoried. Identify the systems that support critical operations and the data that matters most.
- Define the risk-based testing scope. Tie the scope of vulnerability assessments and penetration tests to those critical assets, not to whatever is easiest to test.
- Run the testing on a defined cadence. Establish an annual baseline, with event-driven testing layered on top (major releases, new infrastructure, mergers).
- Remediate and re-test. A finding is not closed until it has been fixed and the fix has been validated. Build retesting into the program rather than treating it as optional.
- Report in a board-ready format. OSFI examiners and your own board need findings framed in terms of business impact and risk, mapped back to the relevant B-13 domains — not a raw scanner dump.
- Use independent testers. B-13 emphasizes objective, independent assurance. Engaging a qualified third party removes internal bias and gives examiners confidence that testing was not marking its own homework.
B-13 and Open Banking
As Canada moves toward an open banking (consumer-driven banking) framework, the security expectations in B-13 become even more relevant. Open banking expands the number of API integrations, data-sharing arrangements, and third-party relationships an institution maintains — and every one of those is part of the attack surface B-13 expects you to manage and test. Institutions preparing for open banking should treat their API security testing and third-party risk assessment as core parts of their B-13 program, not as a separate exercise.
How B-13 Relates to Other Frameworks
B-13 does not exist in isolation. Its outcomes map closely to widely used frameworks such as the NIST Cybersecurity Framework (CSF), and a strong testing program built for one will largely satisfy the others. If your institution already aligns to NIST CSF, ISO 27001, or SOC 2, you are most of the way to demonstrating B-13’s security testing expectations — the work is in mapping the evidence to OSFI’s domains and making sure the testing scope reflects your critical assets.
Do You Need a Penetration Test for OSFI B-13?
While B-13 does not name penetration testing as a mandatory line item, it clearly expects institutions to validate the effectiveness of their security controls — and penetration testing is the most widely accepted method for doing so. In practice, OSFI examiners expect to see penetration testing as part of a mature security program, and most institutions treat an annual penetration test as the baseline. For larger institutions, that baseline extends to intelligence-led red team testing.
How DarkPoint Helps
DarkPoint Security delivers OSFI B-13 penetration testing for Canadian banks, insurers, and other federally regulated financial institutions. Our assessments are scoped to your critical technology assets, executed by OSCP- and CISSP-certified consultants, and reported in a format structured for OSFI examination and board-level reporting. For institutions building toward intelligence-led testing, we also deliver OSFI I-CRT-aligned red team engagements.
If you are scoping your B-13 security testing program, contact us to discuss an engagement built around your environment and examination timeline.