Regulatory rigour: Navigating the technology and cyber risk landscape Regulatory rigour: Navigating the technology and cyber risk landscape Regulatory rigour: Navigating the technology and cyber risk landscape

A key element of governance for all federally regulated financial institutions (FRFIs) is managing technology and cyber risk. To help FRFIs develop greater resilience against operational disruption, financial loss and reputational loss, Canada's Office of the Superintendent of Financial Institutions (OSFI) issued Draft Guideline B-13. FRFIs that handle transactions in Canada and abroad will need to remain compliant with the outcomes stated in regulation B-13 and demonstrate to the regulator the actions they're taking to do so.

Read our new article on managing technology and cyber risk and how FRFIs can achieve outcomes laid out in OSFI B-13.

As FRFIs work proactively to get ahead of the curve, they will need to assess the gaps that exist between their current operations and the new regulatory demands posed by B-13. Here are some key points to consider regarding the five technology and cyber risk management domains presented in the new regulatory guidelines.

Risk management is a fundamental part of governance. It entails looking at critical assets, the threat vectors that can affect them, and then assessing how best to protect them through the implementation of controls across people, process, and technology. Once the risks associated with critical assets or digital crown jewels are accounted for, FRFIs must also assess and report any residual risk that remains after risk controls have been applied to those assets.

One of the most challenging aspects in this area is creating cyber risk appetite statements, which in turn require institutions to establish the metrics and thresholds that trigger certain responses or actions, such as course correction or escalation. However, determining what is within an organization's appetite can be tricky, especially when reporting to executives and boards. This requires FRFIs to have a clear definition for their risk appetite and how to measure it. One of the most effective ways to do this is via qualitative risk appetite statements with supporting metrics. They must establish limits, thresholds, tolerance levels and put a reporting structure in place.

FRFIs must also be able to demonstrate what their cyber risk management framework is based on: an industry framework such as NIST 800-53 or ISO 27005, for example, as well as the organization's enterprise risk management framework. Changes made must be traceable, and FRFIs must both record and be able to demonstrate any actions taken. This means having documentation, not just for the processes already in place, but also for additional processes that might not be as mature right now or are not yet in use.

As FRFIs assess their technology solutions, and how they work together, they must also examine the controls that exist between them and ensure that access is segregated appropriately. FRFIs have been using technology for decades now with high availability of assets and systems being of importance. However, this has led to many legacy applications being housed on servers that are no longer supported and cannot be patched. The migration of applications to the cloud or to an alternate server is difficult because they must be available 24/7.

In addition to knowing what technology assets exist and what they contain, FRFIs must also know the risk ownership:

• Who owns the risks associated with the data?
• Who owns the risks associated with the application?
• Who owns the risks associated with the asset?
• Who owns the servers, the desktops, even the printers?
  

Any assessment of legacy devices should also include processes to evolve and put compensating controls around them if baseline controls can not be implemented.

Another critical element of technology operations for FRFIs to consider is the secure system development life cycle (SSDLC). Usually employed with the goal of producing the highest quality systems and software at the lowest cost and in the shortest time, the SSDLC should have robust security requirements and should establish practices for the integration of development, security and technology operations, so that new software can be deployed without compromising application security. FRFIs should ensure that security risk assessments are conducted for any acquired systems and software, and they should define and implement coding standards in order to provide for secure and stable code.

It's also important for FRFIs to implement processes relating to both change and release management and patch management. These processes should include protocols for testing all changes made to the technology, and for ensuring that patches are applied across the FRFI's technology so as to address any vulnerabilities and flaws in a timely fashion.

A central part of defending against cyber incidents is identifying threats and risks, and FRFIs usually have an internal or external security operations centre (SOC) that handles these tasks. FRFIs must be able to demonstrate the actions they have taken in response to an incident and that they have established adequate controls. Following an incident, it's essential to perform root cause analysis. This feeds back into the FRFI's risk management framework (specifically the assessment phase), so that managing technology and cyber risk becomes a cyclical process: lay out the strategy, monitor, manage, and respond to risks, then adjust the strategy and the risks based on that response.

Think about all the controls FRFIs have in place to safeguard technology and protect against cyber risk. Can they demonstrate that all their third-party providers (TPPs) have the same controls? What about all their third parties? An effective due diligence program can help ensure that all TPPs have their own risk management frameworks that match the FRFI's security posture.

It's also important to assess the FRFI's mitigating or compensating controls to ensure that they are able to respond if a third party has a failure. TPPs should be able to comply with the FRFI's standards, demonstrate what they're doing, and prove that it meets or exceeds those standards. An easy way to do this is to ask TPPs to demonstrate compliance with national and international standards, such as asking them to demonstrate that they are SOC 2 compliant, which serves to de-risk the relationship between the FRFI and TPP in certain respects. The FRFI can then focus on the other areas where the TPP is not able to attest. The FRFI might also be partnering with a smaller organization that doesn't yet have the maturity to meet the FRFI's standards. In this situation, a different strategy may be needed, such as asking them to be compliant with the FRFI's own control standards.

A particular area of concern is cloud computing. Cloud isn't new, but in many instances, FRFIs have been reluctant to adopt it because of the inherent risks in not using on-premises data storage. When implementing cloud storage, FRFIs must look beyond the physical security of the cloud environment and ensure that cloud platforms have the right security standards in place:

• What is the data?
• Does the data need to be protected?
• Who has access to the data?
• Is data encrypted in emails?
• What happens to the data when it arrives at a recipient's laptop?
• How is data protected once it's stored on another organization's servers or leaves the FRFI's environment?

At the end of the day, FRFIs are held accountable if a breach happens, and it is their reputation and risk to manage. And because many financial services organizations still rely on external parties to detect or respond to breaches, having a plan in place to manage risks associated with TPPs is one of the biggest risks for FRFIs to consider.

Risk also extends beyond the realm of cyber and the regulatory scope of B-13. As the number of customers guided by environmental, social and governance (ESG) principles when making decisions grows, it's important that FRFIs assess the ethical and environmental practices of their TPPs. Doing so can help them avoid costly reputational risk.

Following an incident, organizations must be able to continue essential operations. Along with incident response plans and playbooks, it's essential that FRFIs have a SOC function that can monitor and respond in real time, 24/7, or can even stop an attack before it happens.

Incident response closely links to business continuity and disaster recovery. This extends well beyond cyber security: consider the impact of recent events in Canada, such as fires, floods, and even the COVID-19 pandemic. Having a realistic incident response and disaster recovery scenario in place is crucial, and it should include tests at multiple levels, including the operational/technical level, the leadership level, and the executive level.

Whilst not part of the B-13 requirements, OSFI recently updated their requirements for reporting of cyber incidents within 24 hours. This is a challenging timeline, but it is important to note that this is 24 hours from the time that the FRFI learns about the incident or potential incident occurring. Effective security monitoring, incident response, a notification process (with roles and responsibilities detailed) and also an open communication channel with OSFI will enable this requirement to be met.

Through an effective risk management framework, has the FRFI identified the critical assets and risks specific to the organization?

Does the FRFI know what data is in the cloud and how it is being secured?

Has the FRFI updated their cyber risk appetite statements with associated metrics and thresholds?

Has the FRFI completed multiple realistic cyber incident simulations at different levels within the organization?

Does the FRFI regularly complete a self-assessment to see how effective the cyber security function is? OSFI provides a self-assessment tool and there is an expectation that assessments are regularly conducted.

As FRFIs look to manage their technology and cyber risks and meet all regulatory requirements, including those outlined in B-13, KPMG can help. Contact our team to learn more.