Risk Management in IT and Technology

Risk management is an overlooked aspect of IT and generally in the broader technology landscape, frequently it is conducted under a facade of “checklist risk management“. However, with the rise of security and privacy being top of mind, the risk management needs to be a conscious activity done throughout the IT lifecycle. And risk management needs to be more than an exercise of appeasing an audit, or checklist risk management.

Risk management introduction

You may already be familiar with a risk matrix similar to the one below. And your organisation will likely have definitions for how to scale the consequence based on:

  • Direct financial impact,
  • Indirect financial impact,
  • Injury or death,
  • Recoverability,
  • Disruption to business continuity,
  • Reputation change,
  • Legal or regulatory actions,
  • Directors’ liabilities

Your business also likely has guidance on how to determine the likelihood of a risk manifesting. This usually is posed in terms of “chance” of occurrence within a time period, or it may be backed by statistical data from past events, or the likelihood will be presented to you by an external organisation.

The typical process is:

  1. A group of people to get together,
  2. Identify the hazards1,
  3. Identify the corresponding unmitigated outcomes of the hazard,
  4. Apply consideration for the scale of the consequence and likelihood of each hazards’ outcomes. This is the risk2,
  5. Consider any mitigations that can be applied to reduce either, or both the consequences or likelihood,
  6. Reconsider the scale of the consequence and likelihood of each hazards’ outcomes after each set of mitigation has been applied.

The goal is to reduce the risk to ALARP (As Low As Reasonably Practicable) or SFAIRP (So Far As Is Reasonably Practicable). In many Workplace Health and Safety regulations, they will have required of what is meant by these. In IT, it generally means, based on your organisations risk profile, how much money, time, and disruption to process, is tolerable to reduce the risk.

Risk Management

However, when it comes to risks in IT, it can be difficult for non-technical personnel to quantify the risks, and it can be difficult for the technical team to assign appropriate consequences. Further, the environment that IT lives within, is far more dynamic with hazards thought to be benign yesterday, serving an unmitigated and exploited vulnerability that takes down the entire business tomorrow. And that is before you notice or react.

Fire Safety

For comparison and to highlight the level of seriousness, how many structural fires (buildings, including commercial, industrial and residential) have you heard of in the news lately? I will wager that that number is significantly lower than the number of organisations, and individuals that have been impacted by a Cyber Incident. The large Cyber Incidents make the news, however, almost every industrial fire or cluster of residential house fires makes the news.

As far as some real numbers. In 2013, there were 19,5243 fires that Australia Fire and Emergency agencies attended to. In that same year, Yahoo was breached with more than 3 Billion accounts compromised globally4.More recent numbers from 2022:

  • 9.8 Million customers of Optus were compromised5,
  • 9.7 Million customers of medibank were compromised6,
  • 95,100 Cyber Incidents were reported to the Australia Signal Directorate7.

Fires, and the number of people they impact are insignificant compared to Cyber Incidents, yet they are still absolutely devastating impacting a wider range of people than directly involved with the fire. When we look at fires, we have several ways that we mitigate, and we have several things that are acted upon in the immediate aftermath.

Our first tool is prevention:

  • Consider the failure mechanism, and how we ensure that there is a safe path for the people to escape.
  • Choose materials that are flame retardants.
  • Do not co-locate accelerants with fuels.
  • Safety standards and regulations for built environments of electrical, and mechanical systems.
  • Training and drills to know how to behave in the event of a fire.
  • Constant enforcement of the standards for the organisation.
  • Designing the built environment from the start to reduce fire risks.
  • Gaps and boundaries between buildings as a fire break.
  • Australian and ISO standards (AS 1670, 1841, 1851, 2293, 2444; Building Act 1975/2012, ISO 2392-1)

But, we also have the tools that help in dealing with the immediate aftermath, and the control.

  • Fire warning systems kick in.
  • Fire suppression systems kick in.
  • Emergency lighting and signage.
  • Emergency responders who are specialty trained.
  • Local infrastructure to assist in firefighting.

The key with all of this is, parts of the fire risk management are very prescriptive. But other parts are left for the interpretation of a professional, and the client.

The same needs to be done for IT and technology. In ensuring that there are enough preventative measures in place, looking at the failure modes, and ensuring that you have a professional that understands both the technical, and the business impacts.

Fire is also an interesting comparison point because the risk management has both prescriptive (“checklist risk management”) and interpretive risk management. In the many many instances I see with clients, they are almost exclusively in checklist risk management. This works for well-known and understood risks, but also can work against you when a vendor appears to offer a solution that perfectly ticks that box. And, if you are chasing the checklist, you are not taking the time to stand back, and evaluate if that checkbox is right for you, your organisation, and your risk profile.

Techniques

Some of the techniques that I use with clients that have limited risk management in place for IT and Technology include:

  • Review the existing risk register.
  • Understand the businesses tolerance to types of disruptions:
    • Availability (system up time),
    • Changes to technologies,
    • Changes to process,
  • Understand what the businesses core value is, and the process is to deliver that value.
  • With the client, white board session to process map of existing flows, with a critical eye on what could go wrong, and the technologies that will impact the behaviour of the flow.
  • Review existing vendors, with a view to identify changes to service that will impact the organisation, level of access they have into the organisation, systems that are under the vendors’ control.
  • Identify critical software and systems, and how they could be adversely impacted.
  • Identify the secondary, redundant, alternative systems in place for the critical systems.
  • Understand the regulatory environment that my client operates within.
  • Conduct exercise of: what would an adversary do to get to that data/information?

This will produce quiet a number of actions that need to be taken to mitigate what has been discovered. This can be as simple and unintrusive as changing an update configuration/policy, to more involved and require reworking entire core processes and technologies.

Outsourcing the Risks

Whilst it can sometimes clients believe that they can outsource risk, if something happens, it is your organisation that is on the hook. You can outsource the tools, tasks, projects and even entire departments. But ultimately, the risks your organisations to own. This is important when you rely on the technology that holds, processes, collects, your businesses processes. Working with your entire supply chain to ensure that the risks are appropriately identified, and mitigated will build higher resiliance.

It is the responsibility of the agency to wear the risk associated with their operations – you cannot outsource risk. – Alastair MacGibbon8

This can also become your strategic advantage, by ensuring that your business understands the risks that you have when you outsourced tasks, projects and tools, you can mitigate better and weather the storm of a Volatile, Uncertain, Complex and Ambiguous (VUCA) environment.

Definitions and References

  1. Hazard is something that has the potential to cause harm. It could be a physical item, a process, software, an activity, a substance etc. i.e. a network cable, payment processing, email system, lodging a ticket, thermal paste. ↩︎
  2. Risk is the likelihood and severity of the harm resulting from exposure to a hazard. ↩︎
  3. Chapter 2 – Parliament of Australia (aph.gov.au) 2013-2014 there were 19,524 structure fires. ↩︎
  4. Yahoo says all three billion accounts hacked in 2013 data theft | Reuters ↩︎
  5. 2022 Optus data breach – Wikipedia ↩︎
  6. What we know about the Medibank cyber attack and what to do if you’re a customer – ABC News ↩︎
  7. ASD Cyber Threat Report 2022-2023 | Cyber.gov.au ↩︎
  8. Agencies must ‘wear the risk’ of outsourcing: MacGibbon – Strategy – Cloud – iTnews ↩︎