At the moment, when you create a risk, the form requires you to fill-out two fields in the treatment tab that aren’t possible to make optional: mitigation strategy and residual risk classification. The result is that we end-up having to spend time populating these fields with fake data and have an additional status custom field to differentiate risks that have real treatment data from fake treatment data.
I believe that many other companies may approach risks in a multi-step way, like we do, and it would be a good idea to make the mitigation strategy and residual risk classification fields optional in the treatment tab. This will help simplifying and save time in our workflow.
Can the product team please comment on this feature request?
Hi @kisero, how can I look at the github reference you shared here? When I click on it, it says page not found. Perhaps because I don’t have permissions? Can I be granted read-only there? My GitHub account e-mail is fabio.lanza@me.com. Thanks.
Hi @kisero can you please share if this change is planned for upcoming releases? If so, do you have any estimate release date (e.g. quarter or semester)? Thank you.
Hi @kisero can you please explain what’s your view on risk capture? Do you believe that risks should only added to Eramba when treatment controls have already been defined and agreed on?
Noting that we are also a customer that would benefit from this. For now we state “accept” but this isn’t rally true. There are risks we track before treatment as we use Eramba at earlier stages and don’t prefer tracking it separately in a spreadsheet before we know the treatment or risk analysis of the actual planned treatment.
My take on this is to mitigate (since to “accept” means that management has accepted the risk, which is not the case), and put the treatment phase on the same matrix (probabilityXimpact).
I then connect it to a project (what I will implement to really mitigate the risk)
This will display the risk as high, above your risk appetite, but will be able to tell your auditors that you have identified the risk, and you are working on it (you ‘will’ mitigate it)
Your project/tasks deadlines will help you keep track of the mitigating process. You can edit your project accordingly when you have done your analysis.
After the project is complete, you change the residual risk to it’s new value and connect it to your new policy/control
we will see this when we get there (hopefully later this year), we are working one by one all forms on the software.
treatment (not the dropdown, but the solutions) is optional. the reason for this is that if you create a risk, the problem exists in the org. and somehow you need to define what the strategy is (indifferently if you know which solution exist).
as explained in the documentation, eramba needs to reflect today reality. if your org. has a risk and you create it in the software. the following scenarios are handled as follow:
“we dont have time to define/identify treatment”, then you accept the risk, you can use an exception or leave all treatment options empty. in eramba, you are not “mitigating” a risk unless you have a solution (typically control/policy) and these solution has a defined owner. we want to avoid empty promises in the software.
“we have a solution but we dont have time to create it”, some people has a placeholder control “To be defined” linked in this situations, the option above would also apply.
“we dont have a solution today but we wil some day”, create a project/exception and choose “accept” until the solution exists and has been audited.
“we dont care”, accept and create an exception
“we have a solution”, you mitigate, link control/policy to the risk. these should have been already tested, otherwise you dont really have a solution, you have a promise of a solution.
“is someone else problem actually” , you transfer and create exception
“we stop doing what cause the risk”, avoid and create exception
there might be another scenario which i might be missing, but the general logic is the one above.
