Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.
All security →SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.
All frameworks →Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.
Read the blog →B-13 sets technology and cyber risk expectations for federally regulated financial institutions. It does not bind you. It arrives anyway, as contract terms, questionnaires, evidence requests and audit rights.
OSFI Guideline B-13, Technology and Cyber Risk Management, sets expectations for federally regulated financial institutions across governance and risk management, technology operations and resilience, and cyber security. It took effect on 1 January 2024. It applies to institutions, not to their suppliers. Vendors meet it through B-10, Third-Party Risk Management, which is the route almost every obligation actually travels: materiality tiering, due diligence, contractual terms, ongoing monitoring, and exit planning. What an institution asks you to evidence is predictable: an independent report on your controls, tested resilience with real recovery objectives, an incident notification clock shorter than their own regulatory clock, a subprocessor list, concentration and residency answers, and financial viability. The single most useful thing to learn early is how the institution has tiered you, because the tier determines everything else.
The Office of the Superintendent of Financial Institutions supervises federally regulated financial institutions: the chartered banks, federally incorporated trust and loan companies, federally regulated insurers, fraternal benefit societies, and federally regulated private pension plans. Guideline B-13, Technology and Cyber Risk Management, sets out OSFI's expectations for how those institutions manage technology and cyber risk. It was published in 2022 and became effective on 1 January 2024.
B-13 is a guideline, not a regulation. OSFI supervises against it, and an institution that cannot demonstrate sound practices in the areas it covers will hear about it through the supervisory relationship. That is a more effective enforcement mechanism than a fine, because it is continuous and it is attached to the institution's standing with its regulator.
It does not apply to you as a vendor. There is no B-13 certification, no B-13 attestation, and no registry of compliant suppliers. Any firm offering you one is selling something that does not exist. What exists is a set of expectations your customer must meet, some of which they can only meet by extracting commitments and evidence from you.
Establish early which category your buyer sits in, because it determines how much room there is to negotiate. A federally regulated bank or insurer has a supervisory relationship it must be able to defend, and its vendor risk function has real limits on how far it can bend. A provincially regulated credit union, a Quebec caisse, a provincial insurer or an unregulated fintech is not supervised by OSFI at all, though provincial regulators run their own equivalents and the Autorité des marchés financiers in Quebec is the most developed of them. Unregulated fintechs often apply bank-shaped terms out of habit, usually because their own bank partner flowed the obligations down to them, and they have far more room to move than they realize.
B-13 is organized into domains, each with principles and expectations. Reading it as a vendor, the useful exercise is to translate each domain into the questions it generates in a due diligence workbook.
Governance and risk management. The institution is expected to have accountability for technology and cyber risk defined at senior levels, a technology and cyber strategy, a risk management framework that covers technology risk explicitly, and reporting that reaches the board. The questions this produces for you are about who owns security at your company, whether that person is a named individual with authority, how risk decisions get made and recorded, and whether there is any independent assurance over the program. This is the domain a named security owner answers directly, and the reason a shared inbox as your security contact reads badly.
Technology operations and resilience. Expectations here cover asset management, technology lifecycle including end-of-life management, change and release management, patch management, incident and problem management, capacity, availability, disaster recovery and backup. The questions are about your asset inventory, your change process, how quickly you patch by severity, what your recovery objectives are, whether you have tested a restore, and what happens on a regional failure. This is the domain vendors underestimate, because security teams are practised at answering security questions and much less practised at answering availability ones.
Cyber security. Expectations cover identifying the cyber threat landscape, protective controls including identity and access management, network and endpoint security, data security, secure development, detection through logging and monitoring, response, and recovery. The questions are familiar to anyone who has done a SOC 2: access reviews, multi-factor authentication, encryption, vulnerability management, penetration testing, logging retention, alerting, and the incident response plan.
Two things run through all three domains. The first is that OSFI expects the depth of the practice to be proportionate to the institution's size, risk profile and complexity, which is why a Schedule I bank's workbook is heavier than a small insurer's. The second is that OSFI expects evidence of operation rather than documentation of intent, and the institution passes that expectation straight through to you.
Three OSFI guidelines are cited in vendor conversations and they are frequently confused, including by the people citing them.
B-13 is technology and cyber risk management: what good looks like inside the institution's own technology estate and, by extension, inside the technology it depends on.
B-10, Third-Party Risk Management, is the guideline that actually governs the institution's relationship with you. It sets expectations for identifying and assessing third party arrangements, tiering them by criticality, conducting due diligence proportionate to that tier, putting appropriate terms in the contract, monitoring performance and risk on an ongoing basis, managing concentration, and planning for exit. When an earlier draft of B-13 contained a third party domain, that material was consolidated into the revised B-10, which is why practitioners sometimes describe third party technology risk as a B-13 matter and sometimes as a B-10 matter. Both descriptions point at the same set of obligations; the operative document for the vendor relationship is B-10.
E-21, Operational Risk Management and Resilience, sits above both. It deals with the institution's ability to deliver critical operations through disruption, including identifying critical operations, setting tolerances for disruption, mapping the people, processes, technology and third parties that support them, and testing against severe but plausible scenarios. If you support a critical operation, E-21 is the reason you may be asked to participate in scenario testing rather than merely describe your continuity plan.
Separately, OSFI expects institutions to report technology and cyber security incidents to it promptly, on a clock measured in hours rather than days, through its incident reporting advisory. That regulatory clock is the origin of the aggressive notification windows in your contract. Your customer cannot meet a 24 hour regulatory reporting obligation if they hear about an incident in your service on day three.
A useful mental model: E-21 says the institution must keep operating. B-13 says its technology must be sound and resilient. B-10 says it must manage the third parties its technology depends on. You are a third party inside a technology estate that supports a critical operation, so all three converge on your contract.
The single most useful thing to learn in a financial institution deal is how they have tiered you. Third party frameworks classify arrangements by criticality or materiality, and the tier drives the depth of due diligence, the contract terms, the frequency of ongoing monitoring, and whether you end up inside the institution's resilience testing.
The factors that push you up a tier are whether an outage of your service would interrupt a business function the institution considers critical, whether you hold or can access customer personal or financial information, whether you have privileged access into their environment, how hard you would be to replace, and whether the institution would face regulatory or reputational consequences if you failed.
A marketing analytics tool used by twelve people in one department is low tier and the review will be light. A service in the payment path, or one holding account holder personal information, is high or critical, and the process changes shape entirely: senior sign-off inside the institution, full contract terms with no material deviations, annual deep-dive or on-site assessment, inclusion in exit and continuity planning, and possibly participation in scenario exercises.
Ask your champion directly: how have you tiered this arrangement, and what does that tier require of us. Vendor risk teams will usually tell you, and knowing the answer in week two rather than week fourteen changes how you resource the deal and whether you bid at all.
A related and underused move is to argue the tier where it is genuinely wrong. If you have been tiered as critical because someone assumed you had access to customer data that you in fact never see, correcting that assumption early removes half the process. Vendor risk teams are not looking for work; they are looking for a defensible record.
The evidence set for a high tier arrangement is consistent enough to prepare in advance. Assembling it reactively is what turns a three month review into a nine month one.
A SOC 2 Type II report covering at least Security, and often Availability and Confidentiality, does most of the heavy lifting. Institutions read them properly: they check the period, the scope, the subservice organizations and the carve-out or inclusive method, the complementary user entity controls, and every exception in the testing results. Expect to be asked to explain each exception and what you did about it. A bridge letter covering the gap between the report period end and the current date is a standard follow-up and you should have one ready rather than producing it on request.
An ISO 27001 certificate is accepted, often alongside rather than instead of a SOC 2 report, and the statement of applicability will be requested with it. Which one to lead with depends on your buyer mix, and Canadian financial institutions generally read SOC 2 more fluently.
A recent penetration test, usually within twelve months, by an independent party, with the remediation status of every finding. Institutions increasingly ask for the report itself rather than an attestation letter, under NDA. They will notice if the scope excluded the parts of your product they actually use.
Your incident response plan, with evidence it has been exercised. The exercise record matters more than the document. Our tabletop guide covers what a defensible exercise record contains.
Business continuity and disaster recovery evidence: stated recovery time and recovery point objectives, and evidence of a tested restore with dates and results. A four hour recovery time objective in a contract, against nightly backups and a manual restore nobody has ever run, is a commitment you will fail in public.
A subprocessor list with the purpose, location and criticality of each, plus evidence that you assess them. Institutions care about fourth party risk because their own regulator cares about it.
Financial viability. This is the request technical founders find strangest: audited or reviewed financial statements, or at minimum evidence of funding and runway. The institution needs to believe you will still exist in three years, because moving off you is expensive and disruptive.
Plus the ordinary set: insurance certificates with limits, policy documents, an organizational chart showing who owns security, background check practices, secure development lifecycle description, encryption specifics, logging retention, access review cadence and evidence, and increasingly a statement on artificial intelligence components and whether customer data trains models.
Five areas cause most of the delay, and each has a negotiated position that vendor risk teams accept regularly.
Incident notification. Institutions open at immediate notification of any security incident. The word doing the damage is "any". Define the trigger: a confirmed security incident affecting the institution's data or the services provided to them, with notification without undue delay and in any event within a stated number of hours of confirmation. That is achievable and it maps to their own regulatory clock. Notification of every suspected event within an hour is not achievable, and agreeing to it creates a contractual breach every time your monitoring alerts.
Audit and inspection rights. The institution needs the right to assess you, and OSFI needs to be able to reach you through them. Expect a clause granting the institution, its auditors and the regulator access to premises, records and personnel. The workable position is reliance on your SOC 2 Type II and penetration test in the ordinary course, an on-site or deep-dive assessment once per year on reasonable notice, and additional access for cause following an incident. Institutions accept this frequently, because they do not want to run fifty on-site assessments a year either.
Subcontracting and fourth parties. They will want a material subprocessor list, notice before you add or change one, and sometimes a right to object. The negotiable part is consent versus notification. Thirty days advance notice with a right to terminate if they object is common ground. Blanket prior written consent for every subprocessor change is a trap if you use a hyperscaler that adds regions and services continuously.
Exit and transition. The institution must be able to show it could move off you in an orderly way. That means a documented exit plan, data export in a usable format within a stated timeframe, transition assistance for a defined period after termination, and deletion certification afterwards. This is easier to satisfy than teams fear: a documented export capability with a named format and a tested timeline usually does it. What fails is a plan that has never been exercised.
Liability. Expect pressure to carve data breach and confidentiality out of your liability cap, or to apply a multiple of fees rather than the standard cap. This is a commercial decision rather than a compliance one, and it needs to be made deliberately with your insurance limits in front of you, not conceded late in a quarter to close a deal.
Security questions have a well-worn script. Availability questions do not, and they are where a technically strong vendor most often loses credibility.
Have recovery time and recovery point objectives written down, and make sure they match what your architecture can actually deliver. Then evidence a restore test: date, scope, what was restored, how long it took, what went wrong, what was fixed. Institutions increasingly ask for that record rather than a policy stating that backups are taken. If you have never done one, do one before the review rather than during it.
Expect concentration questions: which cloud provider, which regions, what happens on a regional failure, and whether you have ever failed over. "Our provider has excellent uptime" is the wrong answer, because the institution's obligation is to understand its exposure, not to be reassured. The right answer states your architecture plainly, including the parts that are single-region, and describes what the impact would be and how long recovery would take. A vendor who says "we are single-region today, here is what a regional outage would mean, here is our plan and timeline" is materially more credible than one who implies multi-region resilience that does not exist.
End-of-life technology comes up more than people expect, because B-13 sets expectations around managing technology assets through their lifecycle. That flows down as questions about unsupported operating systems, deprecated runtimes and libraries past end of support. A clear answer with a remediation roadmap is fine. Not knowing is a finding.
Capacity and performance under stress get asked at the higher tiers: what your load testing shows, what your scaling limits are, and what happens under a volume event. If the institution has a seasonal peak, they will ask how your service behaves during it.
If you support a critical operation, you may be asked to participate in the institution's own scenario testing. That is a reasonable ask and worth agreeing to, because the exercise usually surfaces mismatches between your notification process and theirs while they are still cheap to fix.
A financial institution vendor review is not one conversation with one team. You will typically deal with a business sponsor who wants the deal, a procurement function that owns the contract, a third party risk team that owns the assessment, an information security function that reads your report and asks the technical questions, privacy and legal, and sometimes a second line risk function that reviews the assessment itself. Any one of them can pause the process, and none of them is measured on how fast your deal closes.
The assessment usually arrives as the institution's own workbook rather than a standard questionnaire, running to several hundred lines across security, privacy, resilience, financial viability and sometimes environmental and labour questions. Some institutions accept a shared assessment or an industry questionnaire as a starting point, and it is worth asking.
Elapsed time from first questionnaire to signed contract for a high tier arrangement is commonly three to nine months. Compressing it is mostly a matter of removing round trips, which means having your report, bridge letter, penetration test, subprocessor list, continuity test evidence, insurance certificates, financial statements and policy set ready to send on the first request rather than assembling each one in response.
A practical tactic: ask for the full workbook up front rather than answering it section by section. Reviews that proceed in tranches take three times as long, because each tranche has its own review cycle and its own waiting period.
Another: nominate one named person on your side who owns the review end to end, and make sure they can get answers from engineering without a queue. The most common cause of a stalled review is not a failed control, it is a question that sat unanswered for eleven days.
Data residency comes up in nearly every financial institution conversation and it is misunderstood on both sides.
There is no general Canadian privacy law requiring financial institution data to stay in Canada. What exists is a set of expectations around access to records. Federal financial institution legislation contains record-keeping requirements, and OSFI has long-standing expectations that it be able to access an institution's records, which historically pushed institutions toward maintaining records in Canada or toward specific arrangements when they are held elsewhere. The practical consequence for a vendor is not a prohibition, it is that the institution needs to be able to produce records to its regulator regardless of where your infrastructure sits.
Separately, the institution has privacy obligations under PIPEDA, which applies to banks and other federal works and undertakings including for their employee information. PIPEDA permits transfers for processing subject to the accountability principle and comparable protection through contract. It does not require Canadian storage.
So the honest answer in a bank questionnaire has three parts: where the data actually is, by region, including backups, logs and support tooling; who can access it and from where, including your support team's geography; and what contractual and technical protections apply. If you can offer a Canadian region, offer it, because it removes an entire line of questioning. If you cannot, say so precisely and early rather than allowing it to surface in a security review. Our data residency guide covers how to write that answer.
The related question that catches people is support access. A distributed support team that can view production data from outside Canada is a fact the institution will want to know, control and sometimes restrict. Region-restricted access, field-level masking or a Canadian-only support tier are the usual answers.
The obligation does not end at signature, and this is the part that catches vendors who treated the review as a one-off sales exercise.
Expect annual reassessment with a refreshed questionnaire and updated evidence. Expect to be asked for your SOC 2 report every year, with a bridge letter. Expect an obligation to notify the institution of material changes: a change of control, a new material subprocessor, a significant architecture change, a material incident, or a change in where data is stored. Expect performance reporting against the service levels in the contract, and expect somebody to read it.
At the higher tiers, expect participation in the institution's continuity and scenario testing, and periodic deep-dive assessments. Some institutions run vendor days or require attendance at review meetings.
Practically, this means somebody at your company owns the relationship. Not the account executive who closed it, because they will move on, and not a shared inbox. Ongoing obligations to a regulated customer are a standing operational commitment, which is why this work usually lives in a retainer rather than being handled deal by deal.
The good news is that the second and third financial institution deals are much cheaper than the first, provided you kept the evidence current. The bad news is that letting it go stale costs almost as much as building it did, because a year-old data flow diagram and an expired penetration test put you back at the start of the queue.
If a financial institution deal is live now and you have nothing in place, the order below gets the most value soonest.
Week one: find out how you have been tiered and ask for the full assessment workbook. Nominate one owner internally. Collect what you already have: any report or certificate, the most recent penetration test, insurance certificates, and your policy set.
Weeks one to three: build the artifacts that do not require an audit. A data flow description. A subprocessor list with purpose, location and criticality. An architecture and resilience statement including regions, single points of failure, recovery objectives and what a regional failure would mean. An access model description including who at your company can reach production and how that is controlled.
Weeks two to six: fix the things that will fail the review regardless of paperwork. Standing production access, missing multi-factor authentication, no access reviews, unpatched end-of-life components, backups never restored, an incident response plan nobody has exercised. These are the findings that produce conditions on the contract.
In parallel: run a restore test and a tabletop, and write down both. Two days of work that convert several paper commitments into evidenced ones.
Then the audit. If you have no report, a SOC 2 Type I unblocks some deals and a Type II is what most institutions ultimately want, which means an observation window of three to twelve months. If the deal cannot wait, be candid: say a Type II is in progress with a stated period end, offer the Type I or the readiness assessment in the interim, and offer contractual commitments instead. Institutions accept that more often than vendors expect, especially where the tier is not critical.
Realistic budget for a small vendor doing this properly for the first time: the artifact and remediation work is measured in weeks of senior engineering time plus a few thousand dollars of testing, and the audit is the number in our SOC 2 cost guide. The expensive alternative is losing the deal in month seven.
Claiming B-13 compliance. There is no such thing for a vendor. It signals you do not understand the structure. Say instead that you support your institutional customers in meeting their B-13 and B-10 obligations, and list what you provide.
Not knowing your tier. You cannot resource a review you have not sized, and you may be spending critical-tier effort on a low-tier arrangement or the reverse.
Agreeing to an unachievable notification clock. It converts every noisy monitoring week into a contractual breach.
Implying resilience you do not have. Single-region stated plainly beats multi-region implied and later discovered. Reviewers verify.
Untested backups and untested plans. The evidence request is for the test record, not the document.
Answering the workbook in tranches. Every tranche has its own review cycle. Ask for all of it and answer it once.
Letting the evidence go stale after signing. Annual reassessment is real, and a stale artifact set puts the next deal back at the start.
| Institution obligation | Vendor evidence | Source guideline |
|---|---|---|
| Assess and tier third party arrangements | Accurate description of what data you hold, what access you have, and what business function you support. | B-10 |
| Due diligence proportionate to criticality | SOC 2 Type II or ISO 27001 certificate, penetration test with remediation status, policy set, financial statements. | B-10, informed by B-13 expectations |
| Manage technology operations and resilience | Recovery objectives, evidence of a tested restore, architecture and region description, end-of-life technology position. | B-13 |
| Cyber security controls and monitoring | Access control and review evidence, multi-factor authentication, encryption specifics, logging retention, vulnerability management cadence. | B-13 |
| Report technology and cyber incidents to OSFI promptly | Contractual notification clause with a defined trigger and an hours-based clock, plus an exercised incident response plan. | OSFI incident reporting expectations, flowed down through the contract |
| Manage fourth party and concentration risk | Subprocessor list with purpose, location and criticality, your own vendor assessments, and a concentration answer. | B-10 |
| Maintain operational resilience through disruption | Continuity plan, participation in scenario testing where you support a critical operation, stated tolerances. | E-21 |
| Be able to exit the arrangement in an orderly way | Documented exit plan, export format and timeline, transition assistance period, deletion certification. | B-10 |
No. B-13 sets expectations for federally regulated financial institutions: banks, federally incorporated trust and loan companies, federally regulated insurers and pension plans. It does not bind their suppliers. Vendors encounter it because the institution must be able to demonstrate sound technology and cyber risk management across its estate, including the parts it buys, so the expectations arrive as contract terms, due diligence questionnaires, evidence requests and audit rights, principally through Guideline B-10 on third party risk management.
No, and there will not be one. OSFI does not certify or register vendors, and no attestation of B-13 compliance exists for a supplier. What financial institutions accept as evidence is a SOC 2 Type II report, an ISO 27001 certificate, an independent penetration test with remediation status, and specific artifacts such as tested recovery evidence, a subprocessor list and an exercised incident response plan. Claiming B-13 compliance signals a misunderstanding of the structure.
B-13 covers technology and cyber risk management inside the institution: governance, technology operations and resilience, and cyber security. B-10 covers third party risk management: how the institution identifies, tiers, assesses, contracts with, monitors and exits its arrangements with suppliers. Almost every obligation that reaches a vendor travels through B-10, while the substantive expectations about technology and cyber practice come from B-13. Draft material about third party technology risk was consolidated into the revised B-10, which is why practitioners use the two names interchangeably.
E-21 covers operational risk management and resilience: the institution's ability to deliver its critical operations through disruption, including identifying those operations, setting disruption tolerances, mapping the dependencies that support them and testing against severe but plausible scenarios. B-13 covers the technology and cyber layer of that picture, and B-10 covers the third parties within it. If you support a critical operation, E-21 is usually the reason you are asked to take part in scenario testing rather than simply describe your continuity plan.
Institutions commonly open at immediate notification, or within 24 hours, of any security incident, driven by their own obligation to report technology and cyber incidents to OSFI promptly. The workable negotiated position is notification without undue delay and in any event within a stated number of hours of confirming a security incident affecting the institution's data or the services provided to them. Define the trigger as confirmation rather than suspicion, or your monitoring will generate contractual breaches, and make sure the clock you agree to is one your on-call process has actually been exercised against.
No general Canadian law requires it, and PIPEDA permits transfers for processing subject to accountability and comparable contractual protection. What exists are record access expectations: the institution must be able to produce records to its regulator regardless of where the infrastructure sits. In practice many institutions prefer or require Canadian hosting as a contractual term. If you can offer a Canadian region, offering it removes a whole line of questioning. If you cannot, state precisely where data resides, who can access it and from where, and what protections apply.
For a high or critical tier arrangement, three to nine months from first questionnaire to signed contract is typical. Lower tiers move considerably faster. Most of the elapsed time is round trips rather than analysis, so the biggest lever is having the full evidence set ready to send on the first request: report and bridge letter, penetration test with remediation status, subprocessor list, resilience test records, insurance certificates, financial statements and policy set. Asking for the entire assessment workbook up front rather than answering in tranches also removes weeks.
Say so early and offer what you do have: a readiness assessment or gap analysis, a recent independent penetration test with remediation status, and a stated audit timeline with a period end date. Then offer contractual commitments in place of the report, such as tighter notification terms, an assessment right, or a milestone to produce the report by a date. Institutions accept this more often than vendors expect, particularly below the critical tier. What does not work is implying you have a report, or promising one on a date you have not scoped.
traztech Workspace has every control of whichever frameworks apply to you, written in plain English, with somewhere to attach the proof. Free to use, with no card and no trial clock.
No credit card, no trial clock, no locked features. We make money when someone wants help closing the gaps, not from the Workspace.
| traztech Workspace | Other GRC platforms | |
|---|---|---|
| Licence cost | $0. Free forever, no card, no paid tier | $7,500 to $50,000 a year, on an annual contract |
| Control library, evidence register, policy templates, risk register, vendor questionnaires, readiness scoring | Included | Included |
| What it costs inside an engagement with us | $0. You need a workspace either way | Unchanged. The subscription sits on top of the fee |
| What it does to your audit quote | $11,000 off a five-figure quote on one engagement, for a documented readiness position | Nothing. The audit firm prices your readiness, not your tooling |
Pricing in the right column is what compliance automation platforms are publicly reported to charge; none of them publish a number, so treat it as a range rather than a quote. The $11,000 came off the audit firm's own number once the readiness position was documented (the engagement). Where a paid platform is the better buy, and the fuller comparison, is on the Workspace page.
We size the review, build the evidence set the institution will ask for, and fix the findings that would otherwise put conditions on your contract.
Book a strategy callWant the human version?
Jacob sends a few short, practical notes on getting security and compliance right without the months of pain. No fluff, unsubscribe in one click. Reply anytime; it reaches him directly.
From Jacob Masse, founder of traztech. No spam, unsubscribe in one click.
Track record
Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.
At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15.