SOC 2 and OSFI B-10: What Canadian Financial Institutions Require From Their SaaS Vendors

A SaaS company closes a promising deal with a Canadian bank, sends over a clean SOC 2 Type 2 report expecting the security review to wrap up quickly, and instead receives a due diligence questionnaire considerably more extensive than anything a typical enterprise security team has asked before — questions about subcontractor transparency, concentration risk, exit plan feasibility, and contractual termination notice periods that have nothing to do with a standard SOC 2 auditor certification at all.

This is what selling into a federally regulated Canadian bank or insurer actually looks like once OSFI's Guideline B-10 enters the picture, and it's worth understanding clearly why a strong SOC 2 report — genuinely necessary, genuinely respected — still isn't the whole story for this specific buyer segment.

What OSFI B-10 Actually Is

The Office of the Superintendent of Financial Institutions, Canada's federal regulator for banks, insurers, and trust companies, issued Guideline B-10 on Third-Party Risk Management in April 2023, replacing a much older outsourcing guideline that dated back to 2001. The new Guideline is deliberately broader in scope than its predecessor — it applies to all third-party arrangements a federally regulated financial institution enters into, explicitly including SaaS services, not just traditional outsourcing relationships.

The single principle underlying the entire Guideline is worth stating plainly, because it explains why B-10-driven due diligence feels so much heavier than a standard enterprise security review: OSFI expects the financial institution to manage the risks related to every third-party arrangement it enters, and the institution retains full accountability for the business activities, functions, and services it outsources — regardless of how good the vendor's own security posture is. A financial institution cannot outsource its accountability to OSFI, even when it outsources the underlying function to a SaaS vendor. This is precisely why the bank's own due diligence team, not just their security engineers, ends up asking questions that go well beyond what a SOC 2 Type 2 audit was ever designed to answer.

Where a SOC 2 Report Fits — and Where It Stops

A SOC 2 report remains genuinely valuable input into a Canadian financial institution's due diligence process, and vendors shouldn't read any of this as SOC 2 reporting being unnecessary for this market — it isn't. What changes is the role it plays. Under B-10, a SOC 2 audit report functions as one piece of evidence supporting a much broader lifecycle-based risk management process: risk assessment before onboarding, formal due diligence, contract negotiation with specific mandatory terms, ongoing monitoring for the life of the relationship, and a tested exit plan for when the relationship eventually ends. A strong SOC 2 Type 2 report can meaningfully accelerate the due diligence phase specifically. It doesn't touch the other four stages at all, and a vendor unprepared for those stages will find the deal stalling well past the point where security review alone would have concluded.

Criticality Classification: Not Every Vendor Gets the Same Scrutiny

One of the more consequential elements of B-10 is that financial institutions are expected to classify third-party arrangements by criticality — essentially, how much disruption or harm would result if the vendor failed or was compromised — and calibrate the depth of due diligence, contractual protection, and ongoing monitoring accordingly. A SaaS vendor supporting a genuinely critical function, such as core transaction processing or customer-facing payment infrastructure, faces a materially more rigorous B-10 process than a vendor providing a peripheral, easily replaceable tool.

For vendors entering this market, understanding where their product is likely to land on this criticality spectrum before the sales conversation even starts is worth doing deliberately. A vendor that assumes its SOC 2 compliance alone will carry the deal, without anticipating that its specific function might be classified as critical by the bank's internal risk framework, tends to be caught flat-footed by the depth of the questionnaire that follows.

Contractual Requirements That Don't Show Up in a Standard SaaS Agreement

B-10 imposes specific contractual expectations for higher-risk arrangements that most SaaS vendors' standard terms of service simply don't contain. For high-risk third-party relationships specifically, contracts are expected to include termination clauses allowing the financial institution at least 30 days' notice — a provision most SaaS master service agreements, built for a general commercial market, don't include by default. Audit rights, allowing the institution or its designated auditor to verify the vendor's ongoing compliance posture, are similarly expected as standard contractual language for higher-criticality relationships, going beyond what a SOC 2 report alone provides as a periodic, backward-looking assurance.

Vendors that walk into a Canadian financial institution deal with a rigid, unmodifiable standard contract frequently find themselves in a longer legal negotiation than anticipated, simply because their default terms weren't built with B-10's specific requirements in mind.

Fourth-Party Risk and Concentration Risk: The New Emphasis Compared to the Old Guideline

Relative to the outsourcing guideline it replaced, B-10 places considerably more weight on risks that extend beyond the direct vendor relationship. Financial institutions are expected to understand and track fourth-party risk — meaning a SaaS vendor's own subcontractors and subprocessors — as well as concentration risk, where multiple critical functions depending on a single underlying provider creates a systemic vulnerability the institution needs to actively manage rather than discover after the fact.

For a SaaS vendor, this means transparency about its own subprocessor and subcontractor relationships isn't an optional nicety in a Canadian financial institution deal — it's an explicit, expected input into the bank's own risk assessment. A vendor unable to clearly disclose which subcontractors touch client data, and under what arrangements, is handing the institution's risk team a genuine gap in their own B-10 compliance obligation, which tends to become the vendor's problem in the form of a stalled or rejected deal.

Ongoing Monitoring and Exit Plans: The Lifecycle Doesn't End at Contract Signing

Two further B-10 expectations distinguish this process from a one-time security review entirely. Ongoing monitoring requires continuous oversight of the vendor's performance and risk profile for the life of the relationship, typically formalized through service level agreement scorecards tracking performance against agreed metrics — meaning the due diligence conversation doesn't conclude once the contract is signed, and vendors should expect periodic re-engagement rather than a single point-in-time assessment.

Exit planning is the requirement most vendors find genuinely unfamiliar. For critical third-party arrangements, financial institutions must maintain a documented, tested exit plan ensuring continuity of service if the arrangement is terminated or the vendor fails — and this plan isn't merely a written document sitting in a drawer; it's expected to be actively tested. For a SaaS vendor, this translates into a concrete practical question the bank's team will eventually ask: how feasible, in practice, is it for the institution to migrate off this platform if it needs to, and what does the vendor's own support for that transition actually look like?

What This Means Practically for SOC 2-Compliant Vendors Entering This Market

For a SaaS company with a solid SOC 2 compliance program targeting Canadian federally regulated financial institutions specifically, the practical preparation goes beyond simply having the report ready. It means anticipating a criticality-based classification of the product before the sales conversation starts, being prepared to negotiate contract terms that include appropriate termination notice and audit rights rather than relying on a rigid standard agreement, maintaining a clear and current disclosure of subcontractors and subprocessors, and having a genuine, articulable answer to what an exit or migration from the platform would actually involve for the client.

Vendors that treat their SOC 2 reporting as the complete answer to a Canadian bank's due diligence process consistently find themselves managing a longer, more frustrating sales cycle than vendors who understand from the outset that B-10 due diligence is a lifecycle process the SOC 2 report only partially informs.

Where Accorp Fits In

Accorp Partners helps SaaS vendors preparing for sales cycles with Canadian federally regulated financial institutions map exactly what OSFI B-10-driven due diligence will actually require beyond the SOC 2 report — from criticality-readiness and subcontractor transparency to contract terms and exit plan documentation — so a strong SOC 2 Type 2 audit becomes a genuine accelerant rather than the vendor's whole, incomplete story.

Frequently Asked Questions

1. Does OSFI directly regulate or audit SaaS vendors under B-10?

No. OSFI regulates the federally regulated financial institution itself, which remains accountable for its third-party arrangements. Vendors aren't directly regulated by OSFI but must satisfy the institution's own B-10-driven due diligence and contractual requirements.

2. Is a SOC 2 Type 2 report sufficient for a Canadian bank's B-10 due diligence process?

It's a genuinely valuable input, particularly for the initial due diligence phase, but B-10 requires a broader lifecycle process including criticality classification, specific contract terms, ongoing monitoring, and tested exit planning that a SOC 2 report alone doesn't cover.emphasises

3. What contractual terms does B-10 typically require that standard SaaS agreements don't include?

For higher-risk arrangements, expect requirements like a minimum 30-day termination notice period and audit rights allowing the institution to verify ongoing compliance — provisions not standard in most general-market SaaS contracts.

4. Why does B-10 care about a vendor's own subcontractors?

B-10 emphasizes fourth-party and concentration risk, requiring financial institutions to understand dependencies beyond their direct vendor relationship, which means vendors need to be transparent about their own subprocessors as part of the institution's risk assessment.