By: Marty Miracle
At the risk of sounding like I am just complaining to have something to complain about, I am going to complain about something!
I hate the concept of "inherent risk"!
Whew, I feel better already. Ok, maybe I should explain my loathing of the concept of "inherent risk". Let's start with a typical definition of inherent risk:"The probability of loss arising out of circumstances or existing in an environment, in the absence of any action to control or modify the circumstances.
The risk to a company in the absence of any security controls or actions that might be taken to alter, mitigate, or reduce either the likelihood or impact of a data loss.
The assertion behind either of the definitions above is that it is possible to have a condition (or even imagine a condition) that is absent any controls to prevent a negative event (process completion failure, system failure, etc.). For this to be possible (even theoretically) I would have to narrow the definition of a "control to mitigate" down so far it isn't useful. In a complex system (such as an application) the very code itself is a control to ensure the application can complete its designed function (how well it completes it is another story). By its very nature the creation of a process (no matter how immature) or the creation of a system implies the construct of controls to ensure it functions. To do otherwise means we have created nothing at all. Therefore if I "remove all controls" any negative event will happen as often as it is attempted or possible because I have no means of preventing it. Thus "inherent risk" is chaos and 100% failure. In my mind this is not useful when assessing risk.
So how can I show the value or importance of a process or control? How can I prioritize risks for evaluation/consideration? Tune in for Tilting at Windmills vol 2!