How to Choose a Technology Partner That Meets OSFI B-10 and B-13 Requirements

Introduction

For Canadian financial institutions, choosing a technology partner is no longer just a question of technical capability, cost, or service delivery. It is also a risk management decision that can affect operational resilience, cybersecurity, and regulatory oversight.

Banks, insurers, and other federally regulated financial institutions increasingly depend on cloud providers, managed service providers, cybersecurity firms, and other technology partners to support critical operations. But outsourcing a service does not outsource the risk. If a third party experiences a cyber incident, service disruption, control failure, or issue within its own supply chain, the financial institution still needs to understand and manage the resulting exposure.

This is where OSFI B-10 and B-13 become important. B-10 sets expectations for managing risks associated with third-party arrangements, while B-13 focuses on technology and cyber risk management. Together, they raise an important question for Canadian financial institutions: Does your technology partner give you the controls, visibility, evidence, and resilience you need to manage that relationship effectively?

This guide looks at what to evaluate before choosing a technology partner, the red flags to watch for, and how to identify gaps in existing vendor relationships.

Why Technology Partner Selection Matters for OSFI B-10 and B-13

Technology providers can support critical business functions, from payment systems and customer platforms to cloud infrastructure and cybersecurity operations. Their performance can directly affect an institution’s security and operational resilience.

Consider a managed IT provider responsible for maintaining critical infrastructure. A missed security patch could leave systems exposed. A poorly tested recovery process could prolong an outage. A subcontractor with inadequate controls could create another point of vulnerability.

These examples show how a technology relationship can introduce operational, financial, legal, and cybersecurity risks.

OSFI B-10 requires institutions to identify and manage risks arising from third-party arrangements. Its expectations extend across the relationship, including provider selection, due diligence, contracting, ongoing monitoring, and eventual exit. The intensity of these activities should reflect the arrangement’s risk and criticality.

Three considerations should guide the evaluation:

• Operational dependency: The institution needs to understand how a provider’s failure could affect critical business services.
• Technology and cyber exposure: The assessment should cover access to systems, sensitive data, security controls, and dependencies on other providers.
• Continuity and accountability: The institution must retain sufficient oversight, evidence, and contingency options to manage problems when they arise.

Vendor selection is therefore one part of a broader third-party risk management process. A strong provider should make risks easier to identify and control, not create dependencies that the institution cannot adequately oversee.

How OSFI B-10 and B-13 Apply to Technology Vendors

OSFI B-10 and B-13 address connected but distinct areas of risk. Understanding their scope helps institutions evaluate a provider without treating the two guidelines as interchangeable.

OSFI B-10 – Third-Party Risk Management

The 2023 version of B-10 uses the title Third-Party Risk Management Guideline. Its scope is broader than traditional outsourcing.

It covers third-party arrangements involving external organizations or individuals that provide services, perform business activities, or support an institution’s operations and strategy. Examples include cloud providers, managed service providers, technology companies, and other external dependencies.

The institution must assess each arrangement based on its risk and criticality. A provider supporting critical operations will generally require more rigorous assessment and oversight than one supporting a low-risk activity.

OSFI B-13 – Technology and Cyber Risk Management

B-13 focuses on the institution’s technology and cybersecurity risk management. It organizes its expectations into three domains:

• Governance and risk management: Clear accountability, defined responsibilities, and a structured approach to managing technology and cyber risks.
• Technology operations and resilience: Reliable technology services, controlled changes, asset management, and effective recovery processes.
• Cybersecurity: Measures to identify, protect against, detect, respond to, and recover from cyber threats.

These domains help institutions evaluate the technology risks introduced by external providers. For example, a vendor with privileged access to critical systems should be assessed for access controls, activity logging, incident response, and recovery arrangements.

The practical distinction is that B-10 guides the management of third-party relationships, while B-13 addresses the technology and cyber risks that those relationships can create. Institutions should consider both when selecting and overseeing technology partners. Neither guideline transfers the institution’s accountability to its vendor.

Key Criteria for Evaluating a Technology Partner Under OSFI B-10 and B-13

A technology partner’s capabilities should be supported by evidence. Marketing claims, policy documents, or general security assurances do not provide enough information to assess every risk associated with a service.

Use the following criteria to structure the evaluation. The depth of each assessment should reflect the institution’s risk profile, the service involved, and its importance to business operations.

Risk Assessment and Business Criticality

Start by defining the service and its role in the institution’s operations. This provides the context needed to evaluate the provider’s controls.

The assessment should establish:

• Which systems, business functions, and data the service supports.
• The potential consequences of a service disruption or provider failure.
• The institution’s ability to replace the provider or bring the service in-house.
• The complexity of the provider’s supply chain and subcontracting arrangements.
• The institution’s exposure to concentration risk from relying on a provider, geography, or shared technology platform.

These factors help establish the arrangement’s criticality and the level of due diligence required under B-10.

For example, a provider supporting a critical customer-facing platform may need stronger continuity arrangements, more frequent reviews, and greater contractual protections than a vendor supplying a non-critical internal tool.

The assessment should be documented before the relationship begins. It should also be revisited during renewal and when material changes affect the service or its risk profile.

Technology Risk Management and Security Controls

A provider’s security practices should align with the institution’s requirements for protecting systems, data, and business operations.

B-13 covers technology governance, operations, resilience, and cybersecurity. When a vendor manages part of the technology environment, the institution should understand the controls used within that service and how they connect to its own security framework.

Review evidence covering:

• Identity and access management: Role-based access, least privilege, multifactor authentication, and privileged account controls.
• Data protection: Encryption, secure data transfer, access restrictions, and appropriate logging.
• Vulnerability management: Regular assessments, timely patching, and documented remediation.
• Change management: Controlled, tested, and approved changes to production systems.
• Security monitoring: Log collection, threat detection, alert investigation, and escalation.
• Incident response: Defined responsibilities, notification procedures, containment, and recovery.

Independent assurance reports, such as relevant SOC 2 reports or ISO 27001 certification evidence, can support the review. However, an assurance report does not automatically establish that a vendor meets every requirement relevant to the institution. Check its scope, validity, exceptions, and coverage of the proposed service.

Technology risk management should also account for emerging tools. For example, institutions assessing vendors that use AI in risk management should consider data access, output validation, human oversight, and auditability. These checks help identify risks that may not be covered by conventional security reviews alone.

Data Handling, Location, and Subcontractors

A technology service may involve more parties than the primary vendor. Data can pass through external platforms, processing environments, and subcontractors, creating additional dependencies.

The institution should establish a clear view of how its information is handled throughout the service.

Key areas to document include:

• The types of data the provider stores, processes, or accesses.
• The locations where relevant data is stored and processed.
• The individuals and subcontractors with access to institutional systems or information.
• The safeguards used to protect data in storage and transit.
• The procedures for notifying the institution about material changes to subcontractors.
• The arrangements for returning or securely deleting data when the relationship ends.

Data location requires particular attention. OSFI B-10 does not establish a blanket rule requiring all data handled by every technology vendor to remain in Canada. However, applicable financial institution legislation requires certain records to be maintained in specified locations in Canada, subject to statutory exemptions and related access requirements.

Institutions should identify which records are covered and examine the legal, security, and operational implications of processing information outside Canada. The locations of a provider and its subcontractors may also affect access, oversight, and continuity.

A complete assessment should consider the entire service chain rather than relying only on the primary provider’s assurances.

Contractual Safeguards and Audit Rights

A provider’s commitments need to be reflected in the agreement. Otherwise, the institution may lack the information or rights needed to monitor the service and respond to problems.

OSFI B-10 expects third-party arrangements to establish clear rights and responsibilities through appropriate written agreements. For high-risk and critical arrangements, the guideline sets out more extensive contractual expectations.

Review the agreement for provisions covering:

• Service scope and accountability: Defined responsibilities, service levels, performance measures, and escalation paths.
• Security and incident reporting: Data protection requirements, incident notification, cooperation, and remediation.
• Information and audit rights: Access to relevant records, reporting, and appropriate rights for the institution and OSFI to evaluate the arrangement.
• Subcontracting: Requirements for notification, oversight, and control of material subcontractor changes.
• Continuity and recovery: The provider’s responsibilities during disruption and its commitment to test recovery arrangements.
• Termination and transition: Data retrieval, knowledge transfer, transition assistance, and conditions for ending the relationship.

Legal, technology, security, and risk teams should review the agreement according to its scope and risk. A standard vendor contract may not adequately address the institution’s particular needs.

Clear contractual safeguards establish the foundation for effective oversight, but they must be supported by evidence that the provider follows the agreed terms.

Business Continuity and Operational Resilience

A provider’s ability to maintain service during disruption is an important part of operational resilience. An institution also needs confidence that critical services can be restored within acceptable timeframes.

Assess the provider’s continuity and recovery capabilities in the context of the service it delivers.

Relevant evidence includes:

• Documented business continuity and disaster recovery plans.
• Backup and restoration procedures.
• Recovery time and recovery point objectives appropriate to the service.
• Results from recent recovery tests.
• Plans for prolonged outages, cyber incidents, and subcontractor failures.
• Corrective actions taken after unsuccessful tests or identified weaknesses.

A recovery plan on paper is not enough. Test results show whether the procedures work and whether the provider can meet the institution’s requirements.

The institution should also maintain its own operational resilience framework, including contingency arrangements for critical third-party services. This planning should account for the possibility that a provider may be unable to continue delivering the service.

Ongoing Monitoring and Accountability

Due diligence establishes a baseline, but a vendor’s risk profile can change. Security weaknesses, financial problems, subcontractor changes, and service disruptions may arise long after the contract is signed.

OSFI B-10 expects institutions to monitor third-party arrangements and reassess risk throughout the relationship. B-13 also emphasizes continued oversight of technology services, security controls, and recovery capabilities.

A monitoring process should define:

• The performance and risk information each provider must supply.
• How frequently that information will be reviewed.
• Which incidents or changes require immediate escalation.
• Who owns the review and approves corrective actions.
• How unresolved issues and exceptions will be reported to management.

Useful evidence includes service performance reports, incident records, unresolved vulnerabilities, audit findings, recovery test results, and changes to subcontracting arrangements.

The review process should lead to action. Record significant findings, assign responsibility for remediation, and track corrective measures through completion. This helps maintain visibility into operational risk and supports informed decisions about whether the relationship remains appropriate.

Red Flags to Watch for When Assessing Technology Vendors

A provider may appear capable during sales discussions but lack the evidence or operating practices needed for a high-risk financial services environment. The following warning signs deserve closer review.

• Claims of OSFI certification or guaranteed compliance: OSFI does not certify technology vendors. Such claims should be replaced with specific evidence of the provider’s capabilities and controls.
• Incomplete security evidence: The provider offers broad assurances but cannot supply relevant security documentation, test results, or remediation records.
• Limited subcontractor transparency: The provider cannot explain material subcontracting dependencies or demonstrate appropriate oversight.
• Unclear incident responsibilities: Notification timelines, escalation paths, and support during investigations are not adequately defined.
• Untested recovery capabilities: The provider cannot demonstrate effective backups, disaster recovery testing, or remediation of known weaknesses.
• Restricted information or audit rights: The arrangement prevents the institution from obtaining the evidence needed for oversight.
• Weak exit arrangements: There is no practical plan for retrieving data, transferring services, or maintaining critical operations if the relationship ends.

These warning signs do not all carry the same level of risk. Their significance depends on the service, the institution’s risk appetite, and the availability of effective safeguards.

However, material weaknesses should be documented and addressed before the institution accepts the associated risk. For critical services, an unresolved gap may require stronger controls, additional contractual protections, or a different provider.

How to Identify Gaps in Your Existing Technology Partnerships

New vendors are only part of the picture. Existing technology partnerships may have gaps because contracts have changed, services have expanded, or security and operational requirements have evolved.

A structured gap analysis helps institutions move from general concerns to specific, actionable findings.

Build a Complete Vendor Inventory

Create a central inventory of technology providers and other relevant third parties. Record their services, internal owners, systems, data access, subcontractors, and key dependencies.

Classify each arrangement by risk and criticality. This helps identify providers that support critical operations and may require more rigorous oversight.

An incomplete inventory can leave important dependencies outside the institution’s normal review process.

Map Arrangements Against B-10 and B-13 Expectations

Review each arrangement against the relevant requirements, internal policies, and control standards.

For B-10, examine due diligence, risk classification, contracts, subcontractors, monitoring, and exit planning. For B-13, assess the technology and cybersecurity controls affected by the service, including recovery and incident response.

Use documented evidence wherever possible. Contracts, security assessments, audit reports, access reviews, incident records, and disaster recovery test results can help establish whether controls are working as intended.

Also identify responsibilities that remain with the institution. A vendor’s security report cannot, by itself, demonstrate that the institution’s wider technology risk management framework is effective.

Prioritize Findings by Risk

Not all gaps require the same response. Prioritize them according to potential harm to critical operations, sensitive information, service availability, and regulatory obligations.

For example, missing recovery evidence for a critical service may require urgent attention. A documentation issue involving a lower-risk arrangement may be addressed through a different timeline.

Record each finding with its supporting evidence, business impact, responsible owner, and recommended action. Document risk acceptance through the institution’s established governance process.

Create a Remediation and Monitoring Plan

Turn the findings into specific, trackable actions. Depending on the issue, these may include updating contracts, strengthening access controls, obtaining missing assurance evidence, testing recovery capabilities, or improving subcontractor oversight.

Assign owners and target dates. Establish reporting mechanisms so management can track material gaps and confirm that corrective actions have been completed.

The review should also be repeated when significant changes occur, such as a new service, a major incident, a change in data location, or the introduction of a new subcontractor.

A gap analysis is not a compliance guarantee. It provides an evidence-based view of existing weaknesses and helps the institution prioritize the work required to address them.

How BuzzClan Helps Canadian Financial Institutions Stay OSFI-Ready

Meeting technology risk management expectations requires more than documented policies. Institutions also need the technical capabilities to assess their environments, strengthen controls, monitor systems, and address weaknesses.

BuzzClan provides cybersecurity, cloud consulting, managed IT, and infrastructure services that can support relevant technology risk management activities. The appropriate scope depends on the institution’s environment, control requirements, and existing processes.

• Cybersecurity services: BuzzClan’s cybersecurity capabilities can support security monitoring, threat detection, and the management of cyber risks.
• Cloud consulting: Cloud consulting services can support infrastructure assessment, cloud strategy, migration planning, and security-related work.
• Managed IT operations: Managed IT services cover infrastructure management, proactive monitoring, and service operations.
• IT infrastructure services: Infrastructure management can support the reliability, performance, and management of technology environments.

These capabilities can contribute to specific technology and security workstreams within a broader risk management program. Any engagement should have a defined scope, clear responsibilities, and agreed evidence of delivery.

The institution remains responsible for interpreting applicable OSFI expectations, assessing risks, accepting or rejecting residual risk, and maintaining its regulatory obligations. A technology partner can help support these responsibilities, but cannot replace them.

Conclusion

For Canadian financial institutions, choosing a technology partner is about more than technical capabilities or service delivery. The relationship also needs to support effective third-party risk management, technology resilience, cybersecurity, and ongoing oversight.

OSFI B-10 and B-13 make one thing clear: working with a third party does not transfer accountability. The right technology partner should provide the transparency, controls, evidence, and support your institution needs to understand and manage its risk.

Before entering a new technology partnership or renewing an existing one, take the time to identify where gaps exist and whether the arrangement can stand up to ongoing regulatory scrutiny.

Frequently Asked Questions