OSFI B-13 and SOC 2: what maps and what does not

If a Canadian bank or insurer is asking about B-13 during a vendor review, the obligation is theirs and the evidence has to come from you. A SOC 2 report covers a good part of what they need and leaves specific pieces uncovered.

Last reviewed 2026-09-18Written by Jacob Masse, TrazTech Inc.

OSFI Guideline B-13, Technology and Cyber Risk Management, came into effect on 1 January 2024 and applies to federally regulated financial institutions: banks, life insurance and fraternal companies, property and casualty companies, trust and loan companies, and foreign bank and insurance branches. It does not apply to their software suppliers. What happens instead is that the institution has to manage the technology and cyber risk arising from arrangements it depends on, and it does that by asking you.

So a SaaS vendor never has a B-13 obligation and frequently has a B-13 problem, in the form of a questionnaire from a customer who does. A SOC 2 Type 2 report answers a useful share of it. Knowing which share saves a long exchange.

What B-13 actually contains

The guideline is principles-based rather than a control list, and it is organised into three domains. OSFI applies it proportionately to the size, nature, scope and complexity of the institution.

Governance and risk management

Accountability for technology and cyber risk, a risk management framework that covers it, and the reporting that lets senior management and the board see the position.

Technology operations and resilience

The asset management, change management, incident and problem management, capacity planning, disaster recovery and resilience testing that keep technology services running and recoverable.

Cyber security

Identifying and defending the attack surface, detecting and responding to incidents, and recovering from them, with the security controls that underpin each.

OSFI defines technology and cyber risk in B-13 as risk arising from any inadequacy, disruption, failure or damage from unauthorised access or use of technology assets, taking in IT failures, data incidents and cyber incidents. That definition is broader than a security framework, which is the root of most of the mapping gaps below: B-13 cares about availability and operational resilience to a degree that a Security-only SOC 2 does not.

How a SOC 2 report maps

The table below is a practical mapping, not an official crosswalk. OSFI publishes no mapping to the Trust Services Criteria and nobody should present one as though it were authoritative.

Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.

The Availability criterion is usually the gap

Most first SOC 2 reports are Security only, because Security is the sole mandatory Trust Services Criterion and every additional one adds scope, cost and evidence. That is a sound default for a general enterprise buyer and a poor fit for a financial institution, because a large part of B-13 is about keeping services running and recovering them when they fail.

If regulated financial institutions are a real segment for you, adding Availability is usually the single highest-value scope change you can make. It brings recovery objectives, resilience testing and capacity into the examined set, which is exactly the material that otherwise turns into a long questionnaire thread. The decision belongs in scoping rather than in year two, so it is worth reading how the criteria are chosen before the first engagement.

What the review actually asks for

1. The full SOC 2 report, not the certificate page. A financial institution's reviewer reads Section 4, the tests and results, and looks at exceptions and management responses. See how to read a SOC 2 report for what they are looking at.
2. The complementary user entity controls. The things the report assumes the customer does. Reviewers check these because an unallocated CUEC is a gap in their own framework, not yours.
3. A current penetration test and the remediation evidence. Findings alone are half an answer. What was fixed, when, and what the retest showed is the other half.
4. Recovery objectives and the last test of them. Stated targets and a dated test result.
5. Subprocessors, with locations. Concentration risk is a real part of the review and your suppliers are part of their picture.
6. Incident notification commitments. How quickly you will tell them, triggered by what. Institutions have their own reporting obligations to OSFI on short timelines, so a vague commitment from you is a problem for them.
7. Exit and portability. What happens to their data if the arrangement ends, in what format, on what timetable.

Asked for it and you have no SOC 2 yet

A regulated buyer asking these questions mid-deal is the common case, and a first Type 2 is six to twelve months away. The deal does not have to wait for it, and what you send in the meantime decides whether the review stalls.

1. Say what you have and when the rest arrives. A dated plan with a named auditor engaged carries real weight with a reviewer whose own obligation is to assess and document risk, not to collect certificates. An unanswered questionnaire carries none.
2. Send the penetration test and the remediation evidence. A current test with the fixes traced to closure is the single most useful artifact you can produce before a report exists, because it shows a control environment operating rather than described.
3. Write the resilience answers down properly. Recovery objectives, the date of the last restore test, and what the test showed. This is the block a Security-only report will not cover later either, so the work is not wasted.
4. Produce the subprocessor list with locations. Concentration and residency questions are asked of every supplier and the list takes an afternoon.
5. Commit to notification in the contract. A defined trigger and a defined clock, because the institution has its own reporting timelines and a vague commitment from you is an unquantified risk on their register.

A Type 1 can also carry a review while a Type 2 window runs, which is the usual sequencing when a regulated deal arrives before the program does. The trade-offs are in Type 1 against Type 2.

A sensible order of work

For a company that has decided regulated financial institutions are worth selling to:

1. Scope the SOC 2 with Availability included if resilience questions are going to come up, which they will.
2. Write the artifacts B-13 reviewers ask for that no report contains. Asset inventory, recovery objectives with a test record, subprocessor list with locations, notification commitment. Each is a page or two and each removes a round trip.
3. Map your own controls to the three domains once, and keep the mapping. Reviewers ask the same questions in different words, and a maintained mapping turns a two-week thread into an attachment.
4. Keep the penetration test current and keep the remediation evidence with it.

Nothing in that list is unique to B-13. It is the same material a demanding enterprise security review asks for, arranged the way a regulated institution reads it.