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 no three-year requirement in B-13. The three-year figure comes from a different document, the 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," and whose scope "applies to all Systemically Important Banks (SIBs) and Internationally Active Insurance Groups (IAIGs)."
This guide is written for the two buyers who carry the obligation: the mid-market or enterprise FRFI, meaning a bank, insurer, trust and loan company or federally regulated credit union, and the critical third party supporting one of its business functions, meaning the fintech, payments provider, core platform or SaaS vendor whose security questionnaire arrives with a bank's name at the top. Both are asked for the same artefacts, for different reasons.
Every regulatory statement here was read from OSFI's own published guideline, advisory and release letter, and links back to that source. 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 and 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" than the draft, which is why the testing language ended up outcome-based rather than numeric.
Scope is broad: the guideline "is applicable to all federally regulated financial institutions (FRFIs), including foreign bank branches and foreign insurance company branches," covering banks, life insurance and fraternal companies, property and casualty companies, and trust and loan companies. 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 sentence is why no number appears next to "penetration testing" anywhere in the document: a guideline applying identically to a Schedule I bank and a small property and casualty insurer cannot set one cadence without being wrong for one of them. It is also the sentence a mid-market FRFI should lean on, because proportionality is written into the instrument. A defensible programme at a mid-sized trust company looks nothing like a Big Six programme, and that is the design rather than a concession. Structurally, B-13 runs to seventeen principles across three domains: governance and risk management, technology operations and resilience, and cyber security. Penetration testing sits in the third, under Principle 14.
What B-13 actually says about testing
Testing appears in several 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 is testable by a supervisor.
Defined triggers. Name the events that cause a test 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. One that exists only in a procurement calendar is not.
An intelligence-led approach, meaning scope traceable to sector threat reporting, the tactics used against comparable institutions and your own threat models under 3.1.6, rather than to a generic checklist. And defined scope with risk mitigation controls, which makes rules of engagement an explicit expectation rather than a courtesy.
The clause-to-activity map
The other testing clauses are separate obligations with separate evidence. Vulnerability assessment (3.1.3) is not penetration testing, pipeline scanning (3.2.9) is not penetration testing, and scenario exercises (2.7.2, 2.9.3) are not penetration testing. None of them names a number either.
B-13 section | Testing obligation, as written | Frequency named | The activity that produces evidence |
|---|---|---|---|
3.1.2 (Principle 14) | Intelligence-led threat assessment and testing, expressly including "penetration testing and red teaming" | None. FRFI sets triggers and minimum frequencies | Penetration testing across external, internal, application and cloud scope; red team or adversary emulation for mature programmes |
3.1.3 (Principle 14) | Regular vulnerability assessments, ranked with "a standard risk measurement methodology," considering "cumulative impact of vulnerabilities, irrespective of risk level" | None. Processes must "articulate the frequency" | Vulnerability scanning plus the manual attack-path analysis that shows cumulative exposure |
3.1.6 (Principle 14) | Threat models maintained; "manual techniques to proactively identify and isolate threats which may not be detected by automated tools" | None | Threat modelling; threat hunting; the manual half of a penetration test |
3.2.6 (Principle 15) | Timely risk-based patching and reporting of remediation "against defined timelines, including any backlog and exceptions" | Defined timelines, set by the FRFI | Retest evidence closing findings; remediation SLA reporting |
3.2.9 (Principle 15), 2.4.2 (Principle 7) | Static and dynamic scanning before release; control gates in each SDLC phase | None. "Where feasible" | SAST and DAST in the pipeline; pull-request gating; secure design and code review |
2.7.2 (Principle 10), 2.9.3 (Principle 13) | Periodic exercises using plausible scenarios for incident response; recovery testing under severe but plausible scenarios | None. "Periodic" | Tabletop exercises; purple team detection validation; recovery testing |
The conclusion is the same in every row: B-13 asks the institution to set, document and defend its own frequencies. That is a governance artefact, and it is the artefact most often missing when a supervisor asks.
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 passages settle the question. On its own status: "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 sets trigger "Supervisory cycle," cadence "Three years" for SIBs and IAIGs, adds event-driven assessments for the same population, and for everyone else 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," cadence "Case by case."
So the honest statement is: a domestic systemically important bank or an internationally active insurance group should expect an OSFI-led I-CRT assessment roughly once per three-year supervisory cycle, plus event-driven assessments. Any other FRFI can request one, and the three-year cadence is not an expectation that applies to it. For a mid-market institution, budgeting to a three-year cycle on the strength of that number is the most expensive misreading in this space, because it leaves two years of an untested estate behind a governance decision citing the wrong document. An I-CRT assessment is also not a substitute for your own programme: it is "a regulatory-led (i.e., OSFI) activity," and your 3.1.2 obligations continue regardless.
I-CRT, red teaming and penetration testing are not the same thing
OSFI's taxonomy separates three activities. Traditional penetration testing is "finding known vulnerabilities with standard tool set" against a "technology-focused" scope. Red teaming is "objective-based assessment aiming at persistent access to specific systems or information," with scope that "goes beyond technology that is People, Process, Technology (PPT)." I-CRT emulates "sophisticated threat actors' TTPs based on genuine cyber threats" against critical business functions. Read the first description as the commodity end of the market rather than as what a good test looks like, because authorisation and business logic testing is objective-based work that does not fit "known technique with a standard tool set." The framework also places I-CRT in an international lineage, noting that intelligence-led 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 regime a Canadian group with EU entities also faces.
The other OSFI clock: 24 hours
B-13 sets no testing number, but OSFI sets one hard number in this space. The Technology and Cyber Security Incident Reporting Advisory, effective 13 August 2021, applies to all FRFIs and states: "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 trigger is broad, covering any incident "that has an impact, or the potential to have an impact on the operations of a FRFI."
The connection to testing is direct. A penetration test that produces a Critical finding in production is not an incident. A test that is not properly scoped and rules-of-engaged, and that causes a production impact, can become one. That is 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, as our guide to cloud penetration testing rules of engagement sets out. A third party testing a system a FRFI depends on should assume the same discipline, because a production impact at the provider becomes a reportable event at the institution.
Scoping the engagement: critical business functions, then entities
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 from the asset inventory and the critical business functions. Principle 5 requires FRFIs to "maintain an updated inventory of all technology assets supporting business processes or functions," and a test scoped against an inventory that does not exist is a test scoped against an assumption. From there, follow the functions: payments, settlement, policy administration, customer onboarding, lending origination, claims. The assets underpinning those 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," and 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, and it is what confirms or refutes the privileged access and MFA controls 3.2.7 expects "across external-facing channels and privileged accounts."
Include the applications, their APIs and the cloud behind them. Section 3.2.3 asks FRFIs to defend against "application business logic attacks." Business logic is named in the guideline and it is the class 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. On the platform side: identity and access configuration, storage exposure and workload isolation for the CBF workloads, bounded as our cloud penetration testing services guide and the AWS and SOC 2 cloud testing provider comparison describe.
Then scope across entities. This is where enterprise groups diverge from startups. A Canadian group typically carries a federally regulated parent, subsidiaries, a US entity, sometimes a foreign branch, and a shared services company operating the platforms for all of them. Decide early whether this is one programme with per-entity reporting or several separate engagements, because the answer determines whether a subsidiary board can be handed its own report. The better structure is usually a single master agreement with entity-scoped statements of work and a consolidated cross-entity attack-path narrative on top, because lateral movement between entity estates is a real finding class and separate vendors never see it.
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.
What a FRFI or a critical third party needs from a penetration testing vendor
Most vendor selection in this market runs on price and turnaround, then fails six months later when the report cannot carry the weight the institution needs it to carry. What follows separates a vendor that fits a federally regulated buyer from one that fits a seed-stage startup, and it applies to the FRFI buying for itself and to the provider buying because a FRFI client asked.
Evidence built for B-13, not adapted to it. The report has to answer 3.1.2 and 3.2.6 on its face: scope tied to critical business functions, the threat inputs that shaped it, rules of engagement carrying the risk mitigation controls the clause names, a stated severity methodology, attack paths rather than an isolated finding list, and a remediation record. A vendor who cannot show a redacted example of each artefact before you sign is asking you to buy on faith. Our penetration testing report sample shows the structure and how to evaluate a penetration test report covers the difference between a usable report and a scanner export.
B-10 third-party risk fit. Guideline B-10, Third-Party Risk Management is the companion instrument, named in B-13's release letter as complementary guidance, and it keeps accountability with the FRFI for risk arising from third-party arrangements. That is why the testing obligation travels downstream in contract language rather than in regulation. If you are the FRFI, testing a provider's environment normally requires the provider's authorisation, so the mechanism is contractual: name the cadence, name the scope class, reserve a right to review results, then collect what you are entitled to. If you are the provider, your own annual test and its retest evidence close that clause for every client at once, far cheaper than negotiating bespoke testing rights with each of them.
A questionnaire-ready evidence pack. Providers selling into FRFIs get the same questions from every institution: who tested, when, against what scope, under which methodology, what was found, what was fixed, when was it retested, and can we see the letter. A deliverable that includes a summary letter shareable under NDA, alongside the full technical report kept internal, saves a security team a quarter of its year, and it is the same pack that clears a SOC 2 or ISO 27001 review. The SOC 2 penetration testing provider comparison and the pentest evidence auditors accept guide are the right companions here.
Named, certified penetration testers, and a retest in the price. Ask for the names, certifications and CVE record of the people who will be on the engagement, written into the statement of work, and for both firm-level CREST accreditation and the individual certifications testers hold. Anonymous testers are a procurement risk: you cannot evidence competence to a board with a logo. Retest belongs in the base price for the same reason, because 3.2.6 asks for remediation reporting against defined timelines and a retest sold as a change order tends not to happen.
A portal and a board summary, not a PDF in an email. Programmes at this size need findings in a system the remediation owners already live in, with severity, owner, due date, status and an export the risk function can reconcile against the cyber risk profile 3.1.8 requires FRFIs to "maintain, and report on," plus a two-page summary a non-technical audit or risk committee can read: scope, classes of weakness found, business exposure, what is fixed, what remains under a compensating control.
Procurement and TPRM fit. The provider is itself a third party, so expect to run them through your own onboarding: questionnaire responses, their own testing evidence, insurance, subcontractor position, data residency and handling of your findings data. Canadian institutions frequently require that engagement data stay under Canadian or UK control, and a provider who cannot answer that in writing stalls in vendor risk review for months.
Multi-entity scoping and both cadences from one provider. One master agreement across parent, subsidiaries and the US entity removes a procurement cycle per entity per year. And because B-13 asks for a minimum frequency and defined triggers, you need a provider who sells both: an annual engagement serves the frequency, while testing that can start when a major release ships rather than when a purchase order clears serves the triggers. Our explainer on continuous PTaaS and the comparison of continuous red teaming against an annual pentest set out where each model fits.
What a supervisor asks to see
OSFI publishes no penetration testing evidence checklist, so the honest framing is this: what satisfies B-13 is the evidence demonstrating each of 3.1.2's four obligations was met, plus the remediation trail 3.2.6 asks for.
The documented testing frequency and its basis. The most important document and the one most often missing. Not "we test annually," but the minimum frequency by asset class, its risk rationale, and its approval through the risk management framework Principle 3 requires.
The trigger list, and the log showing when one fired.
The threat inputs. Sector reporting, the threat models maintained under 3.1.6, and the tactics you chose to emulate. This is what makes the test intelligence-led rather than generic.
The scope statement and the rules of engagement, naming systems, applications, IP ranges, cloud accounts and roles, with exclusions and their reasons, testing windows, escalation contacts and the risk mitigation controls 3.1.2 requires.
The full technical report, with reproduction steps, affected assets and severity ratings under a stated methodology, because 3.1.3 asks for ranking "using a standard risk measurement methodology."
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.
The remediation record against defined timelines and the retest report confirming closure, feeding the cyber risk profile 3.1.8 requires.
The third-party equivalent of items 4 to 7 for each critical provider supporting the functions in scope, collected under the contractual right you negotiated when the arrangement was signed.
OSFI also publishes a technology and cyber risk management self-assessment tool alongside B-13. Running your testing evidence against it before a supervisory review is cheaper than discovering the gaps during one.
How B-13 maps to the frameworks you are also running
Most FRFIs and their providers run B-13 next to at least one customer-facing or cross-border regime, and the overlap is high enough that one well-scoped annual engagement can feed several evidence sets.
Requirement | Penetration testing position | Frequency named | Notes for a FRFI or its provider |
|---|---|---|---|
OSFI B-13, 3.1.2 | Named expressly, alongside red teaming, intelligence-led | None. The FRFI sets triggers and minimum frequencies | The frequency document is the evidence, not the number |
OSFI B-10 | Not named. Testing evidence is how a FRFI oversees a critical provider | None | Cadence and results-review rights live in the contract |
OSFI I-CRT | Regulator-led, scoped to critical business functions | Three years for SIBs and IAIGs; case by case for others | Advisory, expressly not setting regulatory expectations |
PCI DSS v4.0 Req. 11.4 | Named expressly, internal and external, documented methodology | At least every 12 months and after significant change | Card-handling scope. See our PCI DSS guide |
SOC 2 (TSC) | Not named as a control. Testing is evidence for the monitoring criteria | Not specified. Annual is convention | The default ask from a FRFI's vendor risk team. See our SOC 2 guide |
ISO/IEC 27001:2022 | Not a clause requirement. Annex A 8.8 and 8.29 | Not specified. Risk-treatment driven | Results feed the risk treatment plan and Statement of Applicability |
NYDFS 23 NYCRR 500.5(a)(1) | Named expressly, inside and outside the boundaries | At least annually | Bites any group with a New York licence. See our NYDFS guide |
EU DORA TLPT | Named expressly for designated entities | Multi-year cycle for designated entities | Relevant to groups with EU operations. See our DORA TLPT guide |
B-13 is the least prescriptive instrument in that list and the broadest in scope. Build a programme to satisfy the most prescriptive regime that applies to your group and B-13 is normally satisfied inside it, provided you also produce the frequency rationale and threat-intelligence linkage B-13 asks for and the others do not.
If your group holds a New York licence
This catches more Canadian institutions than people expect. A Canadian bank or insurer with a New York branch, agency or licensed subsidiary is a Covered Entity under the New York Department of Financial Services cybersecurity regulation, and 23 NYCRR 500.5(a)(1) requires penetration testing "from both inside and outside the information systems' boundaries" at least annually, unless the entity qualifies for a limited exemption. That is a hard number sitting next to B-13's soft one, and the consequence is straightforward: the New York entity sets the floor for the whole group, because running the Canadian estate on a looser cadence than the US one is difficult to defend to either supervisor. Most groups in this position scope one annual programme at the NYDFS cadence and report it into both. Our NYDFS penetration testing requirements guide covers the exemption thresholds and the certification that follows.
What the tests actually find
Stingrai's State of Penetration Testing 2026 analysed 1,206 verified findings from 55 penetration tests. 92.7% of tests surfaced at least one High or Critical finding, which is worth putting next to a frequency decision concluding that testing every other year is sufficient: an untested estate has an opinion about exposure, not a measurement. The false positive rate was 0.74% and the median Critical took 10.5 days to fix, which matters because 3.1.3 requires ranking "using a standard risk measurement methodology" and unvalidated scanner output corrupts both the ranking and the remediation queue. Authorisation and business logic findings concentrate in application testing, the class 3.2.3 names and the class 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
There is no OSFI rate card, and any figure presented as one is invented. What can be said is what the Canadian bands look like and which variables move them.
Published Canadian market research puts a penetration test at roughly C$5,000 to C$150,000 or more depending on scope, depth and compliance mandate (Packetlabs, 2025). Within that range, the bands most FRFI and third-party buyers land in, from Stingrai's 2026 benchmark ranges, are C$5,000 to C$12,000 for a small single-role web application, C$12,000 to C$25,000 for a standard multi-role SaaS application, C$15,000 to C$35,000 for a standard external network test, and C$40,000 to C$120,000 or more per year for a continuous testing subscription. At the Bank of Canada USD to CAD reference rate of 1.3943 on 7 August 2026, that continuous band is roughly US$28,700 to US$86,100 per year and a C$25,000 engagement is roughly US$17,900, so Canadian and US bands are broadly similar in real terms once converted. A full enterprise programme covering internal network, external perimeter, applications, cloud and a red team component sits above these bands and is always quoted rather than listed.
Four variables move the number. Critical business function count, because scoping by CBF rather than by IP count removes low-consequence assets. Both sides of the perimeter, since an external-only engagement is roughly half the work Principle 14 describes and the internal component is usually the larger half for an institution with an Active Directory estate. Application role complexity, because authorisation testing scales with role pairs rather than page count, and a broker or advisor portal with client, advisor, branch administrator, operations and support roles has a matrix several times larger than a single-role product. Retesting, because a quote that excludes it is not comparable to one that includes it. The average cost of a pentest in Canada covers the domestic market in detail and the pentest cost calculator produces a scoped estimate from asset counts.
Stingrai publishes fixed package prices rather than a metered rate. The pricing page lists an Autonomous Pentest at 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 associated APIs, with the same tiers running continuously at US$650 and US$1,275 per month on a 12-month engagement. A full FRFI scope covering internal network, external perimeter, applications and cloud is quoted through Get a Quote.
What Stingrai delivers against a B-13 scope
Stingrai is a CREST-accredited penetration testing service provider, founded in 2021 and headquartered in Toronto with a London, UK office. OSCE³, OSWE, OSEP, CREST CRT certified pentesters, who are also world-class security researchers and bug bounty hunters, with 18 published CVEs and bug bounty Hall of Fame listings at Apple, Google, the US Department of Defense and the US Federal Reserve. Choose from fully human-led or hybrid (AI agents plus human penetration testers) engagements across web, API, mobile, AI and LLM, cloud, network, Active Directory and social engineering penetration tests and red team engagements, delivered through its PTaaS portal, and its penetration testing supports FRFI and third-party B-13 programmes by producing the scope statement, attack-path narrative, technical report, remediation record and retest evidence described above.
Annual or continuous, both available. An institution can buy a one-time annual test against a documented minimum frequency, or run continuous testing so the defined triggers in 3.1.2 are covered without a new procurement each time. Both are published offerings.
Certified penetration testers and Snipe work concurrently. Snipe is Stingrai's AI agent for web application penetration testing, including the application's APIs, available for autonomous web testing or alongside penetration testers in a Hybrid web engagement. It hunts the complex classes 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 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, and both contribute findings across all severities. Network, cloud and internal scopes are delivered by the penetration testing team.
Named testers, a published research record, and retest included. The team holds OSCE3, OSCP, OSWE, OSEP, CREST CRT, CISSP and CRTO among other certifications, has published 18 CVEs and presents research at DEFCON and BSides, with tester names written into the statement of work. Retest is included, which converts a finding list into the remediation-against-timelines evidence 3.2.6 asks for. Red teaming services cover institutions whose 3.1.2 decision calls for objective-based testing beyond technology, with a worked example in the adversary simulation in telecom case study.
What this means for FRFIs and their critical providers
Write the frequency down, then defend it. B-13's testing obligation is procedural before it is technical, and the document naming your minimum frequency, its rationale and its approval is the artefact a supervisor asks 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. Annual testing of the CBF-supporting estate, plus change-driven tests, is the market-normal answer for everyone else.
Let the strictest applicable regime set the floor. If any entity in the group holds a New York licence or handles cardholder data, its annual requirement effectively governs the group's cadence.
Make the test intelligence-led in a way you can evidence. If nothing in your scoping document references a threat, your test is not intelligence-led, whatever the statement of work says.
Evidence cumulative impact and closure. The attack-path narrative in 3.1.3 and the remediation-against-timelines reporting in 3.2.6 are the two things scanners cannot produce and the two things reviews most often find missing.
If you sell into FRFIs, buy the evidence pack, not the cheapest test. One annual engagement with retest, a shareable summary letter and a portal closes B-10 diligence for every institutional client at once.
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." 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 an Advisory dated 1 April 2023 whose 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)." Everyone else "may request an I-CRT assessment and OSFI will evaluate the request on a case-by-case basis." Applying three years to a mid-sized FRFI misattributes a document that says on its face it is not setting expectations.
What should a FRFI look for in a penetration testing vendor?
Evidence that answers B-13 on its face rather than a finding list: a scope statement tied to critical business functions, documented threat inputs, rules of engagement carrying the risk mitigation controls 3.1.2 requires, a stated severity methodology, attack-path analysis, a remediation record and an included retest. Beyond the report, the practical criteria are named and certified penetration testers written into the statement of work, firm-level CREST accreditation, a findings portal that integrates with the remediation workflow, a board-level summary the audit or risk committee can read, a summary letter shareable for third-party diligence, multi-entity scoping under one master agreement, and both annual and continuous engagement models from the same provider.
What does a fintech or SaaS provider selling into Canadian banks need?
The same evidence pack the institution holds for itself, because Guideline B-10 keeps accountability for third-party risk with the FRFI, which discharges it through contract terms and diligence. In practice: an annual penetration test covering the application, its APIs and the cloud environment behind it, a retest confirming closure, a summary letter shareable under NDA, and answers on tester identity, methodology, severity ranking and remediation timelines. The same package clears SOC 2 and ISO 27001 reviews, which is why most providers buy it once and reuse it. Our fintech penetration testing provider guide covers the vendor landscape for this buyer.
When did Guideline B-13 come into effect, and who does it apply to?
1 January 2024, per OSFI's release letter, not the 31 July 2022 publication date on the guideline page. It applies to all federally regulated financial institutions, "including foreign bank branches and foreign insurance company branches," covering banks, life and fraternal companies, property and casualty companies, and trust and loan companies. Provincially regulated credit unions and insurers answer to their provincial regulator instead.
What evidence does an OSFI supervisor expect from a penetration test?
OSFI publishes no testing evidence checklist, so the practical answer is the evidence demonstrating each obligation in 3.1.2 and 3.2.6 was met: the documented minimum frequency and its risk basis, the trigger list, the threat inputs that shaped scope, the scope statement with reasoned exclusions, the rules of engagement, the technical report with a stated severity methodology, the attack-path analysis 3.1.3 asks for, the remediation record against defined timelines, and the retest confirming closure.
Does a vulnerability scan satisfy B-13?
Not on its own, and the guideline separates the activities: vulnerability assessment sits in 3.1.3, penetration testing and red teaming in 3.1.2, application scanning in 3.2.9. Section 3.1.3 also closes with a sentence a scanner cannot answer, asking FRFIs to "consider the potential cumulative impact of vulnerabilities, irrespective of risk level, that could present a high-risk exposure when combined." Chaining low-rated weaknesses into a high-impact path is what a penetration 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."
Related reading
Best Cloud Penetration Testing Companies for AWS and SOC 2 (2026)
Pentest Evidence Auditors Accept: SOC 2, ISO 27001, PCI DSS and CMMC (2026)
References
OSFI. 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. Source of every B-13 quotation on this page.
OSFI. OSFI releases final Guideline B-13, letter. 2022. https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/osfi-releases-final-guideline-b-13-technology-cyber-risk-management-letter-2022. The 1 January 2024 effective date.
OSFI. 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. The not-a-policy-instrument statement, the SIB and IAIG scope, the Table 2 cadence and the testing taxonomy.
OSFI. Guideline B-10, Third-Party Risk Management. https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/third-party-risk-management-guideline.
OSFI. Technology and Cyber Security Incident Reporting Advisory. Effective 13 August 2021. https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/technology-cyber-security-incident-reporting. The 24-hour reporting requirement.
OSFI. 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.
New York State Department of Financial Services. 23 NYCRR Part 500, section 500.5(a)(1). https://www.dfs.ny.gov/industry_guidance/cybersecurity
Packetlabs. Penetration testing cost in Canada, 2025. The C$5,000 to C$150,000 market range.
Bank of Canada. Daily exchange rates. USD to CAD 1.3943 on 7 August 2026. https://www.bankofcanada.ca/rates/exchange/daily-exchange-rates/
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.
Stingrai. Average Cost of a Penetration Test in Canada 2026. https://www.stingrai.io/blog/average-cost-of-pentest-canada-2026. The Canadian benchmark bands quoted above.
Stingrai. Pricing. https://www.stingrai.io/pricing. Published one-time and continuous package prices for one web application and associated 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 and B-10 programmes by producing the scope statement, intelligence-led attack paths, technical report, remediation record and retest evidence a supervisor or a client's vendor risk team 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 web engagements, 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.
