In this article, the focus will be on the Risk Treatment & Response phase which is the third phase in the Risk Assessment process. I will go through the phase, Risk Treatment & Response, and the elements within it.

If you are new to Risk Management, I recommend you read the article What is Risk Management. And if you are interested in the Risk Assessment process and want to learn more about the prior phases:

• The Risk Assessment Process & Identification Phase Explained
• The Risk Analysis Phase Explained

And if you want a detailed explanation and have a security risk modeled, I recommend you read this article:

• What is Risk? Modeled and Explained

This illustration is a summarized view of Risk Management and the Risk Assessment process.

The illustration is an example of the Risk Management discipline. It may vary between frameworks, standards, and how organizations implement it but in general, it contains more or less the pieces in the illustration.

The Risk assessment process consists of four phases, these are Identification, Analysis, Treatment & Response, Monitoring & Reporting.

RISK TREATMENT & RESPONSE PHASE

When the related activities to the Risk Identification and Risk Analysis phase have been conducted it is time to move into the Risk Treatment & Response phase. This phase has, as the name of the phase stipulates, to decide on treatment of the risk and response options. Now it is time to decide on those chess moves we have analyzed and strategized around in the opening game, i.e. previous phases.

In some frameworks and standards Treatment equals Response. I often use both terms and I will show why and for what purpose. There is no right or wrong here. Use both of the terms if that fits the purpose best in your organization’s Risk Management framework, discipline, and Risk Assessment process.

In the Risk Treatment & Response phase the following activities, but not limited to, are conducted:

• Treatment
• Prioritization
• Owner
• Plan
• Response Option(s)

Let’s go through each of them, as I at the same time share some knowledge and experience from the field.

PRIORITIZATION

The purpose of the prioritization is to rate the urgency of the risk. The easiest method is to use an existing prioritization taxonomy if one exists. For example, 1 -3 or P1 – P3 or similar. The benefit of using an already existing taxonomy for prioritization makes the understanding of the urgency and the term easier to relate to. I have seen this used here and there.

Some organizations do not use prioritization at all and others do. I like to use prioritization, as it gives a better overview of the risks when they are aggregated within a risk register. And I have seen methods for assigning prioritization based on automation, i.e. formulas, or with the help of manual assignment.

My recommendation is to use it due to that it will be helpful when the risk register and risks start to grow. There may be situations where the same resources are needed for several risks, but this is usually the case. Technical subject matter experts are pulled across the organization when things start to get into the red zone, i.e. high up in the right corner of the risk matrix/heatmap/model etcetera. But as said before, risks are dynamic. They change over time. Revisit the prioritization frequently. Re-prioritize risk if changes take place or if other more urgent risks are needed to be managed.

OWNER

Each risk in the register shall have an owner. The owner, also known as the risk owner, shall be a dedicated person. Risk ownership shall not be shared among people, roles, or teams. The owner shall be a person who has the authority and experience to select the appropriate risk treatment and response based on the analyses of the risk. The reason for this is that shared responsibility and accountability circumvent the ownership.

I strongly recommend always assigning a risk owner within the risk treatment. Do this as a mandatory task when Risk Treatment & Response phase is entered into the Risk Assessment process. Do it directly, there is no need to wait or “think about it”.

It is beneficial to have a chain of command and responsibility matrix in place that dictates who the risk owner shall be. Many frameworks and standards stipulate that this person should be a person in a senior management or leadership role. The reason for this is due to that these persons usually have the authority and responsibility for information systems, related budgets, assets, and so forth. These roles and persons usually also, and should have, the mandate to decide on necessary investments that may be needed to be made to ensure the risk is managed according to an acceptable level.

I recommend having a pragmatic mindset when it comes to the risk owner. It does not always need to be a formal manager or leader. The person, within a certain role, who has the expertise and knowledge of how to best apply adequate treatment and response options can be appointed as the owner. Pragmatism is key. Do not overcomplicate things. RACI models are good, but execution and progress are better. Execution will eat those models for breakfast, and dinner, and achieve better results. And if there is a need to make investments, that require approval from a manager, these forms of the decision shall follow the organization’s decision-making process.

TREATMENT

Risk treatment is the activity, within the Risk Assessment process phase Risk Treatment & Response, where adequate measures are selected to modify the risk. The treatment of risk will vary dependent on the characteristics of the risk. And the risk treatment will be categorized into a response option. This is though how I look at it. And this is why I like to use both terms, i.e. treatment and response options.

Each risk shall have an adequate treatment plan that describes how it shall be treated. When the plan is formulated, be as specific as possible. Describe how the plan will be executed. What will be done? Why certain treatment options are needed. Keep it simple but include relevant details.

The plan might result in a larger project or activity that needs to be launched and sanctioned. In this case, it is ok, according to my reasoning, to describe this as a part of the treatment plan. Complex risks will usually involve stakeholders from several teams in the organization and need more resources to be invested. There might be a need to involve stakeholders from several IT, security, and business teams. Describe why these stakeholders are needed and who they are, i.e. for example the roles found in the organization structure.

The goal is to, with the help of the participants and the team involved in the risk assessment, construct a plan to treat the risk.

During the design of the Treatment & Response phase Key Risk Indicators, KRIs shall be selected. KRIs are metrics that provide relevant insight for predicting or indicating the probability of a risk getting actualized.

When I say that they “shall be selected”, this is what the theories, standards, and frameworks mainly dictate. In reality, I have seen that the selection of KRI may be something that takes place in the last phase of the risk assessment process, Monitoring & Reporting.

Personally, I think it is better to do the selection of KRIs during the Treatment & Response phase as I see the last phase as a more purse “operational phase” related to risk management.

But as I have said before, be pragmatic. If the KRI selection takes place in this or that phase is a smaller issue compared to if the activity is not conducted at all. KRIs as such is a topic of its own, so I will not go in so much deeper here. But I will write more about them in the next article, the last phase of the Risk Assessment process, Monitoring & Reporting phase.

KRIs = Keep it simple and do not overcomplicate stuff too much. Choose indicators based on metrics that are relevant and adequate.

Start asking:

“Why” are we monitoring this risk?

and

“How” shall we monitor this risk?

It might turn out that there is no need for defining a KRI for every risk. Certain risks cannot be monitored effectively, or the cost might be too high to monitor them. Pragmatism is key. I have said it before, there is no need to try to punch that little red ball into that green squared hole.

One way to do it could be to develop KRIs for those risks that fall outside of the risk appetite and in the top right corner of the risk matrix. But as said, be pragmatic.

Response OPTION(S)

Each risk will be treated according to a certain option. An option is a term for how the risk will be treated. The goal of assigning an option is, in combination with the plan, to identify the most favorable option for how the risk shall be treated and managed according to an acceptable level.

The most common options, that are used when risk is responded to are:

• Avoid
• Accept
• Transfer
• Mitigate

Descriptions to each option are given below:

AVOID

Avoiding risk means that the approach taken is to avoid those activities that cause the risk. For example, let’s say that an organization has decided to shift an information system to the cloud. The results from the Risk Analysis are showing that the risk(s) involved are not at an acceptable level for the organization. For this reason, the activity has been decided to be stopped. In this case, the risk(s) option will fall into the “avoid” category as the information system will not be moved to the cloud. The decision has been made, by the organization, to avoid the risk. Risk avoidance, the option “avoid”, is usually the last option of the resort if other options are not applicable.

ACCEPT

Acceptance of risk means that the level of the risk level is accepted. This option is chosen if the risk falls into and is within an acceptable level. In other textbooks, risk acceptance will also be correlated with the term risk appetite. I will describe this term in a separate article.

Risk acceptance will also be the option that will be played out if there might be no practical ways to reduce the risk. This is, from an experience perspective, something that is often seen when investments are made in cloud services. An organization will not have the possibility to, for example, but not limited to, control how the supplier’s internal security controls are managed.

I have several times seen this scenario play out when conducting risk assessments of cloud services and suppliers. The risk analysis has resulted in an identification that the service and supplier lack adequate security controls. This can, for example, mean that the cloud service and supplier do not have an acceptable security posture in relation to the customer’s organization. The cloud service and supplier lack certain security controls required by the customer’s organizations.

During the contract negotiation, and prior to when the ink is put on the paper, the customer and the supplier have come to an understanding that there is a gap. The lack of certain security controls does not fulfill all the security requirements stipulated by the customer’s organization. The supplier does not have the possibility to mitigate the identified gap and does not have a plan to do so, due to that it is not practically or technically possible.

In this case, the customer has a decision to make a risk-aware and informed decision. The customer can still decide to invest in the cloud service provided by the cloud supplier, meaning that they will need to accept the risk(s) identified. The customer will need to live with the risk(s). These forms of risk are also known as residual risk. Those risks that reside after treatment and responses have been investigated and taken.

I strongly recommend assigning each risk an option (Avoid, Accept, Mitigate, Transfer). This will help to understand where and in which business processes, services, assets, risk types, and scenarios each option is taken. It is very useful to understand how much and how often the acceptance option is applied. This might also lead to contemplations, such as:

• Are we choosing the correct suppliers and partners?
• What is our acceptable risk level in our organization?
• Do we understand and have insight into where and in which business processes we accept the risk?
• Do we have unidentified risks accepted?
• How can we improve our overall process to work with risk acceptance?
• How can we improve our overall risk awareness?

MITIGATE

Mitigation of risk means that treatments are conducted to reduce the likelihood and impact of the risk by designing and implementing adequate security controls. The objective of the “mitigation” option is to reduce the risk to an acceptable level. The necessary treatments and plans are put into play to ensure that risk is kept within an acceptable level.

If we stick to the example of the cloud service, an additional security control applied in the customer’s organization could for example be to incorporate and periodic security assessment of the cloud supplier. This would help the customer’s organization to ensure and monitor if additional risks, besides those already accepted, may appear in the future. Risk is dynamic and changes over time. I strongly recommend conducting continuous monitoring of the third-party suppliers that are a part of the organization’s supply chain with the help of a systematic and stringent risk assessment process.

TRANSFER

To transfer a risk means that the risk is shared or transferred to another entity via for example:

• Insurance
• Coverage
• Contracts
• Agreements
• Or by other means

Risk transfer, the option “transfer”, is something that is very useful for risks that have a high impact on the organization but a low likelihood. A typical situation where risk transfer is a natural option of choice is to have insurance for natural disasters and environmental threats.

Another situation and scenario where the transfer option comes in are to have insurance against cyber attacks and the potential impact they may cause on an organization. As with all insurances, there are “ifs” and “buts”. The insurance will not cover everything.

Insurance against cyber-attacks that wipes out an organization will have limitations. And so do all forms of insurance. I am not saying they are a less good option or something that should be neglected. Cyber insurances have its place. But before this form of insurance is bought, make sure to understand what it covers and what it does not cover. Be sure to understand the limitations and the obligations, responsibilities, and accountability aspects that the insurance stipulates.

Take help from an expert in the field who helps you to translate the contract and to describe it for you so that there are no question marks or own made beliefs, assumptions, or subjective thoughts around the insurance contract. Ask all the questions and ask them again.

Insurance companies are not there to steal your money or to fight against you, they are there to help you. And they will answer the questions you ask. And if you do not find one insurance company fitting into your organization, seek up another one. Due diligence, due diligence, due diligence. The due diligence exercise is something that the organization is accountable for. Accountability for security can never be outsourced or transferred. Accountability for security always resides within the organization.

RECOMMENDATIONS

Prioritize each risk and form a plan for each risk that describes how it shall be treated.

For each risk assigned to an owner, the owner shall be a person with the authority to decide on adequate treatment and response options.

If the risk is accepted, make sure to understand the implication of what the acceptance means. Is the acceptance of the risk within the acceptable level of risk within the organization?

If the risk is transferred, make sure to do the due diligence before the ink is put on the paper. Reach out to experts who understand the jurisdictional aspects of the contracts, agreements, and so forth.

Henrik Parkkinen