Risk Management

Introduction

eramba requires you to identify solutions (treatment options shown inside a green square) to the Risks you have identified, these are typically a mix of Internal Controls, Policies, Exceptions and Projects. In this episode, we describe at least one (of many) methods that will help you identify them.

Is impossible to understand this episode without having completed the Policies, Internal Controls, Projects and Exceptions courses. Do not attempt reading this episode without first having completed the other courses.

Treatment Options

When creating a Risk you will be required to describe the Treatment you would like to apply, your options are to Accept, Mitigate, Avoid and Transfer the Risk.

For example, if the Risk you are working on is "Unauthorized loss of data due to Laptops lost or stolen" then:

• Accept: nothing will be done for this Risk, someone accepts the risk and its consequences.
• Avoid: no one will be allowed to use Laptops (back in the 90s!)
• Mitigate: laptops will have strong authentication and end-point software to protect them
• Transfer: well, in this Risk is hard to imagine how this could happen

Possible Solutions

On top of describing what your desired treatment option is, risks require you to describe what your organisation is doing (as you are creating the Risk) to deal with these Risks. You will need to create or re-use already created solutions:

• Internal Controls: are used to describe activities performed in your company to deal with Risks. For example, you will create two internal controls "AD authentication in Laptops" and "End-Point Encryption".
• Policies: are used to describe documents (of any kind) that are used to deal with a Risk. For example, you might have a "Laptop Policy" or an "Acceptable use of Assets" policy.
• Exceptions: are used to describe a top manager's decision to do nothing in regards to this Risk. For example "No money to mitigate laptops Risks" 
• Projects: are used to describe activities (typically Internal Controls) that do not exist today but will exist in the future (in theory if projects are completed)

While you can save a Risk without describing in detail what is done about the Risk we strongly recommend you link these solutions to your Risks.

Reflect Today Reality

The method we use to identify solutions is split in two:

• Identify solutions that currently exist in the organisation (no matter if they work great or not)
• Identify solutions that the organisation would like to have in the future

In eramba, we always reflect the reality of "today", this is very important.

For example, if your risk is "Unauthorized loss of data due to Laptops lost or stolen" and today your organisation does not have an Internal Control "End Point Security Software", instead your IT department tells you that they plan to implement it in the future, what you would link to the Risk is:

• Treatment: Accept
• Solutions:
  • Internal Control: nothing
  • Policies: nothing
  • Projects: "End Point Security Software", owner IT, deadline 15th May 2026
  • Exceptions: "Not enough Endpoint Security", owner IT, deadline same as next Risk review.

With the use of Risk "Reviews" you will regularly review these solutions for changes.

Identification Process

In the same way, you rely on the expertise of the department you interviewed to identify the Risk in the first place, you will also rely on them to brainstorm "Solutions". Remember, "Solutions" almost always cost money and someone has to pay for them.

We strongly advise you to surround yourself with all departments that can help brainstorm these solutions, the decision tree shown in the table below is one of many ways on how to identify realistic, feasible solutions:

Note that is perfectly possible that your Risk will have a combination of "Solutions", we do not cover this scenario on the tree diagram shown above to keep things simple. For example, if the Risk you are working on is "Unauthorized loss of data due to Laptops lost or stolen" we could have the following treatment options:

• Treatment: Mitigate
• Solutions:
  • Internal Control: "Central AD Authentication on all devices"
  • Policies: "Laptop Hardening Standard"
  • Projects: "End Point Security Software", owner IT, deadline 15th May 2026
  • Exceptions: "Not enough Endpoint Security", owner IT, deadline same as next Risk review.

Practice will dictate what is best to do to reflect the reality of your Risk treatment, so as long you reflect today's reality you will be ok.

Outcome

As described above you need to make sure that for every risk you identify what "Treatment" will be used and what solutions are involved.

Remember that solutions have other mandatory fields on top of their title, the following are always the bare minimum you need:

• Internal Controls: who operates the control, what policy dictates how the internal control is operated.
• Policies: who reviews the policy, where the document is and when the next review will be done.
• Exceptions: who is signing off the exception and when will be the next review?
• Projects: who is implementing the project and when it will be ready?

Spreadsheets

If you are using spreadsheets for Risk management (as shown in the screenshot below), chances are you will not have these four solutions (and their bare minimum attributes) so you will need to collect this information for eramba.

This situation is perfectly normal since eramba is a software and does far more advanced monitoring of solutions. than a spreadsheet could ever do. Always remember, if a Risk on your risk register becomes a reality, will you be able to explain what has been done in regards to this Risk, discussed, reviewed and what treatment (and how that treatment has been tested and reviewed) exists?