Service Design - Design Risks

ISO 31000 defines risk as the effect of uncertainty on objectives, which can be either positive or negative. We use risk management to identify, assess, and prioritize the risks and follow those up with a corresponding and efficient application of resources to minimize, monitor, and control the probability or impact of unfortunate events in the future.

Risks in IT can come from a variety of sources including; uncertainty in financial markets, failures with IT or business projects, legal liabilities, credit risk, accidents and mistakes, natural causes and disasters as well as deliberate attacks from an adversary such as hacking.

During the design phase we would want to:

• 1. Identify, characterise and assess threats/risks
• 2. Assess the vulnerability of certain assets (usually the critical ones first) to specific threats. Such as an online payment processes vulnerability to hacking or fraud.
• 3. Establish the particular risk (i.e. map risks to particular assets)
• 4. Identify ways to reduce risk and include them in design
• 5. Prioritize risk reduction measures and again include in design

The ISO standard outlines the principles of risk management, but more generally risk management should aim to create value or improve it. It should be an integral part of design and processes, and specifically address uncertainty. Risk management should be a structured and methodical approach, taking into account human factors.

Once risks have been identified, they must then be assessed as to their potential severity of loss and to the probability of occurrence. These quantities can sometimes be simple to measure, e.g. the value of a lost building, or in other cases they can be impossible to know for sure. Such as the probability of a freak event occurring, which may never have occurred in the past.

One of the most difficult parts of risk assessment is determining the rate of occurrence. Since statistical information is not always available on all kinds of past incidents and events which have a very low probability but drastic results are of course hard to weigh up.

There have been several theories and attempts to quantify risks. In actual fact, numerous different risk formulae exist, but probably the most broadly accepted formula for risk quantification is:

Rate of occurrence multiplied by the impact of the event equals risk

Coming back to ITIL a little, risk management is one of those things that's a little bit underemphasized. ITIL Service design doesn't prescribe any particular designs that you should use for this. However, we would normally follow the ISO standard and add risk assessment as one of the core items of a design review. We want to mitigate risks so they don't flow down stream to the production phase where it's much harder to fix these things. A good example of a risk would be; we won't be able to fund the depth of monitoring for this design. Another good example is compatibility; we may be running an app on an older version of windows server which is not compatible. This would be identified as a risk.

Cost recovering structures are also another thing that needs to be considered in the Service Design phase. The point about Service Design is that you should at least consider all of the aspect of design whether it is big or small. If something can't be addressed then that's considered a risk.

Risk Analysis

Is used to identify and quantify risks and appropriate countermeasures to safe guard availability of systems. We specifically undertake RA at the design phase to ensnare all possible risks, vulnerabilities and threats.