Security working group meeting 5 – October 21, 2022

This discussion guide is provided to assist security working group members in preparing for the fifth meeting.

For questions or comments, please contact obbo@fin.gc.ca.

On this page:

• Discussion guide
• Outcomes

Discussion guide

Internal risk governance

As part of the common rules, the Final Report of the Advisory Committee on Open Banking (the Report) recommended that the Canadian system should address requirements with regards to data security as well as operational and systemic risk. As the Report noted, consumers need to trust and have confidence that the system is designed with safety and security considerations at every level.

To fulfill this requirement, the security working group meetings have taken a risk capability based approach. Discussions have focused on identifying the key components of risk programs as they relate to information, cyber and operational risk. In the course of those meetings, preliminary consideration was given to certain internal risk governance requirements related to these disciplines, including the appropriateness of the three lines of defence model as well as a dedicated risk professional within the executive leadership ranks.

However, an overarching view of how an organization approaches risk governance has yet to be analyzed. While the identification of principal risks open banking system participants may be exposed to is an essential step in managing such risks, the overall effectiveness is complemented by an internal risk governance program, meaning a program that outlines the accountabilities, leadership, organizational structure and frameworks for enterprise wide oversight of critical risks.

The purpose of this working group meeting is to focus on internal risk governance requirements to support proper risk management and oversight in order to effectively identify, measure, control, monitor and report on risks. Internal risk governance requirements in the context of financial services are not uncommon. For example, the Office of the Superintendent of Financial Institutions outlines such expectations in guidelines applicable to federally regulated financial institutions^{Footnote 1}. Similar provisions exist under open banking frameworks^{Footnote 2} as well.

As has often been the case throughout different working group topics, the concept of proportionality also remains a consideration. While the goal of the common rules is to create system wide requirements, the varying profiles of businesses, namely from the perspective of their complexity and size, among other factors, merits an approach which takes into account the inherent risk posed by such organizations. What's more, a uniform application of internal risk governance requirements could place onerous demands which may dissuade potential system entrants.

Discussion

1. What are the critical components of a system participant's overall security management framework? Consider this from a top down approach (for instance, board awareness, committee structures, documented policies / procedure documents, risk appetite statements etc.).
2. Is a dedicated security function necessary for the proper management of security risks? If so, what would be the key attributes of such a function?
3. What are the key requirements of a suitable controls assessment program?
4. What are the critical components of an incident response plan?
5. How important is staff awareness and risk training in a system participant's management of security risks?
6. In the spirit of proportionality, the accreditation working group has discussed different paths to access consumer-permissioned data, including tiers and an agency model where a potential system participants relies on the access of a fully accredited principal. In the event such a model was implemented, would internal risk governance requirements vary depending on the system access model? 
7. How will an organization evidence their adherence to security requirements (e.g. self-assessment vs assurance report)? Is the adherence to security requirements a static obligation or an ongoing one? If the latter, how often should it be refreshed?

Outcomes

Internal risk governance

Discussion 1

What are the critical components of a system participant’s overall security management framework? Consider this from a top down approach (for instance, board awareness, committee structures, documented policies/procedure documents, risk appetite statements etc.).

• There was general consensus that critical components include documented policies and procedures managed and enforced by oversight functions, specific controls, as well as senior level accountability with sufficient authority and independence to act on matters related to security.
• Additional examples provided by participants included having an incident management framework, ongoing testing of controls and regular third-party reviews of both the design and effectiveness of controls.

Discussion 2

Is a dedicated security function necessary for the proper management of security risks? If so, what would be the key attributes of such a function?

• There was general consensus that a dedicated security function is necessary for the proper management of security risks.
• Justifications included contributing to the risk culture within an organization, outlining accountability and establishing segregation of duties. The importance of specific expertise for assessing and communicating security issues throughout the organization was also mentioned.

Discussion 3

What are the requirements of a suitable controls assessment program?

• There was general consensus that third-party reviews of both the design and effectiveness of controls is a requirement of a suitable controls assessment program. 
• Additional examples provided by participants included regular reviews, ownership, testing and reporting of prescribed controls as well remediation requirements.

Discussion 4

What are the critical components of an incident response plan?

• There was general consensus that critical components included requirements with regards to event analysis following an incident, escalation of the incident to accountable senior leadership, remediation plans and a process for communicating lessons learned throughout the organization. 
• Additional examples provided by participants included a process to confirm that the incident has ended, scenario testing of the incident response plan both internally and with third parties, a help desk to address consumers’ concerns and a communication plan to inform the public. 

Discussion 5

How important is staff awareness and risk training in a system participant’s management of security risks?

• There was general consensus that staff awareness and risk training are critical components of a system participant’s management of security risks.
• The reasons provided included the considerable threat posed by phishing attempts, the evolving threat landscape as well as the number of breaches attributable to staff.
• Participants added that training could involve topics related to phishing, perimeter security and password protection. 

Discussion 6

In the spirit of proportionality, the accreditation working group has discussed different paths to access consumer-permissioned data, including tiers and an agency model where a potential system participants relies on the access of a fully accredited principal. In the event such a model was implemented, would governance requirements vary depending on the system access model?

• There was general consensus that governance requirements should not be relaxed for participants storing customer data within their environment. Outside of this scenario, examples of relaxed governance requirements included dispensing parties from reporting requirements, a dedicated security function and in-house training.
• In addition to storing data, other participants suggested that requirements should not be relaxed for participants handling or processing data.

Discussion 7

How will an organization evidence their adherence to security requirements (e.g., self-assessment vs assurance report)? Is the adherence to security requirements a static obligation or an ongoing one? If the latter, how often should it be refreshed?

• There was general consensus that organizations should demonstrate their adherence to security requirements with an independent assurance report that is refreshed at regular intervals or following the occurrence of certain events. Examples of this included changes to accreditation requirements or an industry-wide event.

Security working group attendees