OSFI B-13 and Penetration Testing (2026): What the Guideline Expects from Canadian FRFIs

Quick answer: OSFI Guideline B-13 expects penetration testing, but it does not tell you how often to do it. The only place the guideline names the activity is section 3.1.2, which says FRFIs "should set defined triggers, and minimum frequencies, for intelligence-led threat assessments to test cyber security processes and controls" and "should also regularly perform tests and exercises, to identify vulnerabilities or control gaps in its cyber security programs (e.g., penetration testing and red teaming) using an intelligence-led approach." There is no annual requirement in B-13, and there is no three-year requirement in B-13. The three-year figure comes from a different document. It is the cadence in OSFI's Intelligence-led Cyber Resilience Testing (I-CRT) Framework, an Advisory published 1 April 2023 whose foreword states plainly: "This document is not a policy instrument used to set regulatory expectations." Its scope "applies to all Systemically Important Banks (SIBs) and Internationally Active Insurance Groups (IAIGs)."

Every regulatory statement on this page was read from OSFI's own published guideline, advisory and release letter on 5 September 2026, and links back to that source. Where a claim could not be traced to an OSFI document, it was dropped rather than softened. This page explains published supervisory expectations; it is not legal advice, and an institution making a compliance determination should consult counsel.

What Guideline B-13 is, and when it took effect

Guideline B-13, Technology and Cyber Risk Management, is published by the Office of the Superintendent of Financial Institutions as guidance in the Sound Business and Financial Practices category, dated 31 July 2022. That is the publication date, not the compliance date. OSFI's own letter releasing the final guideline states: "Guideline B-13 will be effective on January 1, 2024, to provide FRFIs sufficient time to self-assess and ensure their compliance with this new guideline." The same letter describes the final version as "less prescriptive and streamlined with clearer definitions and clearer expectations" than the draft, which is exactly why the testing language ended up outcome-based rather than numeric.

Scope is broad. The guideline states: "This Guideline establishes OSFI's expectations related to technology and cyber risk management. It is applicable to all federally regulated financial institutions (FRFIs), including foreign bank branches and foreign insurance company branches, to the extent it is consistent with applicable requirements and legal obligations related to their business in Canada." Sector coverage on the guideline page lists banks, foreign bank branches, foreign insurance branches, life insurance and fraternal companies, property and casualty companies, and trust and loan companies.

And the reading instruction is set out in the purpose section itself:

There is no one-size-fits-all approach for managing technology and cyber risks given the unique risks and vulnerabilities that vary with a FRFIs' size, the nature, scope, and complexity of its operations, and risk profile. This Guideline should be read, and implemented, from a risk-based perspective that allows FRFIs to compete effectively and take full advantage of digital innovation, while maintaining sound technology risk management.

That sentence is the reason no number appears next to "penetration testing" anywhere in the document. A guideline that applies identically to a Schedule I bank and a small property and casualty insurer cannot set one cadence without being wrong for one of them.

Structurally, B-13 is organised into three domains, each with an outcome statement and a set of principles, seventeen in total:

Penetration testing sits in Domain 3, under Principle 14 and the Identify function.

What B-13 actually says about testing

Testing appears in five places across B-13, and only one of them names penetration testing. Getting these separated is the difference between a defensible programme and a programme built on a misread.

3.1.2 Intelligence-led threat assessment and testing is conducted

This is the clause. It sits under Principle 14: "FRFIs should maintain a range of practices, capabilities, processes and tools to identify and assess cyber security for weaknesses that could be exploited by external and insider threat actors." The section reads in full:

FRFIs should adopt a risk-based approach to threat assessment and testing. FRFIs should set defined triggers, and minimum frequencies, for intelligence-led threat assessments to test cyber security processes and controls. FRFIs should also regularly perform tests and exercises, to identify vulnerabilities or control gaps in its cyber security programs (e.g., penetration testing and red teaming) using an intelligence-led approach. The scope and potential impacts of such testing should be clearly defined by the FRFI with effective risk mitigation controls applied throughout the assessment to manage any associated inherent risks.

Four obligations are embedded in those four sentences, and each one is testable by a supervisor.

Defined triggers. You must be able to name the events that cause a test to happen outside the routine cycle. A major release, a new critical business function, an acquisition, a change in the threat picture, a significant incident. "We test when we can get budget" is not a trigger.

Minimum frequencies. OSFI does not set the number; it requires that you have set one and can show where it came from. A frequency that falls out of a risk assessment, is approved through the risk management framework, and is reviewed annually is defensible. A frequency that exists only in a procurement calendar is not.

Intelligence-led approach. Both the threat assessments and the tests are supposed to be informed by threat intelligence rather than by a generic checklist. In practice this means the scope of your annual test should be traceable to something: sector threat reporting, the tactics used against comparable institutions, and your own threat models under 3.1.6.

Defined scope and risk mitigation controls. Rules of engagement are an explicit expectation, not a courtesy. The clause asks that "the scope and potential impacts of such testing" be clearly defined "with effective risk mitigation controls applied throughout the assessment."

3.1.3 Vulnerabilities are identified, assessed and ranked

Separate obligation, separate activity:

FRFIs should establish processes to conduct regular vulnerability assessments of its technology assets, including but not limited to network devices, systems and applications. Processes should articulate the frequency with which vulnerability scans and assessments are conducted. FRFIs should assess and rank relevant cyber vulnerabilities and threats according to the severity of the threat and risk exposure to technology assets using a standard risk measurement methodology. In doing so, FRFIs should consider the potential cumulative impact of vulnerabilities, irrespective of risk level, that could present a high-risk exposure when combined.

Note the last sentence. It is the strongest single argument in B-13 for buying penetration testing rather than scanning alone. Cumulative impact, where several individually low-rated weaknesses combine into a high-risk exposure, is precisely the thing a scanner cannot compute and a tester chains together as an attack path. If your evidence for 3.1.3 is a scanner report with severity counts, you have satisfied the first two sentences and ignored the fourth.

3.2.9 Application scanning and testing capabilities are employed

Under Principle 15, on defending technology assets:

Where feasible, static and/or dynamic scanning and testing capabilities should be used to ensure new, and/or changes to existing, systems and applications are assessed for vulnerabilities prior to release into the production environment. Security controls should also be implemented to maintain security when development and operations practices are combined through a continuous and automated development pipeline.

This is a pipeline expectation, not a penetration testing expectation, and it pairs with 2.4.2, which requires FRFIs to "establish control gates to ensure that security requirements and expectations are embedded in each phase of the SDLC," including for Agile methods.

2.9.3 and 2.7.2, the resilience testing clauses

Two more testing obligations sit in Domain 2 and are often confused with security testing. Under Principle 13, section 2.9.3 says FRFIs "should regularly validate and report on their disaster recovery strategies, plans and/or capabilities against severe but plausible scenarios." Under Principle 10, section 2.7.2 lists among incident management expectations "Performing periodic testing and exercises using plausible scenarios in order to identify and remedy gaps in incident response actions and capabilities."

Scenario-based resilience testing is a distinct programme from offensive security testing. They share nothing but the word "test," and a supervisor will expect both.

3.1.7, phishing and awareness testing

Also under Principle 14: "the FRFI should regularly test its employees to assess their awareness of cyber threats and the effectiveness of their reporting processes and tools." Social engineering testing sits here rather than in 3.1.2, though a red team engagement will usually touch both.

The clause-to-activity map

Nine testing expectations. Zero numbers. That is the shape of B-13, and it is deliberate.

The three-year myth, and where it comes from

Search for OSFI penetration testing requirements and you will find "every three years" repeated across dozens of vendor pages. The number is real. The attribution is wrong.

It comes from the I-CRT Framework, listed on OSFI's site as publication type Advisory, dated 1 April 2023. Three sentences from that document settle the question.

On its own status: "As a supervisory tool, this framework is a 'how to' guide to follow when conducting OSFI's Intelligence-Led Cyber Resilience Testing (I-CRT) assessments. This document is not a policy instrument used to set regulatory expectations."

On its scope: "While I-CRT concepts in general apply to all FRFIs, the current scope of the I-CRT framework applies to all Systemically Important Banks (SIBs) and Internationally Active Insurance Groups (IAIGs)."

On its cadence: Table 2 of the framework, headed "I-CRT assessment criteria and cadence," lists three rows. For SIBs and IAIGs, trigger "Supervisory cycle," cadence "Three years." For SIBs and IAIGs again, triggers "FRFIs' technology and cyber risk potentially threatening financial stability" and "Major cyber incidents impacting FRFIs' operational resilience," cadence "Event driven." For other FRFIs: "FRFIs outside of SIBs and IAIGs may request an I-CRT assessment and OSFI will evaluate the request on a case-by-case basis," cadence "Case by case." The framework adds that "OSFI will review the I-CRT assessment and cadence requirements at a regular interval within its supervisory cycle and update if necessary."

So the honest statement is: if you are one of Canada's domestic systemically important banks or an internationally active insurance group, you should expect an OSFI-led I-CRT assessment roughly once per three-year supervisory cycle, plus event-driven assessments. If you are any other FRFI, I-CRT is available on request and evaluated case by case, and the three-year cadence is not an expectation that applies to you.

Importantly, an I-CRT assessment is not a substitute for your own testing programme. It is regulator-led. As the framework puts it, "An I-CRT assessment of a FRFI is a regulatory-led (i.e., OSFI) activity where OSFI provides guidance and oversight throughout the assessment," and "As a prudential regulator, OSFI provides independent oversight and guidance throughout an I-CRT assessment." Your 3.1.2 obligations continue regardless.

I-CRT, red teaming and penetration testing are not the same thing

The framework carries a comparison table that is worth reproducing, because it is OSFI's own taxonomy and it maps neatly onto how a Canadian FRFI should structure its testing spend.

Two notes on reading it. First, OSFI's "traditional penetration testing" column describes a floor, and it is a floor that modern application testing has already moved past: authorisation and business logic testing is objective-based work that does not fit "known technique with a standard tool set." Treat the column as a description of the commodity end of the market, not of what a good test looks like. Second, the framework locates I-CRT in an international lineage: "the concept of intelligence-led penetration testing was developed by the Bank of England with its CBEST framework and it has since been leveraged globally by regulators (e.g., TIBER, CORIE)." Our comparison of TIBER-EU, CBEST and DORA TLPT covers those siblings, and the DORA threat-led penetration testing guide covers the European regime a Canadian group with EU entities will also face.

The other OSFI clock: 24 hours

B-13 sets no testing number, but OSFI does set one hard number in the technology and cyber space, and it is worth knowing because it is the number that turns a bad week into a supervisory event.

The Technology and Cyber Security Incident Reporting Advisory, publication type Advisory, dated and effective 13 August 2021, applies to all FRFIs. It states: "Under the Advisory, FRFIs must report a technology or cyber security incident to OSFI's Technology Risk Division as well as their Lead Supervisor at OSFI within 24 hours, or sooner if possible."

The advisory defines the trigger broadly: "a technology or cyber security incident is defined as an incident that has an impact, or the potential to have an impact on the operations of a FRFI, including its confidentiality, integrity or the availability of its systems and information." Among the reportable characteristics it lists are impacts to customer information confidentiality, integrity or availability, activation of the incident management team or protocols, an incident reported to the board or to management, an incident reported to the Office of the Privacy Commissioner or law enforcement, an incident for which a cyber insurance claim has been initiated, and any incident "assessed by a FRFI to be of a high or critical severity, level or ranked Priority/Severity/Tier 1 or 2 based on the FRFI's internal assessment." Where details are unavailable, the FRFI "must indicate 'information not yet available'" and provide best estimates, and OSFI "expects FRFIs to provide regular updates (e.g., daily)."

The connection to testing is direct. A penetration test that produces a Critical finding in production is not an incident. A penetration test that is not properly scoped and rules-of-engaged, and that causes a production impact, can become one. This is exactly why 3.1.2 asks for "effective risk mitigation controls applied throughout the assessment," and why the rules of engagement document belongs in your evidence file. Our guide to cloud penetration testing rules of engagement covers what those controls look like in practice.

Scoping a B-13 penetration test: start from critical business functions

B-13 does not enumerate assets, so the scoping conversation has to be driven by something. The guideline gives you the driver: critical business functions, threat intelligence and the asset inventory.

Start with the technology asset inventory. Principle 5 requires FRFIs to "maintain an updated inventory of all technology assets supporting business processes or functions," with classification "to facilitate risk identification and assessment." A test scoped against an inventory that does not exist is a test scoped against an assumption.

Follow the critical business functions. I-CRT is scoped to CBFs, and even though I-CRT does not apply to most FRFIs, the logic transfers. Payments, settlement, policy administration, customer onboarding, lending origination, claims. The technology assets underpinning those functions are where the annual test earns its money.

Cover both sides of the perimeter. Principle 14 speaks of weaknesses "that could be exploited by external and insider threat actors." An external-only engagement addresses half of that sentence. An internal or assumed-breach component covering directory services, privileged access paths, lateral movement and segmentation addresses the other half. Section 3.2.7 expects privileged access management and MFA "across external-facing channels and privileged accounts," and those are control assertions that an internal test either confirms or does not. Our explainer on assumed breach engagements sets out how that component is run.

Include the applications and their APIs. Section 3.2.3 asks FRFIs to consider "Deploying additional layers of security controls, as appropriate, to defend against cyber attacks (e.g., volumetric, low/slow network and application business logic attacks)." Business logic is named in the guideline. Business logic is also the class that scanning does not reach, which is why the cumulative-impact sentence in 3.1.3 and the application-logic sentence in 3.2.3 point at the same purchase.

Include cloud. Identity and access configuration, storage exposure and workload isolation in whichever platforms host the CBF workloads. Our cloud penetration testing services guide sets out how those scopes are bounded.

Write down what was excluded and why. Section 3.1.2 asks that scope "be clearly defined by the FRFI." A documented exclusion with a compensating control is a programme decision. A silent exclusion is a gap.

Third parties. Guideline B-10 on Third-Party Risk Management is the companion instrument here, and B-13's release letter names it alongside the Corporate Governance Guideline, E-21 on Operational Risk Management, the incident reporting advisory and the Cyber Security Self-Assessment tool as complementary guidance. Testing a provider's environment usually requires the provider's authorisation, so the mechanism is contractual: name the cadence and a right to review results, then collect what you are entitled to.

What a supervisor asks to see

OSFI does not publish a penetration testing evidence checklist, so the honest framing is this: the evidence that satisfies B-13 is the evidence that demonstrates each of 3.1.2's four obligations was met, plus the remediation trail that 3.2.6 asks for. In practice that is nine artefacts.

1. The documented testing frequency and its basis. This is the single most important document and the one most often missing. Not "we test annually," but a written statement of the minimum frequency by asset class, the risk rationale, and the approval through the technology and cyber risk management framework required by Principle 3.

2. The trigger list. The defined events that pull a test forward, and the log showing when one fired.

3. The threat inputs. What intelligence shaped this year's scope. Sector reporting, threat models maintained under 3.1.6, and the tactics you decided to emulate. This is what makes the test "intelligence-led" rather than generic.

4. The scope statement, naming systems, applications, IP ranges, cloud accounts and roles, together with exclusions and their reasons, mapped to the critical business functions they support.

5. The rules of engagement, including testing windows, escalation contacts and the risk mitigation controls that 3.1.2 explicitly requires.

6. The full technical report, with reproduction steps, affected assets, severity ratings and a stated rating methodology. Section 3.1.3 asks for ranking "using a standard risk measurement methodology," so the methodology has to be stated, not implied. Our penetration testing report sample shows the structure, and how to evaluate a penetration test report covers what separates a usable report from a scanner export.

7. The cumulative-impact analysis. Attack paths, not just a finding list. This is the fourth sentence of 3.1.3 and almost nobody evidences it.

8. The remediation record against defined timelines. Section 3.2.6 asks FRFIs to "Regularly monitor and report on patching status and vulnerability remediation against defined timelines, including any backlog and exceptions." Owners, dates, exceptions and compensating controls where remediation was unavailable.

9. The retest report confirming closure, and the reporting line into the cyber risk profile that 3.1.8 requires FRFIs to "maintain, and report on."

OSFI also publishes a technology and cyber risk management self-assessment tool alongside B-13. Running your testing evidence against that tool before a supervisory review is cheaper than discovering the gaps during one.

How B-13 maps to the frameworks you are also running

Most Canadian FRFIs are running B-13 next to at least one customer-facing or cross-border regime. The overlap is high enough that one well-scoped annual engagement can feed several evidence sets.

The pattern is consistent: B-13 is the least prescriptive instrument in the list and the broadest in scope. If you build a programme to satisfy the most prescriptive regime that applies to your group, B-13 is normally satisfied inside it, provided you also produce the frequency rationale and threat-intelligence linkage that B-13 asks for and the others do not. Our guide to the pentest evidence auditors accept across SOC 2, ISO 27001, PCI DSS and CMMC covers the shared package.

What the tests actually find

Stingrai's State of Penetration Testing 2026 analysed 1,206 verified findings from 55 penetration tests, and four of its numbers speak directly to the B-13 clauses above.

92.7% of tests surfaced at least one High or Critical finding. Put that number next to a risk-based frequency decision that concluded testing every other year was sufficient. Principle 14 asks FRFIs to identify weaknesses "that could be exploited by external and insider threat actors." An untested estate has an opinion about that, not a measurement.

The false positive rate across the dataset was 0.74%. Section 3.1.3 requires ranking "using a standard risk measurement methodology." A report padded with unvalidated scanner output corrupts the ranking and, with it, the remediation queue that 3.2.6 asks you to report on.

The median Critical took 10.5 days to fix. Section 3.2.6 asks for patches "at the earliest opportunity, commensurate with risk and in accordance with established timelines," and for regular reporting against those timelines. A measured median gives you a timeline to establish rather than a number to invent.

Authorisation and business logic findings concentrate in application testing. Section 3.2.3 names "application business logic attacks" as a threat class to defend against. It is also the class automated scanning is worst at, because the request is well formed and the response is a valid 200. Our analysis of why API scanners miss BOLA and IDOR covers the mechanics.

What a B-13 penetration test costs in Canada

There is no OSFI rate card, and any figure presented as one is invented. What can be said honestly is which variables move the number for a Canadian FRFI.

Critical business function count. Scope driven by CBFs rather than by IP count is the B-13-aligned way to buy, and it is usually the cheaper way, because it removes low-consequence assets from the engagement.

Both sides of the perimeter. An external-only engagement is roughly half the work Principle 14 describes. The internal component is usually the larger half for an institution with an Active Directory estate.

Application role complexity. Authorisation testing scales with role pairs, not page count. A broker or advisor portal with client, advisor, branch administrator, operations and support roles has an authorisation matrix several times larger than a single-role product.

Intelligence-led scoping. Threat intelligence work up front adds days and is what converts a generic test into something that satisfies the wording of 3.1.2.

Retesting. Section 3.2.6 asks for reporting against defined timelines. A quote that excludes retesting is not comparable to one that includes it.

Our penetration testing cost guide for 2026 breaks pricing structures down by engagement type, the pentest cost calculator produces a scoped estimate from asset counts, and the average cost of a pentest in Canada covers the domestic market specifically.

Stingrai publishes fixed package prices rather than a metered rate. The pricing page lists an Autonomous Pentest from US$3,000 one-time driven by Snipe, and a Hybrid Pentest at US$6,800 one-time where certified penetration testers work alongside Snipe throughout the engagement, both covering one web application and its APIs. The same two tiers run continuously at US$450 and US$1,275 per month on a 12-month engagement, which is the model that fits a B-13 programme with defined triggers, because change-driven testing does not wait for a purchase order. A full FRFI scope covering internal network, external perimeter, applications and cloud is quoted rather than listed, through Get a Quote.

What Stingrai delivers against a B-13 scope

Stingrai is headquartered in Toronto, Ontario, with a London office, and has been operating since 2021. It is a CREST-accredited penetration testing service provider at the firm level, holds 18 published CVEs across the team, and is rated 5.0 out of 5.0 across 19 Clutch reviews. Team certifications include OSCE3, OSCP, OSWE, OSED, OSEP, CREST CRT, CISSP, CRTO, GCPN, CRTE and eWPTX. Stingrai's penetration testing supports B-13 programmes, along with SOC 2, ISO 27001, PCI DSS 4.0, NIST SP 800-53 and 800-171, DORA and NIS2, by producing the technical evidence those programmes consume.

Annual or continuous, both available. A FRFI can buy a one-time annual test against a documented minimum frequency, or run continuous testing so that the defined triggers in 3.1.2 are covered without a new procurement each time. Both are published offerings. Our explainer on continuous PTaaS and the comparison of continuous red teaming against an annual pentest set out where each model fits a risk-based cadence.

Certified penetration testers and Snipe work concurrently. Snipe is Stingrai's autonomous AI agent for web application penetration testing, custom-trained on more than 6,000 HackerOne Hacktivity disclosure reports and on methodology distilled from Stingrai's own penetration testers. It hunts the complex classes that generic scanners miss, including IDOR, business logic flaws and broken authorisation, performs both black-box dynamic testing and white-box source review, generates AutoFix pull requests, and can run as a pull-request gating check, which maps directly onto the 3.2.9 and 2.4.2 pipeline expectations. Stingrai's penetration testers test at the same time throughout the engagement, direct Snipe's focus, extend its attack paths and pursue what it surfaces. Both contribute findings across all severities.

Red team and adversary emulation for institutions whose 3.1.2 frequency decision calls for objective-based testing beyond technology, delivered through red teaming services. A worked example sits in the adversary simulation in telecom case study.

Retest included, which is what converts a finding list into the remediation-against-timelines evidence 3.2.6 asks for.

Guarantee. On the Autonomous tier, "No High or Critical Finding = Don't Pay." That guarantee applies to the Autonomous tier only; other tiers and scopes are quoted through Get a Quote.

What this means for Canadian FRFIs

• Write the frequency down, then defend it. B-13's testing obligation is procedural before it is technical. The document that says what your minimum frequency is, why, and who approved it, is the artefact a supervisor will ask for first. Most institutions have the tests and not the document.

• Do not budget to a three-year cycle unless you are a SIB or an IAIG. The three-year cadence belongs to an advisory that says it does not set regulatory expectations, and its stated scope is SIBs and IAIGs. Annual testing of the CBF-supporting estate, plus change-driven tests, is the market-normal answer for everyone else.

• Make the test intelligence-led in a way you can evidence. Section 3.1.2 uses that phrase twice. If nothing in your scoping document references a threat, your test is not intelligence-led, whatever the statement of work says.

• Evidence cumulative impact, not just findings. The fourth sentence of 3.1.3 asks for it explicitly, and attack-path narrative is the part of a report that scanners cannot produce.

• Keep the remediation and retest trail. Section 3.2.6 asks for monitoring and reporting "against defined timelines, including any backlog and exceptions." A report with no closure record answers half the clause.

Frequently Asked Questions

Does OSFI B-13 require penetration testing?

Yes, as an expectation rather than a numeric rule. Section 3.1.2 of Guideline B-13 says FRFIs "should also regularly perform tests and exercises, to identify vulnerabilities or control gaps in its cyber security programs (e.g., penetration testing and red teaming) using an intelligence-led approach," and that they "should set defined triggers, and minimum frequencies" for that testing. The guideline names penetration testing directly. It does not name a frequency, because the frequency is the FRFI's to set and defend.

How often does OSFI require a penetration test?

B-13 sets no interval. It requires that the FRFI set one: "FRFIs should set defined triggers, and minimum frequencies, for intelligence-led threat assessments to test cyber security processes and controls." Section 3.1.3 similarly says vulnerability assessment processes "should articulate the frequency with which vulnerability scans and assessments are conducted." Annual testing of the estate supporting critical business functions, plus change-driven tests, is the cadence most Canadian FRFIs operate and the one that survives a supervisory conversation.

Where does the "OSFI penetration test every three years" figure come from?

From the I-CRT Framework, not from B-13. I-CRT is listed as an Advisory dated 1 April 2023, and its foreword states: "This document is not a policy instrument used to set regulatory expectations." Its Table 2 sets a three-year supervisory-cycle cadence, and its stated scope "applies to all Systemically Important Banks (SIBs) and Internationally Active Insurance Groups (IAIGs)." Applying a three-year cadence to a mid-sized FRFI is a misattribution of a document that says on its face it is not setting expectations.

Does the I-CRT framework apply to my institution?

Only if you are a Systemically Important Bank or an Internationally Active Insurance Group. The framework says so in terms: "While I-CRT concepts in general apply to all FRFIs, the current scope of the I-CRT framework applies to all Systemically Important Banks (SIBs) and Internationally Active Insurance Groups (IAIGs)." For everyone else, Table 2 records that "FRFIs outside of SIBs and IAIGs may request an I-CRT assessment and OSFI will evaluate the request on a case-by-case basis," with a cadence of "Case by case."

When did Guideline B-13 come into effect?

1 January 2024. The guideline page carries a publication date of 31 July 2022, but OSFI's release letter states: "Guideline B-13 will be effective on January 1, 2024, to provide FRFIs sufficient time to self-assess and ensure their compliance with this new guideline." Anyone quoting 2022 as the compliance date is quoting the publication date.

Who does B-13 apply to?

All federally regulated financial institutions. The purpose and scope section reads: "It is applicable to all federally regulated financial institutions (FRFIs), including foreign bank branches and foreign insurance company branches, to the extent it is consistent with applicable requirements and legal obligations related to their business in Canada." The sector list on OSFI's page covers banks, foreign bank branches, foreign insurance branches, life insurance and fraternal companies, property and casualty companies, and trust and loan companies. Provincially regulated credit unions and insurers are outside OSFI's remit and answer to their provincial regulator instead.

What does "intelligence-led" mean in section 3.1.2?

That the threat assessments and the tests are shaped by threat intelligence rather than by a generic checklist. In practice it means your scoping document should trace the chosen attack paths and scenarios back to something: sector threat reporting, tactics observed against comparable institutions, or the threat models B-13 asks you to maintain under 3.1.6, which also expects FRFIs to "use manual techniques to proactively identify and isolate threats which may not be detected by automated tools." A test scoped purely from an asset list does not meet the wording.

What evidence does an OSFI supervisor expect from a penetration test?

OSFI publishes no testing evidence checklist, so the practical answer is the evidence that demonstrates each obligation in 3.1.2 and 3.2.6 was met: the documented minimum frequency and its risk basis, the defined trigger list, the threat inputs that shaped scope, the scope statement with reasoned exclusions, the rules of engagement including the risk mitigation controls the clause requires, the technical report with a stated severity methodology, the cumulative-impact or attack-path analysis 3.1.3 asks for, the remediation record against defined timelines including backlog and exceptions, and the retest confirming closure. OSFI's self-assessment tool is a useful dry run.

Does a vulnerability scan satisfy B-13?

Not on its own, and the guideline separates the two activities. Vulnerability assessment sits in 3.1.3, penetration testing and red teaming sit in 3.1.2, and application scanning sits in 3.2.9. Section 3.1.3 also closes with a sentence a scanner cannot answer: FRFIs "should consider the potential cumulative impact of vulnerabilities, irrespective of risk level, that could present a high-risk exposure when combined." Chaining individually low-rated weaknesses into a high-impact path is what a tester does and what a scan report does not contain.

How quickly must a Canadian FRFI report a cyber incident to OSFI?

Within 24 hours. The Technology and Cyber Security Incident Reporting Advisory, effective 13 August 2021, states that "FRFIs must report a technology or cyber security incident to OSFI's Technology Risk Division as well as their Lead Supervisor at OSFI within 24 hours, or sooner if possible." Where details are unavailable at the time of the initial report, the FRFI must indicate "information not yet available" and provide best estimates, and OSFI expects regular updates, for example daily, until all details have been provided.

Where can I read the actual OSFI documents?

Start with Guideline B-13, Technology and Cyber Risk Management and read section 3.1 in full. Then read the release letter for the effective date, the I-CRT Framework for the three-year cadence and its stated scope, and the Technology and Cyber Security Incident Reporting Advisory for the 24-hour clock. The self-assessment tool accompanies B-13.

Related Reading

• NYDFS Penetration Testing Requirements (2026)

• DORA Threat-Led Penetration Testing (2026)

• TIBER-EU, CBEST and DORA TLPT Compared

• Top Penetration Testing Companies in Canada (2026), Ranked

• Average Cost of a Penetration Test in Canada (2026)

• Continuous Red Teaming vs the Annual Pentest (2026)

• Pentest Evidence Auditors Accept: SOC 2, ISO 27001, PCI DSS and CMMC (2026)

• The State of Penetration Testing 2026

References

1. Office of the Superintendent of Financial Institutions. Guideline B-13, Technology and Cyber Risk Management. Published 31 July 2022, effective 1 January 2024. https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/technology-cyber-risk-management. The guideline itself. Source of every quotation on this page from the purpose and scope section, Principles 5, 7, 10, 13, 14 and 15, and sections 2.4.2, 2.7.2, 2.9.3, 3.1.1, 3.1.2, 3.1.3, 3.1.6, 3.1.7, 3.1.8, 3.2.3, 3.2.6, 3.2.7 and 3.2.9.

2. Office of the Superintendent of Financial Institutions. OSFI releases final Guideline B-13, Technology and Cyber Risk Management, letter. 2022. https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/osfi-releases-final-guideline-b-13-technology-cyber-risk-management-letter-2022. Records the 1 January 2024 effective date and the description of the final guideline as less prescriptive than the draft.

3. Office of the Superintendent of Financial Institutions. OSFI's Intelligence-led Cyber Resilience Testing (I-CRT) Framework. Advisory, 1 April 2023. https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/osfis-intelligence-led-cyber-resilience-testing-crt-framework. Source of the statement that the document is not a policy instrument used to set regulatory expectations, the SIB and IAIG scope, the three-year supervisory-cycle cadence in Table 2, and the traditional penetration testing versus red teaming versus I-CRT comparison in Table 1.

4. Office of the Superintendent of Financial Institutions. Technology and Cyber Security Incident Reporting Advisory. Advisory, effective 13 August 2021. https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/technology-cyber-security-incident-reporting. Source of the 24-hour initial reporting requirement, the definition of a technology or cyber security incident, and the reportable incident criteria.

5. Office of the Superintendent of Financial Institutions. Technology and cyber risk management self-assessment tool. https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/technology-cyber-risk-management/technology-cyber-risk-management-self-assessment-tool. The companion self-assessment published alongside B-13.

6. Stingrai. The State of Penetration Testing 2026. https://www.stingrai.io/blog/state-of-penetration-testing-2026. 1,206 verified findings across 55 penetration tests, severity mix, false positive rate and remediation timing.

7. Stingrai. Penetration Testing Cost 2026. https://www.stingrai.io/blog/penetration-testing-cost-2026. Pricing structures by engagement type and the variables that move a quote.

8. Stingrai. Average Cost of a Penetration Test in Canada 2026. https://www.stingrai.io/blog/average-cost-of-pentest-canada-2026. Domestic Canadian pricing context.

9. Stingrai. Penetration Testing Report Sample 2026. https://www.stingrai.io/blog/penetration-testing-report-sample-2026. A worked example of the report structure a supervisor or auditor can consume.

10. Stingrai. TIBER-EU, CBEST and DORA TLPT Compared. https://www.stingrai.io/blog/tiber-cbest-dora-tlpt-comparison. The international intelligence-led testing frameworks the I-CRT framework names as its lineage.

11. Stingrai. Pricing. https://www.stingrai.io/pricing. Published one-time and continuous package prices for one web application and its APIs.

Ready to scope a B-13 penetration test?

B-13 does not hand you a number, which means the burden of proof sits with your frequency document, your threat inputs and your remediation trail. Stingrai is a Toronto-headquartered, CREST-accredited penetration testing service provider whose penetration testing supports B-13 programmes by producing the scope statement, intelligence-led attack paths, technical report, remediation record and retest evidence a supervisor expects, as a one-time annual engagement or as continuous coverage across the year. Certified penetration testers work alongside Snipe, our autonomous AI agent for web application penetration testing, throughout the engagement, hunting the broken authorization and business logic flaws that section 3.2.3 names and that scanners do not reach. Book a free scoping call, get a quote for a full internal, external, application and cloud scope, or read the published package prices on the pricing page.