Risk Management in Practice: Lessons from Diving for IT Security

I have been diving since 2015 and am now a licensed instructor with the Professional Association of Diving Instructors (PADI). Diving is fundamentally a safe recreational activity, but it nevertheless remains an excursion into a hostile environment – underwater – and so it involves some risks. There are many parallels to IT security in this respect – especially when it comes to providing an IT service on the Internet. Both activities can be carried out safely if common precautions are taken – one of which is risk management. In this blog article, I show the various components that make up risk management and what we can learn from diving.

Risk management is the ongoing process of addressing risks holistically: identifying, recording, treating and monitoring them. In this blog post, I will discuss the four known risk treatments. These are risk acceptance (take no further measures), risk mitigation (take financially feasible countermeasures), risk transfer (such as insuring possible damage) and risk avoidance (discontinue the risky activity).

In the corporate environment, identified risks are recorded in what is referred to as the risk register, categorised by priority and each risk is assigned a risk treatment. The goal is to track, capture and minimise business-relevant risks over the time in line with the risk appetite that is acceptable to the company as set by the management (how much risk can we accept, how much do we want to risk?).

Risk mitigation and risk acceptance – literally a fluid transition

The risk timeframe in diving is usually short, for example assessing the water situation in terms of swell and current – though this isn’t usually a significant risk factor in Swiss lakes. However, some measures do have a longer-term dimension, especially risk mitigation.

I can generally minimise the risks involved in diving by improving my skills, for instance by diving regularly or taking further training courses and making sure that my equipment is serviced at appropriate intervals by professionals in diving shops. Of course, there are shorter-term risk mitigation measures, such as reacting to lower water temperatures by diving with a thicker wetsuit or even a dry suit. Here the transition to risk acceptance can be fluid, for example if the water temperature on the planned dive is only below expectations at the deepest point, but is bearable for a few minutes. If so, I can accept this situation, but as usual in risk management, I have to monitor things in order to be able to react in an emergency. If my body indicates through shivering that the temperature is too low, I need to come up to a shallower position where the water is warmer.

Risk avoidance – anything but a weakness

A frequently misunderstood type of risk treatment is risk avoidance. As already explained, risk avoidance means not engaging in an activity. But what does that mean exactly? Another useful comparison is that diving is not a competitive sport. If a person feels physically unable to do the planned dive, it is in their own interest as well as in the interest of all involved (dive buddies, lifeguards etc.) to exercise caution and not do the dive – that’s risk avoidance! In other words, I consciously avoid the risk of being injured during a dive by sitting it out and waiting until I am fit enough to dive again. Recognising this situation and reacting with the risk-avoidance strategy is not weakness, but can be life-saving in this case.

Risk avoidance as a strategic decision

In the business environment, risk avoidance requires a greater degree of decision-making, potentially at the executive level. This can have an impact on business strategy and may also require a reorientation of business areas or projects – even if investments have already been made – because of a changed threat level.

One example of misunderstood risk avoidance that I have encountered in my practical professional life was during a risk assessment of an IT service:

• Risk point: the API (application programming interface) can be accessed externally.
• Risk: a vulnerability means that the API could be hacked and customer data stolen.
• Risk Treatment: Risk Avoidance
• Measure: we don't want to be hacked.

Attentive readers will have already noticed what is obviously wrong here: apart from the fact that the measure listed is not a real measure, the risk treatment (avoidance) does not fit the measure. As long as an API is externally accessible, there is always a chance that it can be hacked via a vulnerability. If risk avoidance is indeed the desired risk treatment, then the logical consequence would be to prohibit all external access to the API. This means that the API would have to be removed – other measures such as making the API only accessible via VPN are no longer part of risk avoidance.

Risk transfer: an option in IT security, but a “must” as a diving instructor

Finally, we have risk transfer. In business, it is possible to protect oneself from financial loss through insurance or an indemnity clause in a contract – an option that should be carefully considered if there is a low probability of a risk occurring, but the extent of the damage would be unacceptably large.

Unsurprisingly, insurance for instructors is not an option, it is a “must” and it must cover the students as well.

InfoGuard – your partner in risk assessment and risk management

How can InfoGuard support you in risk assessments or risk management?

InfoGuard has consulting specialists who are certified in risk management, for example ISACA CRISC, or have many years of experience with risk frameworks such as ISO/ISE 27005. In line with our mission statement “We do everything we can to keep our clients safe”, we will be happy to offer you tailored advice to identify your specific needs and requirements in the area of risk management. Contact us for a free consultation!