In the cybersecurity risk world, we often encounter the issue of not speaking the same language as the business. This can result in a lack of support for the cybersecurity risk management program. When a cybersecurity risk is identified, the difficulty is to articulate it in a way that aligns with the organization’s language and goals.

Third-party risk lands in another gray area. Within organizations, many stakeholders — and often many processes — are involved in shaping the third-party risk management (TPRM) approach (including governance, process, and tooling). With all the work that goes into TPRM, risk reporting is often fraught with difficulty, so much so that even subject matter experts can struggle to analyze and identify risks and then report them clearly.

 If you work in third-party or cybersecurity risk, you are a risk professional. As such, it is your job to identify and analyze risk. But to maximize efficiency and success, it is essential to risk rate and track risks. You need to drive risk treatment decisions and the ultimate remediation of the risk(s). Conversely, any accepted risk must be well documented and set up for periodic review based on the risk level and established procedures.

The end goal of both third-party and cybersecurity risk practices is to manage risk and secure an organization’s assets. A well-formed program enables risk practitioners to be proactive in driving positive change.

Identifying and Assessing Risks

In both third-party and cybersecurity risk, the first duty is to find the risks. Discovery is a constant in these roles and is the base of the process. The immediate issue is typically abundance, which leads to the need to understand risk levels so risks can be prioritized.

Risk ratings are typically seen in a grid of likelihood against impact. Often, an organization will have a risk rating system applied to other business areas. This creates an excellent opportunity to link your process to established definitions. Sometimes, this comes with building a partnership with the Enterprise Risk function; at other times, it requires working with other stakeholders or departments to evaluate risk. When working within these bounds, it is imperative to customize definitions to encompass all risk management programs. Perhaps the likelihood metric used does not fully align with articulating cybersecurity or third-party risk; in these instances, a great solution is to build a list of additional definitions for what constitutes a certain score in likelihood. The same approach can be applied to definitions of impact. For instance, the business may be interested in the number of records impacted but may not have considered the number of servers affected or what vendors have access to your data lake.

The definitions are mainly qualitative and subject to interpretation, but the better it can encompass meaningful metrics the easier it will be to have consistent measurements. The results of the impact and likelihood ratings are factors in calculating a risk level. Again, it is important to understand the risk levels used elsewhere in the organization; whether it is low, medium, and high or another set of terms, you should align terminology whenever possible. If sales teams can equate a “high-risk” financial deal with having the same gravity or impact as a high-risk vendor or vulnerability, it will help you articulate the importance of the risk treatment decisions.

When faced with a multitude of risks, the inclination is to prioritize those with the highest risk score, which are those with the highest combinations of likelihood and impact. This is the correct path to take, but having a plan for handling other risks is crucial. Fortunately, there are many tools that can aid in tracking cybersecurity risks. It is easy to look at a list of low risks and assume they are unimportant because they are labeled as low. The problem with this mentality is that they are all still risks. If a risk remains untreated for a year that inherently affects the likelihood of a resulting issue. So, it is recommended that a time frame for risk treatment based on risk score is codified into policy and applied to all risks (this may be another area where defining the differences between financial, operational, third party, cybersecurity, and other risks is necessary). Once that time frame is breached, the risk has also become a policy exception, which should be documented by cybersecurity risk, resulting in an increased impact score due to a lack of compliance with organization policy.

Risk Treatments, Remediations, and Acceptance

An essential piece of proactive risk management is identifying the risk owner. This is the person accountable for the risk and, therefore, the one who is responsible for appropriately prioritizing risk treatment. It is recommended that the risk owner be a manager whenever possible so they can incorporate risk treatment into strategic planning. The risk professional should work with the risk owner to aid in decision-making and articulate the importance of meeting set timelines for the treatment.

The treatment plans should be well articulated and achievable. If a particular risk owner has multiple risks, monthly meetings with the risk manager may become appropriate. This will help ensure clean lines of communication and assist in keeping the risk treatment a priority.

Some risks can be accepted but will still need to be tracked and reviewed. We live in an ever-changing world of business and technology, so a risk that cannot be treated today may be eligible for remediation a year later. Management must be aware of and sign off on any risk acceptance.

Stakeholders need to understand that risk acceptance is not a “set it and forget it” process. It is a living and breathing process like anything else associated with risk.

Articulating and Reporting Risks

With the risks identified, assessed, and treatment plans defined, you are now left with a more organized inventory of risks. To aid in risk accountability, relevant reporting must be made to the correct stakeholders. Of course, the highest impact risks should be reported, but risks applicable to the CIO may not be as relevant to the CFO. Besides relevance, other factors should be considered, such as how long the risk has been present and the number of business lines, product offerings, or business processes affected.

Once the risks have been curated, they need to be reported to the proper teams and applicable management. Depending on the stakeholders, this can take the form of monthly, quarterly, or any other recurring meetings. There should be a central dashboard that can be accessed to view risks and their status, but having a meeting gives the opportunity to highlight certain areas and trends and ensures a higher level of accountability.

Conclusion

Both cybersecurity and third-party risks are part of the overarching and dynamic world of risk management. Neither process should be seen as a standalone process and should be integrated.

Integrated risk management processes can be complex and involve extensive investigation and analysis. As such, it is important to articulate this work and use it to drive positive change within the organization. By speaking the same language as the business, it becomes easier for risk professionals to demonstrate alignment with the business and gain support for risk treatment.