Welcome to first in a series of posts covering foundational topics in IT risk assessment and management. As a risk analytics company, we are often asked by clients where to start, how to optimize their risk management approach, and what types of practices and considerations should go into risk management program planning and execution. This series will provide some common answers that will be helpful for launching and tuning your programs.
The phrase “Risk Assessment” has become a common part of our technical vernacular, yet it’s quite surprising how variable our understanding is of the phrase and what it actually means. In this post we will explore the concept of the risk assessment, where it fits within an overall risk management program, and how we will typically enter into the risk assessment process.
For starters, let’s address what is not a risk assessment. Quite simply, data collection, such as via a questionnaire, is not itself “risk assessment.” Rather, it’s the analysis and evaluation of all collected data, in context and aimed toward producing a statement on risk that is the core objective of a risk assessment. Simply posing questions to constituents, while potentially worthwhile, is not an act of analysis, and thus we must be very careful not to misconstrue the data collection as the “assessment” itself. This, alas, is a common mistake within organizations involved in IT risk management.
The Risk Management Process
A great starting point for a discussion of risk assessment is to first talk about the overall risk management program and process. (Figure 1) Aligning with the three core sub-processes within ISO 31000’s risk management process, we see that risk assessment is in fact the second step, not the first. Step 1 is to establish context within which we will conduct risk analysis, crucial to the determinations that will inform risk treatment decisions. Let’s drill down into these topics.
Context-setting is a critically important step, and one often overlooked. In setting context, we clearly define target and environment of the assessment: the technologies, the data, the stakeholders, the environment, and the business context (such as a business impact analysis and general rubric for risk tolerance, capacity, and/or appetite). It’s only after framing the context that we can effectively then drill down to the next level and conduct the assessment itself.
Risk Assessment is the step where we implement data collection and analysis in light of the information gathered during context-setting (including the definition of assessment target, risk and business context). We will have already determined what the purpose of the assessment is in terms of the type of decision(s) to be supported, and we should have a solid understanding of how the output should be structured in order to be useful for decision-makers. For example, simply producing a magically calculated aggregate number may not provide any value whatsoever if the purpose of the exercise is to determine whether or not a given environment is adequately secured against a defined threat actor.
Risk Treatment (or remediation)_is the final core sub-process within the risk management process. In this step we take the output of the risk assessment and discuss options with the business owners/stakeholders, such as whether or not the assessed risks are palatable to the business or if additional controls should be adopted to reduce the identified exposure levels. Again, the output of the risk assessment should be in a format that is natively understood by your target audience, and it should align well with the desired use case for the report (that is, it should be tailored to how the report is to be used).
Putting everything together, we find that it is indeed critical that information be gathered first in the context-setting stage before any sort of assessment is actually performed. If one were to rely just on the wording of many regulations and standards, then you might not realize that it’s important to understand where risk assessments fall within the overall risk management process. Getting these steps right will make life easier, as well as lead to much happier customers (the recipients of the assessment output).
What and When Should You Assess?
Now that we have a general understanding of the risk management process and where risk assessments fit overall, the next logical question is “well, when do we need to do these things anyway?” At first blush this may seem like an easy question to answer, but it turns out there isn’t typically just a single answer, there are two or three possible approaches.
You can perform an assessment of varying degrees as a contributing data point for just about any decision. In fact, we do this all the time in our personal lives, implicitly, and without any sort of formal framework. Why in IT we think this has to be overcomplicated is somewhat of a head-scratcher, but in reality there are ways in which we can rapidly collect data and perform analysis toward improving decision quality. The mere step of collecting or maintaining contextual information can make a world of difference in overall decision quality.
When thinking about what to assess and when to assess it, there are a few scoping questions to consider:
- Is this a periodic and/or recurring assessment or is it a one-time thing?
- Are you assessing a large portfolio or a specific target environment?
- What level of decision is being supported by the assessment (tactical/operational or strategic)?
These questions are important to understand because the type of assessment you conduct will need to vary in order to meet the needs defined in scoping. Consider these risk assessment scenarios:
- If conducting a risk assessment that is tactical in nature to determine whether or not an environment, as built/designed, is suitably secured (hardened) for production deployment as part of a defined and limited production timeline, you typically cannot afford to halt all work on the project while you spend a couple weeks collecting information, analyzing it, and considering a variety of threat scenarios. In this scenario you will be providing input for real-time decisions, primarily for a technical audience, as to whether or not suitable controls are in place.
- If conducting a risk assessment that is strategic in nature, looking at an entire portfolio of products or services (for example, a cardholder environment), then you almost certainly can afford (and will need) at least a couple weeks to collect and analyze data. In this scenario, your output should be quite different, looking for broader themes and patterns, and addressed to a higher-level business audience.
Getting engaged to perform a risk assessment can come through a variety of means and methods. At the most basic level, engagement may come through a simple conversation, email, or form-based request. Alternatively, certain types of assessments may be integrated into key processes – such as for procurement, project management, or M&A activities – to ensure that a proper risk assessment (that includes IT/information risk considerations) is performed, and early enough in the project to adequately account for IT or information risk. Lastly, it may also be appropriate to perform portfolio assessments on a regularly scheduled, recurring basis (such as quarterly or annually).
Ownership and Common Actors
The last topic we wish to highlight in this post is the role of people in the risk management and risk assessment processes. As has already been noted, the context-setting stage should capture important information prior to commencing the risk assessment itself. This information must include identifying the owner of the resultant assessment report (the person performing the work is rarely the owner in that risk analysts don’t general own the identified risk). Typically, the owner will be someone in management (either business or technical, depending on the scope of the assessment) who is charged with making a decision or recommendation. It is essential that the risk assessment output be tailored to their specific needs, including ensuring that the report is written in a manner that they can understand and use.
Beyond the risk owner, there will then often be the person performing the risk assessment (we’ll just refer to them as a the “risk analyst” here) and the other stakeholders and subject-matter experts who will help provide valuable inputs for context-setting.
The role of stakeholders and subject-matter experts is not to be understated. The worst thing the risk analyst can do is fail to seek out those people with a vested interest in the project or with specialized knowledge that is important for improving data quality and, by extension, decision quality. For example, IT professionals are notoriously bad at estimating business impact without the assistance of someone from the business. Think of all the IT and cybersecurity “sky is falling” moments trumpeted over the years only to fall flat in the face of reality. The simple fact is that, despite all the problems we see with IT and cybersecurity, businesses still manage to continue to exist and function. That alone is a testament to resiliency.
As such, it is very important not to rely on a single source for all or most of the data. Instead, find the people who truly know the answers (verifiably!) and get them involved in the process (early!).
At the end of the day, all of the considerations discussed within this post are critical to achieving success and demonstrating value. Knowing that risk assessment is not itself a starting point is key. Context is all-important. Good decisions cannot derive from poor assumptions or bad/non-existent data. Further, it’s imperative that the right people be involved and that the output of the risk assessment be properly tuned to the target audience. Tuning the output is also a key facet of context-setting, again highlighting the importance of not jumping into later phases too quickly. And, lastly, remember this motto as pertains to being engaged to perform a risk assessment: Semper Gumby! (always flexible). Work diligently to establish hooks into key processes, but resist the urge to make the risk assessment process so rigid and inflexible that people can only engage the risk analyst through a very narrowly defined set of circumstances. Every opportunity to have a risk management conversation should be welcomed. Creating friendly conditions for engagement and conversation are key to success, both today and in the future.
In future posts we will talk about how to leverage risk assessment standards, some of the key differences between – and considerations for – qualitative vs. quantitative risk assessment, and how to leverage platforms to improve the overall risk management program and process. The next post in this series will look at common risk assessment standards and how to best leverage them within risk management programs.