Risk Management

Eramba does Risk Management in three ways:

• Asset Risk Management
• Third-Party Risk Management
• Business Risk Management

Each of them has its own module, and the good news is that they all work almost identically. What changes is the input that each one of them receives:

• Asset Risk Management uses Assets as inputs
• Third-Party Risk Management uses Assets and Third Parties as inputs
• Business Risk Management uses Business Units and their processes as inputs

If you are assessing a supplier, you will most likely use the Third-Party Risk module. If you are assessing a business process in terms of its continuity, you will form the Business Risk Management module. If your risk focuses on something tangible, it is likely that the Asset Risk module is the one you need. These inputs provide context to your risks, and they help explain your risks.

The Risk module lets you record risks like a risk register. Every risk will have multiple attributes, such as people that own them, review records, treatment options, classification, score, etc. We will now introduce you to all of these different attributes.

These inputs will be subject to threats and vulnerabilities. Eramba ships with a threats and vulnerabilities database, and you can choose which ones apply to your risks or describe them in text format. Eramba will try to suggest typical threats and vulnerabilities based on the asset types.

 

 

Risks have one or more review records in order to track changes and approvals for changes. Every time you create a risk or close a review, you need to tell eramba when the next review will take place. Eramba will make sure that you don't miss a review deadline through the use of statuses, notifications, and reports.

 

 

Your reviews (and any module in eramba) use comments and attachments to log interactions between people. When a review is taking place, all discussions will be recorded there. This makes accountability and traceability very simple.

 

 

All modules in eramba use roles. They help us understand who owns what, who can see what while using the software (with a few exceptions, you can only see what you own in eramba), and, of course, notifications will point to these people.

In the Risk Modules, we have two roles:

• Owner: typically the person that has an interest to record and treat the risk. This is typically the GRC or risk.
• Stakeholder: the person or group doing something that creates the risk. This is also the person that by default will own the reviews of the risk. When a risk is created and reviews are automatically created, the stakeholder will own them.

If you do not like these titles, you can use customisations to change them to whatever name you prefer. Customisation allows you to rename, add, hide, and move around fields and tabs in any form and any module.

 

Every risk will require a treatment option. We use the four typical options: Accept, Avoid, Transfer, and Mitigate. Once you choose one of these options, you need to determine which treatment modules you will associate to the risk:

• Projects: when you want to mitigate the risk, but you do not have a solution (Internal Control or Policy), and the solution is a plan for the future.
• Exceptions: when everyone agrees that the risk is there, but nothing can be done about it at the current time.
• Policies & Internal Controls: when you want to mitigate the risk and your organization has an internal control in place.

 

 

Many times, you use a combination of the treatment options mentioned above. For example, you might partially mitigate the risk, and, therefore, have two controls plus an exception and a project. 

If you create a Risk, you then need the inputs we mentioned (assets, third parties, and business units) and the treatment options (projects, controls, exceptions and policies). They are all separate modules that link to your risks. That is why you need to understand multiple modules to use the Risk Module.

You will classify your risks in any way that you want (so long as you are using two dimensions, for example, likelihood and impact), choose from one of the calculation methods available to you, and configure the risk matrix with your titles, colors, etc.
 

The risk matrix is built for you automatically based on the risk classification settings that you set. All you have to do is define the color, title, and description for every combination.

 

You will define for every risk its classification, and eramba will automatically calculate the risk score in two stages:

• Analysis: this is meant to classify the risk as it was first identified.
• Treatment: this is meant to classify the risk after whatever treatment was applied.

So in the end, you will end up with two classifications and two risk scores, at the analysis and treatment phase. Based on the classifications coordinates, eramba will know which position on the matrix your risk sits and apply the label you defined.

 

 

For the most part, Risks are problems waiting to occur, and it makes sense to plan what actions will be taken when they take place. For every Risk, you can set a procedure (which comes from the Policy module) that describes how the Risk should be responded to.

 

 

So far, we discussed creating and reviewing risks in the register, but there is a lot more to it. You will use notifications to trigger emails or REST APIs to notify when reviews are due, say, one, five, or 10 days before and after the deadline.

 

 

You will create filters that will let you know what risks are expired, what reviews are due in the next couple of weeks, the top-10 risks, new risks, and so on. There are literally a million combinations available to you.
 

 

Any filter you create can be exported as a CSV or sent to you as often as you want over email, so you won't even have to log in to the system to know what is going on. 

Reports are also available as charts. These are shipped with standard reports and let you know visually what is going on.
 

You can create your own reports with a report builder based on widgets that you drag and drop into a template. You can use text, tables, filters, and charts that we ship with.

 

 

The outcome will be a graphical report with your desired data. These reports can also be sent over email in PDF format as often as you want, so you don't have to log into the system.

 

 

 

You will want to flag items based on your own conditions: when a risk expires, when a review is missing evidence, when a risk is too high, when the mitigation elements are untested or not working, etc. We use statuses across all modules to highlight these flags, and we ship with hundreds of them preconfigured for you.

 

 

But you can also create your own statuses based on your own conditions, and again, you have access to thousands of possibilities with the status configuration tool.

 

 

Every time a status matches (or fails to match) your conditions, a label will be applied to the risk. You can optionally trigger emails and REST APIs, too. For example, you can notify the risk owner and stakeholder of a risk when the score becomes too high. The options are endless, and it is really up to you what level of complexity you wish to use.

Eramba uses web forms to create things, and these forms have been preset for you. The good news is that eramba ships with custom fields on every module, so you can add, hide, rename, and move around fields on the form in almost any way you want.

 

 

 

A user-friendly interface lets you do all of the work without needing to know how to code software.

As explained, REST APIs can be triggered from eramba to other systems using notifications. You set the condition (from a preset notification or status defined by your own logic), and when it matches, eramba will trigger the REST based on your endpoint url, headers, payload, etc. Eramba can also receive REST APIs calls to create, update, delete, or list risks.

 

 

We use Swagger, so our documentation is automatically created no matter what we change on our software.