Measuring Risk Using a Supply Chain Approach

Risks are everywhere, but some risks matter more than others. ISO 31000, the risk-management standard with the broadest international reach, defines risk as “the effect of uncertainty on objectives.” In any company, uncertainties (both the upside and downside) abound, and objectives can range from buying a new printer to launching a new product.

In this post, I offer guidelines you can use for measuring the risks that matter. Along the way, I point out the importance of collaboration in identifying, measuring and mitigating risks. When IT departments work closely with their business units, risks can be understood and addressed.

Identifying risks associated with strategic objectives

IT organizations are responsible for identifying a wide range of risks, including unpatched systems, new malware variants, new phishing techniques and more — the list goes on. While it’s important to track these risks, to measure and prioritize them, you need to consider their context. After all, the risk from a single security vulnerability can differ from one system to another.

Consider, for example, two file servers that are both lacking the latest patches for an application. One file server stores lunch menus for the employee cafeteria. The other stores manufacturing designs for a new product that will be introduced next month.

Clearly, the server with the design documents is more strategically important. Therefore, its risks should take priority over the risks affecting the file server with the lunch menus.

From this example, we can derive a general rule: Any risk that jeopardizes a high-level strategic objective takes precedence over risks that affect only lower-level objectives.

Given this rule, the work of measuring risk begins with identifying your company’s strategic objectives. Then you can explore the IT infrastructure that supports your company’s pursuit of those objectives.

Think of it as a form of supply-chain analysis. You’re tracing the flow of data, people and operations from a high-level goal down to the specific IT systems and processes that help the company realize that goal. These systems and processes function as a kind of supply chain for the objectives themselves.

For example, let’s say your company has a high-level goal of delivering reliable, cutting-edge financial services through a mobile app. Clearly, the web server, databases and software modules that support this mobile app are strategically important. Any risk that could take them offline would also be considered important, especially when compared with a risk to an internal application that is never used by customers.

In this instance, the company’s risk-management team should ask questions such as:

• Which systems and processes directly support the reliability and innovation of our financial-services mobile app?
• Which systems and processes enable those systems and processes?
• What’s the system that makes the mobile app work?

To measure risk, identify these interconnections and trace them as needed in accordance with your company’s objectives and capabilities.

Not all systems and processes in this “supply chain” are equally important. To measure risks within the supply chain itself, assign a value to everything (that matters in consideration of the 80/20 rule) from the top-level objective to the lowest supporting system or process.

Building a range of risks

Your strategic objectives also need to be compared and valued. It’s rare for a company to treat all of them equally.

Once you’ve identified your top objectives, assign each one a value along some kind of range. For example, based on conversations with your executive team, you might assign continued revenue growth of at least 10% CAGR a value of 10 on a range of 1 to 10, meaning it is the most important.

By contrast, you might value regulatory compliance as a 7. This doesn’t mean compliance isn’t important to the company. It just means that assuring compliance is excellent, but it won’t be the top-level priority that takes precedence over every other investment.

Next, identify the people, processes and technologies involved in supporting each strategic objective. Then rank the importance of each supporting factor.

To provide further nuance, you can estimate the likelihood of a specific failure occurring. For example, imagine that your company has a web server supporting a business-critical mobile app. The odds of that server delivering unacceptably slow performance during a period of peak usage are probably higher than the odds of that same server succumbing to a power outage that crashes both the main and backup power systems.

By multiplying the rank for the strategic value of the server (say, 7 out of 10) by the likelihood of a specific risk (say, 50% or 0.5), you can begin to both rank the risks and identify those that require more immediate action.

For example, let’s say the likelihood of a server delivering slow performance is 40%, while the likelihood of a server crashing in a catastrophic power outage is just 2%. If the server’s importance ranks a 7 on a range of 1 to 10, then the risk value for the slow-performance scenario would be 7 times 0.40, which yields 2.8. Then the risk value for the power-outage scenario would be 7 times 0.02, which yields 0.14. The slow-performance scenario, which has the higher risk value (2.8 vs. 0.14), is obviously the risk that will need attention first.

The importance of collaborating to measure risk

Performing this type of risk assessment takes a lot of work and an openness to embracing ambiguity, paradox and uncertainty. It includes collecting detailed information about people, processes and technologies across the company and synthesizing it into an understanding of what to do.

Realistically, no single person or team knows offhand all the details and vulnerabilities associated with all the IT systems and processes that support all the company’s strategic objectives. The IT department will need to reach out for help.

My advice: If you’re evaluating a department’s processes and technologies, then ask that department for help. For example, if you want to understand the risks surrounding the human resource (HR) department’s applications, then talk to someone in HR. They will likely know things about their application that the IT operations team doesn’t.

When talking to people outside the IT department, minimize your use of technical jargon. When talking with IT colleagues, it’s fine to use technical lingo such as, “Are your controls operational?” But outside IT, that kind of language is likely to be confusing.

When I talk to non-IT people, I instead generally speak in terms of empowering good things and preventing bad things. I also ask them about a process or application’s purpose. I discuss the objectives of our risk-management process. And I explain how our risk assessments can help them get work done and realize their own departmental objectives by increasing certainty of success.

Another piece of advice: Never tell somebody how to do something without first asking them how they think it should be done. If you impose a solution, you might miss out on a creative alternative. You might also find that people balk at following a new policy that affects them directly, especially if it doesn’t take their ideas into account.

A better solution: Solicit advice from business users. Then you can come up with a risk-management solution that they’re likely to support.

Risk management is a company issue, not just an IT issue

When people outside IT realize you trust them and that you’re genuinely interested in what they have to say, they’ll communicate with you more freely. They’ll also be more likely to take ownership of the risk management solutions you jointly put in place.

This ongoing collaboration is one benefit of taking a “systems” approach to managing risk through integration. You not only discover the details you need for measuring risks more precisely, but also educate organization stakeholders about the importance of risk measurement and mitigation. And you get to collaborate with these stakeholders to develop solutions that minimize the risks you’ve both identified.

Risk measurement inevitably turns up a few surprises, and some might be scary or Aha! moments. But risk measurement almost always improves communication across departments. It can also help the whole company make better decisions about reducing uncertainty and achieving the company’s most important objectives.

---

Check out the first blog in this series, Measuring What Matters: Aligning Risk Measurement with Corporate Objectives.

Learn more about Tanium’s risk management solution.