Feature - Risk Treatment Score Calculation

Dear Eramba Development Team,

I am a frequent user of the Eramba platform and have been impressed with its capabilities for managing risk and compliance activities. However, I have noticed that one key feature is missing that would significantly improve the usability of the software.

Specifically, I would like to request that you add the ability to automatically calculate risk treatment scores based on the values set for each mitigation strategy. This feature would allow users to quickly and easily assess the effectiveness of different risk treatment options and make informed decisions about which strategies to implement.

Currently, the process of manually calculating risk treatment scores can be time-consuming and prone to errors, especially for larger organizations with many risks to manage. By adding this feature, Eramba users would be able to save time and ensure that their risk management activities are as accurate and effective as possible.

I believe that this feature would be highly beneficial to many Eramba users, and I urge you to consider adding it to a future update of the platform.

Thank you for your attention to this matter, and please let me know if you have any questions or concerns.

Best regards,

Devil’s advocate sort of question - what exactly would the calculation be based upon? Number of controls and policies associated to a risk? The issue with that approach is that each control/policy is likely going to be weighted differently depending upon the applicability and relevance to the risk.

So… that being said - how would this calculation work? Would it work like this feature suggestion that has already been made? Feature - Auto-calculate residual risk

Dear Eramba Development Team,

After further consideration, I wanted to suggest a possible solution that I believe would be highly effective and useful for Eramba users.

My suggestion is to allow users to assign a general mitigation value based on each risk treatment strategy’s attributed values manually. For example, a user might assign the following values for each risk treatment strategy:

Treatment: Internal Controls
Control 1: Risk Treatment attributed values: -10
Control 2: Risk Treatment attributed values: -20
Control 3: Risk Treatment attributed values: -25
General Mitigation Value for Internal Controls: -18

Treatment: Security Policies
Security Policies 1: Risk Treatment attributed values: -10
Security Policies 2: Risk Treatment attributed values: -40
Security Policies 3: Risk Treatment attributed values: -10
General Mitigation Value for Security Policies: -20

Treatment: Risk Exceptions
Risk Exceptions 1: Risk Treatment attributed values: -20
Risk Exceptions 2: Risk Treatment attributed values: -10
Risk Exceptions 3: Risk Treatment attributed values: -5
General Mitigation Value for Risk Exceptions: -12

Treatment: Projects
Projects 1: Risk Treatment attributed values: -30
Projects 2: Risk Treatment attributed values: -20
Projects 3: Risk Treatment attributed values: -40
General Mitigation Value for Projects: -30

With this information, the Eramba system could automatically suggest the resulting score by Likelihood (Treatment) and Impact (Treatment), with permission to manually set those values as well. This would allow users to quickly and easily assess the effectiveness of different risk treatment options and make informed decisions about which strategies to implement.

Thank you for your attention to this matter, and please let me know if you have any questions or concerns.

Best regards,

Avoiding Negative or Zero Risk Treatment Scores

To further improve the usability of the risk management features in Eramba, I would like to suggest that the system always result in the lowest score treatment instead of invalid values when calculating risk treatment scores. This would prevent users from accidentally assigning negative or zero risk treatment scores, which could potentially lead to confusion or errors in risk management activities.

For example, if a user assigns a value of 0 or a negative value to a risk treatment strategy, the system could automatically assign the lowest score treatment value to that strategy. This would ensure that all risk treatment strategies have a valid score, which would allow users to accurately assess their overall risk management efforts and make informed decisions about which strategies to implement.

Thank you,
Best regards

Just to be clear, I’m not on the development team, but I have no shortage of opinions :wink: .

Still having a difficult time understanding here - is this something that would be configured on a per risk basis or on a per treatment basis?

Looking at it per treatment (i.e. each control, regardless of risk), it takes away the ability to judge the overall relevance of the treatments applied to the risk. It would also lend itself to stacking a bunch of high value treatments to be able to declare victory, even if they are not applicable to that risk (i.e. MFA as a control to reduce risk associated with earthquakes).

Looking at it per risk, it’s really no different than what we already have, other than you’d be more clearly documenting your judgement as to which treatments are more important/not to that particular risk, which would defeat the purpose of suggesting the best treatment to the user since they’d still have to make judgements about the applicability of the controls.

I assume you’d also assign values to reviews expired, maintenance expired, maintenance failed, audits expired and audits failed to go along with this, though, that’s something that can be used to trigger a risk rereview using the system as it is - you can configure a custom status to trigger a notification for a user to re-review risks related to a control that just had a failure.

Thank you for your reply, David Schroth!

The risk mitigation feature based on per treatment basis allows for the automatic calculation of a risk treatment score based on values set for each mitigation strategy. The feature would provide a way for the user to input various mitigation strategies, each with their own set of associated values. These values would correspond to how effective each strategy is at mitigating the risk in question.

For example, the user could input a treatment such as “Internal Controls,” and under that treatment could list several control options such as Control 1, Control 2, and Control 3. The user could then assign a value to each control option, such as -10, -20, and -25 respectively. These values would correspond to the effectiveness of each control option in mitigating the risk. Once all the mitigation strategies have been input, the system would automatically calculate the resulting score by likelihood and impact.

Risk (mitigated) = (Likelihood x Impact) - Total Risk Reduction (-10 - 20 - 15)

Here, “Total Risk Reduction” refers to the sum of all mitigation values applied to the risk, which can be calculated by adding up the mitigation values of each control.

Implementing this mitigation strategy as a parameter in Eramba would provide a more efficient and less subjective way of calculating overall residual risk. By allowing users to input the mitigation values for each control applied to a risk, the system would be able to automatically calculate the total risk reduction and overall risk. This approach eliminates the potential for human error or bias in manually calculating risk mitigation and can also save time by automating the process. Overall, this feature would make risk assessments more accurate, consistent, and streamlined.

Thank you,
Best regards

treatment for risks is typically done by multiple solutions (controls, policies, exceptions, projects) and many times (if not most) in combination. a risk might use 2 controls, 1 project, 2 policies. any given control might be key to deal with risk A but might play a negligent role in risk B.

lets try an example, lets say i have two risks:

  • unauthorised access to end-point devices: if someone looses a laptop i dont want bad people accessing the laptop. for this risk i have two controls: laptop encryption and ad authentication (ensuring provisioning, de-provisioning and enforcement is done). clearly if i would like to access the laptop i would not care about authenticating it if the drive is unencrypted. the authentication control plays a negligent role in comparison to the encryption one in this case.

  • unauthorised access to our network due creeping accounts: we do not want people that no longer works for the company to access the company system/network. now having ad authentication as a control here is key.

so, my point here is, the control ad authentication might be key (high value in your suggestion) for one risk but very low in other risks. i have a zillion examples like the one above.

so, how is someone able to tell what single “value” applies for each internal control considering the mirad of things a control deals with in eramba (risks, data flows, compliance requirements, etc).

what systematic logic is to be applied to determine a value?

Thank you for your reply, Kisero!

The value assigned to each control should be based on the relative effectiveness of the control in reducing the risk. For example, a control that has a greater impact on the risk would be assigned a higher value than a control that has a lesser impact. Similarly, a control that reduces the likelihood of the risk occurring to a greater degree would be assigned a higher value than a control that has a lesser impact on the likelihood.

The values assigned to each control are then used to calculate the risk treatment score for the risk. This score provides a quantitative measure of the effectiveness of the controls in mitigating the risk, and can be used to guide decision-making on further risk mitigation measures.

By considering these factors, the control can be assigned a value that reflects its effectiveness in mitigating a specific risk. This value can then be used to calculate the overall risk treatment score for that risk, in combination with other controls and mitigation strategies.

In cases where a control could have different values for different risks, the user can input the values manually as they do today. The feature of Automatic Risk Treatment Score is intended to provide a default value based on the systematic logic described earlier, but it does not limit the ability for the user to adjust the value manually to reflect specific circumstances or considerations.

For example, let’s say a particular control is assigned a default value of -10 based on the systematic logic used to determine the risk treatment score. However, the user may decide that this value is not appropriate for a particular risk, and can manually adjust the value to reflect a more accurate assessment. Similarly, if the user determines that a control should have a different value for different risks, they can manually adjust the value for each individual risk as necessary. This flexibility allows the user to tailor the risk treatment score to their specific needs and circumstances.

It’s worth noting that assigning a single value to a control is not always straightforward, and may require input from multiple stakeholders and subject matter experts. However, by following a systematic approach and leveraging Eramba’s tools and functionality, the process of determining control values can be streamlined and made more objective.

All the best,

please use my example to provide an answer if you do not mind, is easier for us to understand things with examples. how can “ad authentication” have a single value when as shown on the example above, it can have negligent or critical treatment weights depending the scenario.

also remember that we need a systematic method (step one, step two, step three, etc) to determine the “value”.

First, we should take into consideration that automatic risk treatment score is based on a systematic logic that takes into account the baseline value of each control/mitigration strategie for risk mitigation.

Second, in your exemple/case, the value of the control may differ depending on the specific risk it is associated with. For example, in the case of the risk of unauthorized access to end-point devices, the encryption control could considered as more valuable than the authentication control. On the other hand, for the risk of unauthorized access to the network due to creeping accounts, the authentication control is key.

However, it is important to note that even if the automatic risk treatment score is not able to capture the nuances of each control’s value in every scenario, the user can always input the values manually, as is currently done in Eramba. :slightly_smiling_face: This allows for a more customized and tailored approach to risk management and treatment that takes into account the specific needs and requirements of the organization.

listen, i really appreciate your posts and i can see you are very polite and i really like polite people even if i dont agree with their opinions. so let’s start with a nice warm start.

the discussion you have brought here has been brought before (you can probably search for it) and the conclusion is that there is no magic formula. as you said, risk management is way subjective in this industry and adding more subjective inputs to any formula produces even more subjective outputs. so we prefer keeping things simple and forcing people to think.

we do appreciate your enthusiasm!

Thank you, Kisero, for your thoughtful reply! Your insights are much appreciated and add value to the discussion.

Manual calculation of risk mitigation for a large database of more than 4,000 risks can be an extremely time-consuming process, especially for risks with medium or low severity.

In contrast, automatic mitigation calculation based on pre-established mitigation values could allow the user to focus more effort on the 1,000 risks with high or critical severity. This way, the system could optimize the allocation of resources and help increase the efficiency of risk management practices.

Thanks again!

I would contend that’s a systemic issue with the risk assessment methodology rather than any tool you are using whether it supports the proposed function or not…

yes, more or less i think we think the same way, for now!