• Abdul Manaf

What is the quality of risks in your risk register?

Updated: Jun 30, 2019



Managing risks is a foundational discipline in any organization or domain. Risk management is equally important to mitigate personal risks such as health, accidents, or whatever that could go wrong resulting in an individual’s ability to meet their short and long-term goals. Information security is no different. Managing risks to information, information systems and processing facilities is foundational to information security. It doesn’t matter whether the threats are internal, external, inherent in operating environment, or in the business context.


Quality Risk Statement

Today, I want to discuss the quality of information security risks that you have in your risks register. I am sure, this applies to other disciplines equally, but being an information security professional, I would rather talk about my own domain. I am sure every organization has its own risk registers filled out with numerous small and large risks and it is time that seriously question the quality of those risks for they do not secure your organization any bit unless those risks are of good quality. One must ask – what is a good quality risk? A simple criteria could be to identify the following from the risk statement.

  • What could happen?

  • Why it could happen?

  • What could be lost?

If you have answered all three questions in a risk statement, the next level of assessment could be to see if the statement is SMART.


SMART Risks

A SMART risk looks like below:

  • Specific: The statements could only have interpreted in one way. It clearly identifies the people, processes and/or technologies involved.

  • Measurable: It is possible to state the likelihood and impact of risks quantitatively or qualitatively.

  • Attainable: It fits into the response strategies - accept, avoid, mitigate and transfer.

  • Realistic: Risk statement should not reflect one’s own fears of what could go wrong. Most often, that’s what you will find in a risk register. There should be a method in the madness. For example, suppose if the risk states that there is a 5% chance that there would be an earthquake in, say California, this year”, that should be based on some valid statistics.

  • Timely: Likelihood is defined as a function of time.

Vague or Clarity

One good example of a bad risk statement would be “information may be lost due to poor handling resulting in reputational damage”. This is just a statement of fear. A risk statement would say something like “a staff in the credit card billing department is could exfiltrate information by saving all customer details into a USB drive, which could result in a regulatory penalty of 500,000 USD”. The latter is much clearer. Most importantly, the second statement answers the question – what could be done to mitigate the risks. If this question is not being answered, the risks statement should be rewritten. You can’t mitigate a risk if you don’t know what should be fixed in the first place. A well written risks statement is an effective communication tool, and there is something for everyone in it. The risk monitoring team knows what to look out for, the engineering (for technical risks) team knows what to mitigate, and the business knows the importance of funding the mitigation given the impact that it would have on the business should the risk be mitigated.

High-level and low-level risks

Risk management need to take a view of both top to bottom (high-level) risks and bottom up (low-level) risks. While the high-level risks are aligned to business risks, the low-level risks are most often where the technical risks lie. Mitigating both kinds of risks are important. High-level risk mitigation might require a long-term strategy, policies and organizational change management to address those, while low level risks might only need short term technical or process changes. The high-level risks can be identified by the business owners by asking the question – “what keeps you awake at night?” While the low-level risks are identified from security assessments, penetration tests, design reviews, process reviews, incident reports etc.

Since you are a security professional, most often the business leaders would start addressing their concerns with information security. That’s not what we want here. We are looking for things that they are genuinely concerned with. Things like leakage of confidential information, an earthquake, failure rate in projects, large scale attrition, etc. Some of the above topics are clearly identified with security, while the others (such as attrition) clearly not. However, it might be interesting to note that depending on which security standards you refer, you will find a differing answer. I personally would like to stand with ISO/IEC 27005 on this. It identifies high level attrition as a security issue on the basis that high attrition clearly shows a systemic issue, either with the hiring process or something in the work environment, which ultimately results in unavailability of services.


Risk owner

One of the biggest issues with risks management is that it is significantly harder to identify a risk owner. This is due to the lack of understanding where the liability lies. Since this topic is widely misunderstood, I will have a separate article dedicated to this topic. For this discussion, let’s just say that the risk ownership lies with whoever owns the liability from the risk.


CISO, are you a risk taker?

Yes – wrong answer, No – Wrong again!

A big part of management’s job is to know the relevant risks and take those risks as appropriate, to generate value. It is not for the security professionals to tell the business which risks the business should take and which ones not to. The job of security professional is to provide a view of security risks and how to mitigate them so that the business could make better decisions.