Question - How to handle "closed" risks

I’ve got a kind of philosophy question on how to handle closed risks in Eramba.

Until now, I had a customized field to assets risks and set it to “closed” once it’s considered as over for good (some are pure IT production risks and can be solved for good).

So my customized status set it “out” of sight, but it is still there in Eramba and considered in the asset based risk matrix or in the asset based risk score, which therefore are not showing the reality of on going risk.

I did it this way to keep my history of risk.

Should I delete them instead or is there a way to customize things ?

yes - this is what will happen … its a tough thing to decide how to work on these type of situations, charts have no “logic” built in so as you say there is not much you can do.

1- delete it
2- work on new charts that work based on certain parameters (really expensive, time consuming)
3- define erambas “own” status (open, closed,etc) and hardocode charts accordingly

for the time being that is all i can think of … i tend to incline myself towards #2 but to be honest is complex and a ton of work i dont see this happening anytime now but probably is something we should perhaps start to include on the roadmap. i’ll think more about it and let you know. for the time being i think #1 is what you can do (i wouldnt but…)

External graph through API seems to be the only solution. I tried a post to verify if a special dev could be avoid. Thanks for your answer.

int ref:

again, is very unlikely we’ll work on this anytime soon as its not urgent but it is important and eventually we’ll have to do something about it

If it can be closed - was it a well-defined risk in the first place? I try to make sure we avoid making risks that are “temporary” and avoid typical project risks. If the risk is that temporary - is is just a vulnerability that is part of a larger risk perhaps?

Anyway - what I do is put Likelihood->Very unlikely->0 and Impact->Negligible->0 in the classification table. I also put [Default Threshold] -> Mitigated risk (Grey).

If you somehow take out the likelihood or the impact - it will be a “mitigated” risk.

Probably considered a hack by some - but I think it makes a lot of sense in some cases. Often a “mitigated” risk can re-appear over time (say you decide to not use some “risky” integration to mitigate the risk - but that some new manager would try to get that integration approved again)