Posting Rules:
2- I’ve searched the manuals and used google to search but I can’t find anything that directly relates to how these scores are used and how they differ from the values chosen on the analysis tab.
They are set up with classification - Risk Management | Eramba learning portal. The score should be the same for any classification regardless of being on the analysis or impact tab.
Quite frankly, I do not use the scores. They are also impacted by the risk multiplier set in Liabilities related to a given risk and prior documentation gave an example for dynamic statuses to trigger when a score hit a really high level.
I would say if you’re slogging through a risk assessment for the first time in Eramba to not worth about the score, and focus on the two attributes you selected for the risk matrix…
When I try to import my initial list of business risks the template has columns for these fields : Business impact (Treatment),Likelihood (Treatment) and won’t let me import without adding a value. If I understand what these fields are for I might be able to put a value in there that is somewhat meaningful or at least easier to justify to the new users of eramba who will, no doubt, ask what the scores mean
Ah - I think I answered a different question.
The Business Impact and Likelihood for both Analysis and Treatment are configured in the above mentioned classifications setting - you can call them anything you want though (it can be Bananas and Apples, for example). For the levels, that’s something you have to configure in accordance with your risk methodology - usually a 3 or 5 point low/med/high sort of deal will suffice, but you can certainly change it up. It’s highly suggested to have some form of quantification to help users - for example, a very high impact could mean greater than 20% of revenue lost (amongst other criteria).
On the import side, eramba is making you perform both your initial inherent risk analysis (likelihood/impact on analysis) AND your initial residual risk analysis (treatment) when you first load it into the system.
You’d think of the difference this way -
Analysis (Inherent) - If the risk had no mitigations in place, how do you rate the likelihood and impact of it occurring? For example, destruction of datacenter due to 2km wide asteroid striking. This would be a medium likelihood and very high impact (for lols, of course), which might result in a “medium” risk according to the risk matrix you’re using.
Treatment (Residual) - This is the likelihood/impact after you have implemented mitigations. In this scenario, let’s say you have 2 controls (Asteroid destroying laser and Asteroid Proof Roofing Singles) and a policy (Asteroid Protection Policy) - you document those and you’d note that the likelihood is now a low and the impact is a medium (due to the implemented controls), so you’d set this for Treatment, which may give you a “low” risk according to your risk matrix.
Now, this is a slightly different approach to a common “spreadsheeting” way of doing this which would have you do (likelihood times impact) minus control effectiveness to determine residual risk.
Is this more what you were looking for feedback on?
That’s a stellar answer that rocks.
That answer was meaty all right ( 
) (meteorite)(for groans, of course)
Here’s my understanding after reading your post, correct me if I’m wrong
TDR: Analysis and treatment are like a before and after.
We assess the risk as if we do nothing and record impact and likelihood in the Analysis tab.
We work out what the risk would be if we complete the proposed controls/policies/reviews/projects and record this in the treatment tab. Ideally the “numbers” on the treatment tab should be ‘smaller’ than those on the analysis tab.
This gives us a ‘difference’ or improvement we can use to help determine priorities for the work we carry out. eg if its a high risk but even after we’ve applied everything the risk is still high then we might a) decide we need more /different controls/policies etc or b) we might schedule the work for risk one after a risk 2 where we can eliminate risk2 with a similar amount of work.
Sounds like you’ve got it - couple of other thoughts -
This kind of depends on where you are in your risk assessment maturity. I would prefer to document inherent risks with the mitigations that are actually in place as opposed to planned. If all you’re doing is planning to mitigate, your analysis and treatment ratings should be the same. You can deal with these placeholders with eramba as well - you can mark the controls as “in design” (which may flow through a custom status to the associated risk) and you’d denote the fact you’re working on it with a project. Sure, at first when starting a new program, there may be more plans than reality, but you’ve got to reflect reality to the rest of the business.
The other configuration that I like to set up is a custom status/alert on the risk side for when control audits or maintenances fail - basically to alert me that I need to reassess (review) the treatment/inherent risk for that item due to a change in the functioning of the control.
Yup - That’s risk assessment basics right there and you can have a process to decide to simply accept risks (or partially mitigate). You’ll see there’s a configuration for risk responses - most everyone always chooses “mitigate”, but there should be a few other standard ones like “avoid” (stop doing something), “transfer” (buy a lot of insurance) or “accept” (the YOLO method).