Developing an Appetite for Risk?

8th November 2014

woman cliff jumping

Risk assessment methodologies such as InfoSaaS are based around calculating levels of risk, and comparing the result against pre-defined levels determined by the organisation as being their “risk appetite”. But what does this term actually mean, how it is calculated and how does it become a pragmatic yet effective foundation to your Information Security Management System which is assessed against ISO27001?

From the outset, having an appetite for risk is a strange concept to many, who quite reasonably believe that nobody would willingly accept a risk if it was in any way avoidable, or similarly how can there be a value applied to risk which is, by its very nature, very difficult to assign a number to? To put these opinions into context, information security risk management, unfortunately, has to deal with a wide selection of potentially “bad things”, from power outages to credit card fraud and component failure to employee theft (among many, many more). It is easy to see, therefore, that the effort involved in managing risks is always going to incur cost and effort, as the best result that you can hope to achieve is the predicted events not happening, or business as usual.

Risk appetite is built around the reasonable assumption that not every identified risk should be dealt with at all costs: some will be disproportionately expensive to resolve, and some will have such a low impact on your organisation that implementing complex controls as directed by a policy may be assessed as simply not being an appropriate use of time and money. So how can you determine risk appetite in a pragmatic fashion?

Firstly, how would your organisation like to assess the impact if something bad were to happen? For many this has a direct currency alignment  – “we have contingency to fix things if the cost is below GBP 10k, but above that we’d have to divert funds from live operations”. The latter would affect ongoing business if live operations are impacted, so in its crudest form we’ve determined the sort of events that would be acceptable to the organisation, vs. those where we need to simply take a little more care to make sure that they can’t happen. Another method could be to assess the negative impact on the organisation’s credibility or brand reputation for certain events, and identify which need to be avoided at all costs, as a matter of business survival, vs. those that events that customers won’t even notice.

Next, to add some justification to these decisions, by looking at probability and impact. Probability can be assessed by looking for similar events in comparable industries, or assessing media reports of incidents and breaches to see if your organisation could be similarly affected in the future. As noted in the previous paragraph, impact can be measured in hard cash (cost to put right) but is also likely to factor in unwanted negative publicity and resultant competitor advantage.

Most risk assessment methodologies employ a probability vs. impact comparison to determine whether a risk is acceptable – i.e. does the calculated risk fall above or below the organisation’s risk appetite? Within InfoSaaS we use a 5×5 matrix, with corresponding values between 1 and 25. An event that is extremely likely to happen, and even if it did nobody would notice or be affected would be graded as “1”. However, a negative event that is definitely going to happen, and when it does the continued operation of the business is called into question would be graded as “25”

In our experience, the Senior Management of most organisations will set an acceptable risk limit (or have a risk appetite) of somewhere between “7” (very cautious) through to “12” (more bullish), although we have seen values either side of these. Our own ISMS operates as a “10”. In its simplest form, numbers below 10 (lower probability, lesser impacts) will be accepted as part of the risks of delivering normal business, whilst anything above 10 (more likely to happen, with a greater impact) needs to be carefully looked at to see if better security controls can be implemented, or whether existing security controls need to be delivered in a more effective way.

Back to Insights

Share Insight: