In this article, the focus will be on the Monitoring & Reporting phase in the Risk Assessment process. I will go through the phase, Monitoring & Reporting, and the elements within it.

If you are new to Risk Management, I recommend you read the article What is Risk Management. If you are interested in the other phases of the Risk Assessment process, you can read more about them here:

• The Risk Assessment Process & Identification Phase Explained
• The Risk Analysis Phase Explained
• The Risk Treatment & Response Phase 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, and Monitoring & Reporting.

RISK MONITORING & REPORTING PHASE

When a risk has been Identified, Analyzed, and Treated the risk has been recorded in the risk register and passed through the three initial phases. Now the risk is entering the Risk Monitoring & Reporting phase.

In the Risk Monitoring & Reporting phase the following, but not limited to, activities are conducted:

• Information
• Status
• Follow-up
• Reporting

When a risk has entered the Risk Monitoring & Reporting phase the purpose is to keep an eye on the risk and track changes to the risk level. In this phase, the risk will be assigned “how” the risk is going to be monitored and the risk will then be monitored and reported accordingly.

As risk exists in a specific context, and not in a vacuum or just only as a row in the risk register, the monitoring of the risk will vary. But there are some general principles and methods that can and are recommended to be used.

Risk needs to be monitored with effectiveness, accuracy, and with adequacy. I think that it is wise to be pragmatic in this phase. Apply practical measures for monitoring the risks. In some instances, there will be a technological solution that will help out. In other cases, there will need to be manual processes in place.

I recommend always striving for automating risk monitoring as much as possible. But this is not always applicable though. Changes to regulations for example may be, but do not need to be, something that is more of a manual process of monitoring. There are tools and things that can help out. Still, there will need to be a manual review of the changes and contemplation of how these impact the organization’s compliance posture and requirements.

Risks that have strong dependencies to, for example but are not limited to, threat intelligence can be automated to some extent. But threat intelligence needs to be transformed into practical, relevant, and actionable items. A chunk of random threat intel will not provide much help. It needs to be actionable. Something of relevance for the organization. The subject of threat intelligence will have its place in a separate article, I will for this reason, and due to the importance of the subject leave you with a cliffhanger…once again.

If you are curious about the relationship between threats, vulnerabilities, and what a security risk is take a look at this article What is risk? Modeled & explained.

INFORMATION

For each risk, there needs to be information given on how the risk is going to be monitored. Stipulate in the risk register how the risk and threshold, if risk thresholds have been applied, and how these will be monitored.

As risks are dynamic and change over time, the changes may imply that a risk’s likelihood, impact, scenario, prioritization, rating, and so forth may change as well. Risks do not exist in a vacuum. They exist in a context. If changes take place in relevance to the context, that has dependencies to for example the elements I mentioned, an organization needs to understand what these changes mean. What are the implications of the changes to risk for the organization? Simple as that. Without monitoring risk, it becomes impossible to take adequate action. Monitoring is key.

All security risks are not the same in nature or character. Security spans through Humans, Processes, and Technologies. This means that one way of monitoring every security risk is not a likely and possible solution. Data and information, from the monitoring, I recommend you to centralize. Store and visualize it in one place, from one console or user interface.

To accomplish a more uniform methodology to monitor risk can be accomplished with the help of so-called KRIs, Key risk indicators. KRIs are used to flag when deviations, exceptions, or divergence takes place in relation to the risk. The signal from KRIs, that has been configured for the risk(s), will provide the organization with an opportunity to respond to the risk before damage is actualized. KRIs are decided on (in general and shall be designed) in the previous stage, Treatment and Response, in relevance to the applied/decided security controls.

Example of KRIs:

• Mean time to detect (MTTD) – the average length of time it takes to discover incidents in their environment.
• Mean time to respond/remediate (MTTR) – the amount of time it takes to respond and remediate an identified threat or failure.
• Mean time between failure (MTBF) – the average time between failures of a system used to measure reliability.

KRIs help to form an objective measure of risk and the deviations from what is determined and decided as acceptable. It also provides the possibility to measure, track, and monitor risk over periods of time. And the tracking of the changes to the configured KRIs provides proactive signals that can be used to take actions before the sh*t hits the fan.

But keep in mind. KRIs are indicators. They indicate that something is approaching or going in a certain direction. Actions are still needed though. Here and there automatic measures and controls might be possible to be predefined and implemented but this is not always the case. All security risks cannot be automatically remediated or handled with autonomous measures. And this is not either the case that is always wanted.

For example, a KRI for an organization’s most critical system handling sensitive information might signal that something is approaching. In this case, and almost certainly, cautiousness is needed. It might cost more or generate a very high negative impact if automated actions were taken toward this signal. Automation is king, and you should strive for it but as I said before. Be pragmatic. Use it where it is suitable and makes sense.

Good KRIs are specific and possible to measure. They are relevant for the organization and the context for the risk. And they shall be provided in time. A KRI that is stalling and not reported in a timely manner provides less value. They have a place though, but they are more, according to how I see them, reporting-oriented. Keep in mind, real-time monitoring is great but not always achievable. And it usually comes with a cost as well, both monetary and in terms of human resources. Most of us love real-time monitoring of risks. It is cool and it is something but it is not always possible to be realized…or even needed. I recommend you to not make it into a cool thing. Use it where it makes sense and provides value to your organization.

My recommendation for the usage of KRIs is to keep it simple, to begin with. Sounds like a cliche and yes, it is to some extent but it is true. If the KRIs just creates more noise and do not provide any real value to track the risk, see if there are better ways to achieve the desired goal. Are there some simple metrics or other forms of signals that provide more value-adding monitoring of risk?

Apply monitoring of risk with a pragmatic approach. Do what fits the purpose and achieves the desired goal. You should use a method that tracks the changes which are relevant to the risk and your organization. There is so much more to say about this subject, it is an interesting topic. This is an area that I believe will mature more and more and that will become very interesting in the future if coupled together with the power of AI, quantum computing, and machine learning. Could the future be something like this:

“The KRIs are built and designed automatically based on collected organizational specific data coupled with internal and external cyber threat intelligence.

Real time prediction of future risk events is created that is a product of strong risk scenarios that is measures and reported timely and with high accuracy.”

Time will tell. I have not yet seen something like this, and I do not own a time machine that can tell me if this is something. If this is a thing. But as technology evolves, we are approaching in this direction…or in some sort at least and this is thanks to all those cool technological superpowers. I think the future of Risk Management can be something really powerful. Something really cool.

And there are already models out there today that can be used to quantify cyber security risks, the methods are also referred to as Cyber Risk Quantification (CRQ). The most known framework for CRQ is named FAIR, Factor Analysis of Information Risk. And according to my own beliefs, CRQ (which is a quantitative framework) do not eliminate the need or usage of a qualitative risk management framework (as the one exemplified in this article) or the other way around. They can coexist. <Cliffhanger>.

STATUS

As the activity says, all risks that exist in the risk register need some sort of status. Ensure that the risk status is recorded and standardized. This can, for example, be accomplished with the help of regular risk review intervals. The interval can be but does not need to be based on the rating and prioritization of the risk. The interval provides the time frame for when the risk is going to be revisited. High risks for example are often reviewed and reported on a higher frequency to the stakeholders.

A simple way to report status can be done by categorizing the risk according to the Risk Assessment phases, i.e. Risk Identification, Analysis, Treatment & Reporting, Monitoring & Reporting. As mentioned, several times, risk changes. And if for example, new information becomes available that requires that earlier phases of the Risk Assessment process are revisited the status of the risk may change as well. The risk may need to fall back to an earlier phase in the process and related activities (to that specific phase) may need to be conducted once again. The Risk Assessment process is not a linear process and should not be treated as such. Some organizations do though but according to my experience, this is not the most optimal way of doing things in this process, i.e. Risk Assessment.

Tracking and recording the status of the risk also provides insight into where the risks exist. Is there a large portion of risks in the Identification phase? Or are the larger portions in the Monitoring & Reporting phase?

Status is usually an element many organizations use, to better understand how the risks are spread in the process, i.e. Risk Assessment. I recommend using status as an element and activity for risk. It is a small effort and gives good, valuable, and understandable information. I recommend you contemplate if this would be something that could improve your organization’s Risk Assessment process.

FOLLOW-UP

Risks need to be followed up, on a periodic interval and systematically. This also better supports that positive progress is kept. Follow-up is crucial! Do the follow-up. Put in a method for how the risks are followed up. Who will follow up on the risk or will the Risk Owner communicate to the stakeholders about the progress?

In my opinion, the follow-up should be correlated and with relevance to the rating, prioritization, scoring, and KRIs of the risk. Risks that are high up on the heatmap, that will cause those large unwanted negative impacts on the business organization shall be followed up on a more frequent basis.

From my personal experience, if risks are not followed up and the owner of the risk is not kept accountable laziness has a tendency to kick in. Or other things may arise that are higher up on the Risk Owner’s agenda. The follow-up will also serve as a tool to, if needed, assign a new Risk Owner.

I would though not try to throw around risks between persons if not absolutely needed as this is not something that in general provide added value. But there are natural and needful situations where this is the only way to ensure risks are managed according to agreed treatment and response options. And of this reason, the term Risk Owner is something that also needs to be clarified in the organization. What does it mean to be a Risk Owner? Who is the Risk Owner? What mandates and authority does the Risk Owner have?

According to my beliefs, the Risk Owner should have the authority to decide on relevant treatment and response options for the risk. The person owning a risk, i.e. Risk Owner, should have the mandate to take and make the necessary decision to adequately treat and respond to the risk.

You or I, if we would be acting as a Risk Owner, should have the direct mandate or be delegated the mandate to make the necessary decision. Otherwise, or at least as I see it, the “ownership” is not provided if mandate and authority are not given or delegated to me as a Risk Owner.

I have seen some organizations delegate the mandate and others do it in other ways. They use a central decision forum for treatment and response. I can see the need for it but it also reduces the “ownership” attribute and efficiency. Decisions will most likely take longer time as those need to be made within a certain forum. But if this is the way in which things need to be done in your organization, go for it. Only you and your organization know what is best for you. The textbook, standard, framework, or me saying this or that does not have the answer. There may be requirements (internal or external) that demand certain forms of decision bodies and roles to take part in the decision-making process. Do those things that provide value for your organization and what stands in relation to your requirements.

REPORTING

The reporting of the risk and the risk register, which holds all the risks, are two of the activities that I find crucial. Reporting of each risk shall be conducted by the Risk Owner and stored for each risk in the risk register. The risk register holds the aggregated view of risk for the organization. The aggregated view, i.e. the risk register, will also provide a holistic view of the organization’s risk profile. For example:

• Are we operating and managing risk within our desired risk levels, capacity, appetite, and tolerance?
• Where in our organization do we have most of our risks?
• What assets are mainly related to our highest risks?

The reporting structure and how it is conducted will vary and depend on how the Risk Management Framework, Risk Assessment process, and organization are structured. If all risks are managed with the help of ERM (Enterprise risk management) that includes security risks (Cyber security, information security, and IT security) this is great. But this is not always the case.

If an organization has come this far, to use an ERM for all risks in their organization, in their risk management journey that is really something. Some organizations are here, and they are on the higher scale of the Risk Management maturity levels. The ERM will have and should have, clear reporting structures and principles for how risk shall be managed in the organization according to defined guidelines, processes, and principles.

Some organizations do not even know what ERM is or the difference between Risk Management, Risk Assessment, and Risk Analysis. In these cases, and in these organizations, it is key to start simple and start small. A good way to start out could be to ensure risk reporting is conducted within the security team(s) and to other relevant teams in the organization where Risk Owners reside.

As maturity grows, include more and more stakeholders. Include business leaders and managers from the IT and business organization. It can be overwhelming for persons who do not understand security risks to be faced with a bunch of “scary things”.

Risks can be seen as something scary and awaken paranoia. But the strive for you and your organization should be to create a risk-aware culture. And reporting of risk normalizes the concepts around risk. Use the reporting as a form to educate, engage and train the stakeholders on what risk is. Not to scare them, but to encourage them. To be more risk intelligent and risk-aware. The Risk Management discipline is there to help the organization manage risk and become more successful, not the opposite.

RECOMMENDATIONS

Be pragmatic when KRIs are developed and keep things simple. Automate as much as possible but keep in mind that everything cannot be automated.

Track status. This will help you to better understand the overall performance of the Risk Management discipline and Risk Assessment process.

Risk owner. The role should be defined and formalized. Make sure to educate the Risk Owners on what their responsibilities, mandates, and authorities are. Encourage and empower them to take ownership.

Follow-up is key. Be structured, conduct it periodically, and with the help of predefined methods and procedures.

Establish a reporting structure that is relevant to your organization. Use the reporting as an opportunity to educate and engage with your stakeholders, Risk Owner, and business.

Henrik Parkkinen