Risk Management

Introduction

In this episode, we will provide you with some advice regarding the typical issues we see with organisations trying to implement Risk Management with eramba.

Spreadsheets

Is completely possible (and very common) that if you have been using spreadsheets for Risk Management you would like to bye bye them and manage everything with eramba. Is very important to understand that a software or a spreadsheet reflects a methodology, while is very possible your methodology and eramba are almost the same, is also very possible that some things are different.

Typically we see differences in the following areas:

• Risk treatment in eramba is composed of four solutions (Internal Controls, Policies, Exceptions and Projects). Most spreadsheet-based Risk registers only use a column to describe the treatment and its status. This is almost always the big difference.
• Risk calculations are sometimes a little complicated, we would suggest you review this episode for more information on that matter and also review our documentation in regards to Risk calculations which offer configuration parameters.
• Complicated asset-based Risk practices, in particular when a spider of dependencies in between assets is used for some Risk input. We recommend you read this episode and also our Asset Management course for more details.

We recommend you spend some time with the documentation until you see what differences exist (if any) and only then start moving to a software solution (eramba or anything else). Is very common as well that spreadsheet-based Risk methodologies are outdated and moving to software is an opportunity to adjust that methodology. If you have doubts contact support@eramba.org or post your questions on our forum.

Subjectivity

eramba provides you with four different types of Risk calculations. These calculations provide a formula that tells you, with a number, how much of a problem a given risk is. All four calculations require you to provide some form of likelihood and impact for your risks (you can call them anything you want in eramba). This classification is fully configurable by you.

Is important to clarify the following regarding Risk management in eramba:

• eramba does not use quantitative methods for Risk. You can not tell eramba the asset that inputs a risk is worth 5m EUR and therefore the impact is very high. You can instead use classifications such as "High", "Low", "Medium", "Medium Rare" or whatever you define.
• eramba comes with simple arithmetics for their calculation options, addition and multiplication of two numbers (typically likelihood and impact, both qualitative). You can not define your math model.
• while you relate inputs (Assets, Third Parties, Business Units) to risks, these inputs do not affect the risk calculation at all. These inputs are used in eramba to provide context (clarifications) to the risk.

As you can see, eramba strives for simplicity and assumes Risk in the space of Cyber is subjective. We develop this subjective characteristic of Risk classifications in the coming paragraphs.

Likelihood:

• No one knows the likelihood of something happening with any degree of certainty. This is not the insurance industry where we know the likelihood of a frontal car accident in London's SW1 on a Thursday morning.
• Probabilities (and impacts) are stationary, the likelihood of a frontal impact in London's SW1 is higher in winter than in summer. The likelihood of your company being hacked is bigger when your company releases quarterly earnings or when it acquires another company. Is very hard to keep updated things in real time.
• Probabilities (and impacts) are contextual to each specific organisation and can not be compared. The likelihood of your company website being hacked versus Tesla's website being hacked is very different. Yet if you both create the risk "Website could be hacked" in eramba, you would most likely both classify the risk likelihood as High. Put differently, we can not compare if the risk score of a company is in the norm of the industry.

When focusing on "Impacts" on the business:

• Trying to put monetary value to things that do not have a market value is impossible. The balance sheet of a company requires many specialists (ask your Finance department) to adjust it multiple times per year (yes, things change prices all the time) times per year to have a somewhat fair resemblance of a market value.
• That value, in most international accounting standards, looks at tangible assets alone. If your website is hacked, what will be the monetary impact of that? No one knows, because there is no market value for that. No financial department would even attempt to calculate the "loss of opportunity" cost of such an event unless they are making an insurance claim with a lawyer. Even in that case is a wild guess.
• Pretending a GRC department can do the work stated above is unrealistic.
• Impact has the same issues as likelihood: stationary and contextual.

The point we are trying to make here is that complicating things will not produce more accurate outputs and therefore it should be avoided.

Liabilities

Depending on who you ask, Risk Scores are used to understand two things:

• How big of a problem is
• Which problem is worse (is derived from the first)

Since understanding the size of a problem is subjective (we are referring here to Cyber Security where at least the likelihood is known to be subjective) number (see question above) the second point is also subjective. If you have a Risk matrix of 3x3 or 5x5 or whatever, your Risks will tend to "accumulate" and people will ask:

• What is the difference between a score of 5 and 7?
• Why did you decide to mitigate Risks with a score > 6 and not those that are 5?
• What score has our competition?
• What is the norm in the industry?

Since we work with subjective data any question will be difficult (because when something is not factual is difficult to explain) to answer. eramba uses liabilities to highlight known issues (legal in particular) with something we call Risk Magnifiers (read the documentation) to elevate or dig Risks from the "pack". You will end up with something like this:

Risks without relevant liabilities (SOX, GDPR, etc) will follow the simple math (addition or multiplication of factors) and will therefore be packed all together. Those risks that can have serious legal consequences will be applied with a magnifier that will "elevate" them from the rest (green box).

We are not here implying that just because what we do is based on subjective data the entire process is out of value, but that this fact needs to be accepted, explained clearly to any stakeholder and utilised as a prioritization tool.

What Classification to Use?

If your organization is new to Risk (even if it is not) and you are looking at Cyber Security Risks we recommend using the following setup.

The reason why this works is that the criteria used for every classification are factual and very easy to answer and therefore they will be used systematically and produce factual outputs.

• Likelihood
  • Low: it never happened before and is unlikely to happen
  • Medium: it never happened before but it could easily happen anytime
  • High: it has happened before and it could happen again
• Impact:
  • Low: our customers and finance department won't even care about it
  • Medium: contractual issues are certain from customers and/or partners
  • High: criminal legal issues are certain

Keep it Realistic

When doing risk management in eramba you need to identify, create and maintain updated:

• BU’s and their process (HR, IT, Finance, etc.)
• Their assets, third parties, liabilities and process
• Their perceived risks (we call them problems)
• Their solutions (internal controls, policies, exceptions, etc)

There are rounded-up ratios between these elements you can set for your organisation:

• For every BU you will have 10 assets
• For every asset you will have 1.5 Risks
• For every Risk you will have 2.5 Solutions (Internal Controls, Policies, Projects, etc.)

When reviewing a Risk you will need to review Assets, Risks and all involved solutions. Setting a generic review effort in hours gives you the amount of "maintenance" effort per year.

Done properly, this is a monumental task because it requires many interviews with many different departments multiple times per year to keep your data reflecting the reality of your Risk program all the time.

We can do simple numbers to explain this pyramid effect but you will need a spreadsheet (download our calculator from here) as there are many dependencies:

By definition, if the pyramid is very wide at the top, it will grow, lineally wider, at the bottom. If you create many BUs you will have many more Assets many more Risks and many many more solutions.

You have a choice to make:

• Input a lot of data you won't be able to keep updated and therefore reflect a certain inaccurate picture
• Input less, but real data and reflect an incomplete but real picture. you will focus on the really important piece and leave undocumented the less important issues.

A single step in the right direction is worth more than a thousand in the wrong direction.