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 has multiple attributes, such as people who own them, review records, treatment options, classification, score, threats and vulnerabilities, etc.

Eramba ships with a pre-loaded database of threats and vulnerabilities which can be expanded using CSV imports. Eramba will try to suggest typical threats and vulnerabilities based on the assets related to your Risks.

To track changes and approvals for changes, every Risk has one or more review records. Every time you create a risk or close a review, you need to tell eramba when the next review will take place. This helps companies regularly review Risks.

Eramba will make sure that you don't miss a review deadline through the use of statuses, notifications, and reports.

You will use comments and attachments to log interactions (discussions, approvals, etc) between people when completing reviews. This makes accountability and traceability very simple.

All modules in eramba have 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 be sent to these people.

In the Risk Modules, we have two roles:

• GRC Contact: typically the person who has an interest in recording and treating the risk. Usually, this is the GRC or risk team.
• Risk Contact: the person or department that by doing something, generates a risk.

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 requires treatment, 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 with 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 a combination of the treatment options mentioned above will be used. For example, you might partially mitigate the risk, and, therefore, have two controls plus an exception and a project.

You can classify risks in any way that you want (so long as you are using two dimensions, for example, likelihood and impact). You will define your matrix in any way you want. When it comes to Risk calculations you can choose from four different methods.
 

The risk matrix is built for you automatically based on the risk classification settings defined by you. All you have to do is define a colour, title, and description for every combination.

For every Risk eramba will calculate a 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.

In the end, you will end up with two classifications and two risk scores - at the analysis and treatment phase. Based on the classification coordinates, eramba will know which position on the matrix your risk sits in 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 can 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 can 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 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 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 can flag items based on your 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 statuses based on your 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 logic), and when it matches, eramba will trigger the REST based on your endpoint url, headers, payload, etc. Eramba can also receive REST API 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.