Executive Summary

Curious about how the Canadian regulators are tackling third-party software risks in the financial sector? Our latest article delves into the OSFI's guidelines for managing these risks to ensure operational resilience and robust incident management for regulated financial institutions and their critical suppliers. Learn how proactive third-party software risk management, monitoring, and reporting guidelines safeguard financial system resilience and integrity and align with other emerging standards across the globe.

Topics covered in this article:

• Overview of OSFI guidelines

• Importance of operational resilience in financial systems

• Requirements for:

  • Proactive third-party software risk management practices

  • Ongoing monitoring and incident reporting

  • Alignment with global standards

Equip yourself with the knowledge to strengthen your IT infrastructure and avoid regulatory scrutiny and penalties.

Canadian Office of the Superintendent of Financial Institutions (OSFI) "supervises federally regulated financial institutions and pension plans to contribute to public confidence in the financial system” and that mission extends to mitigating risks to Canada’s financial infrastructure and, more specifically, risks stemming from third party software and systems.

Taking a closer look at Canada’s approach to governing operational resilience offers a practical way to distinguish universal practices and the inevitable over-correction for nationalistic requirements and conventions.

How and when you invest in generalized architecture or highly localized patterns may well ultimately limit a financial services organization to work efficiently across international borders.

Canada’s OSFI is one of over 60 nations that already have – or are in the process of formalizing - specific recommendations to mitigate technical risks to their financial infrastructure. Whether as a member of BCBS or ESFS (see Table 2 below) or if they are going it alone, the fact that over 60 nations have all prioritized minimizing the risks of financial system outages demonstrates that it is foundational to the healthy functioning of our global economy – this is not bureaucracy gone wild - it’s the right thing to do.

Table 1: individual nations and the organizations they rely upon to ensure safety and transparency.

Larger, umbrella organizations have also emerged that represent nation cohorts designed to minimize conflict and maximize their influence on technology development.

Table 2: Two examples of regulatory cohorts with authority over their member companies.

The explosion of regulatory guidelines that both overlap and diverge brings its own set of unique challenges that may, if not properly managed, create more risk and expense than the threats they are intended to eliminate.

A closer investigation of OSFI’s guidelines along with others like DORA offer a roadmap to effective and efficient compliance.

The OSFI issue regulatory guidelines and advisories that are not laws in themselves but are regulatory expectations. These documents outline best practices, standards, and requirements that Federally Regulated Financial Institutions (FRFIs) are expected to follow to comply with existing laws and regulations.

Failing to effectively manage operational risk as a Federally Regulated Financial Institution (FRFI) in Canada can result in various penalties and regulatory actions that can include:

• Administrative Penalties

  • Fines

• Increased Supervisory Oversight

  • Enhanced Monitoring

  • Watch-Listing

• Regulatory Directives and Requirements

  • Corrective Action Plans

  • Supervisory Letters

  • Capital Add-Ons

• Reputational Damage:

  • Public Disclosure

• Operational Restrictions

Broad guidance on how institutions need to manage risks, report incidents, and ensure operational resilience and cybersecurity is spelled out in the following publications.

1. Operational Resilience and Operational Risk Management - Draft guideline (2023) (E21) Publication type: Guideline; October 31, 2023

2. Third-Party Risk Management Guideline (B10) Publication type: Guideline; April 30, 2023

3. Technology and Cyber Risk Management (B-13) Publication type: Guideline; July 31, 2022

4. Technology and Cyber Security Incident Reporting Publication type: Supervisory Advisories; July 31, 2022

Taken together, these documents align and consolidate all of the IT risks factors that must be managed and provide durable and generalizable framework that accounts for bad actors, software and system flaws, human error, and natural disasters.

In this context, the OSFI’s position on the importance of managing risks stemming from the bugs in third party software and systems is clear – both in terms of their materiality and as a risk class related to – but distinct from – classic security vulnerabilities.

Risk management guidance is organized around the construct of incidents, their detection, assessment, and, when appropriate, their reporting and mitigation.

FRFIs need to have processes to manage incidents in three forms.

Figure 1: OSFI Incident management takes three forms based upon where incidents occur in relation to the Federally Regulated Financial Institution (FRFI).

1. Locally Detect and Triage: An Internal FRFI Incident occurs within a FRFI’s operations (and/or supply chain). The FRFI is responsible for detection and triage to ensure effective and appropriate responses.

2. Externally Detected and Triaged: An external FRFI Incident occurs inside another FRFI (or its supply chain). In this scenario, the incident is detected and triaged by another FRFI. FRFIs are expected to monitor and respond appropriately to externally reported FRFI incidents to prevent replication or reoccurrence.

3. Anonymized and Aggregated Detection: A Third-Party Incident is detected by the third-party supplier. The instance is documented (reported) as a bug and published in the vendor’s proprietary bug reporting format. Vendor bug reporting formats are not aligned with OSFI standards. FRFIs must normalize and extend third-party bug reports into an OSFI incident format to then properly assess their potential impact.

The following excerpts from OSFI guidelines provide highlight specific requirements and guidance to manage and mitigate the third form of incident management, Third-Party Incident Management.

Section: Criteria for Reporting

A reportable incident is one that may have any one or more of the following characteristics:

• Impact to FRFI operations, infrastructure, data and/or systems, including but not limited to the confidentiality, integrity or availability of customer information.

• Disruptions to business systems and/or operations, including but not limited to utility or data centre outages or loss or degradation of connectivity.

• Operational impact to key/critical systems, infrastructure or data.

The text is plain; incidents are not restricted to security vulnerabilities or the actions of malicious users and those incidents can rise to the level of “reportable” if the lead to disruptions in service. There is no requirement for a bad actor to trigger the “reportable” responses.

2.4.2 Incident management and reporting

Principle 11: Both the FRFI and its third-party should have documented processes in place to effectively identify, investigate, escalate, track, and remediate incidents to maintain risk levels within the FRFI’s risk appetite.

This is inclusive of bugs inside third-party critical systems and apps.

2.4.2.3 Internal incident management process is established

The FRFI should also have clearly defined internal processes for effectively managing and escalating third-party incidents and for subsequently tracking remediation. The processes established should clearly define accountabilities at all levels of the FRFI and triggers for escalation within the FRFI.

This includes having processes to resolve incidents where bugs in critical systems must be isolated, patched, or removed.

OSFI guidelines emphasize proactive risk management, ongoing monitoring, and comprehensive incident management. OSFI’s guidance on Incident, Impact, and Process scope and requirements include tracking third-party software flaws that may trigger reportable incidents within FSFIs.