By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
IT security and risk professionals have historically had a hard time articulating how IT threats might negatively impact the business. That needs to change. Attacks on government sites, substantial fraud, and massive privacy breaches continue to expose to the world the high level of risk connected to our corporate and national IT infrastructure. Executives and managers will need to rely more on IT security data and analysis in order to better protect their corporate interests.Very few organizations have fully adopted risk management standards in any aspect of their business, and IT departments are no exception.
As internal and external pressure intensifies, IT professionals must adopt more sophisticated risk management practices so they can better articulate risks, mitigation plans and overall exposure. This means combining both security and risk mentalities, which can be difficult to translate into practical tools and processes.
Rather than start from scratch, security professionals should utilize the standards and guidance available in the enterprise risk management (ERM) domain. Forrester recently outlined the fundamental risk management processes that should be applied to IT risk management, based on the new, streamlined risk management standard from the International Organization for Standardization (ISO): ISO 31000. The following five steps provide guidance for building a formal, ISO 31000-based IT risk management program that communicates well with, and adds value to, the rest of the organization:
Step 1: Establish the context
This step may seem esoteric or even irrelevant, but without clear definitions, there will be organizational confusion and arguments over responsibilities later on. Begin by identifying individuals with risk experience (internally or externally) to help formalize tools and methods for identifying, measuring, and analyzing risk. Once formal roles have been established, risk professionals should document the IT organization's core objectives and define the ways in which IT risk management supports them.
Establishing risk appetites and tolerance during this first stage will help prioritize risk mitigation efforts later on. Conversations with risk management clients have indicated that most organizations initially choose to rank certain categories of risk for which they have less tolerance, rather than trying to develop quantifiable risk appetites. This is a good first step, but these organizations will eventually need more granular criteria to make informed decisions about which specific risks to focus on.
Step 2: Identify the risks
Risk managers will need to tap into their creativity to create a comprehensive list of potential risks. Risks not identified at this stage will not be analyzed or evaluated later on, so having an overly exhaustive list is preferable to one that is overly limited. Start by conducting workshops with relevant stakeholders, identifying the broad range of issues that could impair their objectives, processes and assets.
Forrester clients that have been using IT control frameworks, such as Control Objectives for Information and related Technology (COBIT) or ISO 27002, often find them to be useful guides for categorizing their risks. Note that risks should be specific to your organization, not a generic list. Plan to reexamine your full list of risks at least on an annual basis to identify any new or emerging risks.
Step 3: Analyze the risks
Security professionals typically have a good understanding of events and issues that might undermine IT processes; however, it's often harder for them to determine what the impact will be to the IT department or the organization as a whole. Work closely with business stakeholders to understand criticality and impact. It may even be possible to leverage the business impact analysis work done by the business continuity team to fill in some of the gaps.
Many organizations have found it helpful to create a scale by which to approximate the level of likelihood and impact. For example, some companies create a matrix to measure the likelihood of risks based on characteristics such as exposure or attractiveness of target, and impact based on characteristics such as potential financial costs or reputation damage. The result is a "heat map" that helps prioritize mitigation efforts on the set of risks with the highest combined likelihood and impact ratings.
Step 4: Evaluate the risks
Levels of risk after controls have been accounted for (i.e., residual risk) that fall outside of the organization's risk tolerance will require treatment decisions. The risk appetite and thresholds previously defined will provide guidelines for when to avoid, accept, share, transfer, or mitigate risks. The decisions themselves should be made by individuals who are granted authority or accountability to manage each risk, with input from others who may be positively or negatively affected.
For some risks, the initial analysis may only allow you to determine that your exposure is potentially high enough to warrant further investigation. Make sure to conduct further analysis when necessary.
Step 5: Treat the risks
If the treatment decision involves the mitigation of risk, organizations need to design and implement controls to reduce threats to the organization's achievement of objectives. Many risks will require more than one control (i.e. policies, training, prevention measures, etc.) to decrease their expected likelihood and/or impact. Conversely, some controls may mitigate more than one risk. It's a good idea to consider multiple reevaluations during implementation.
Look out for peripheral effects caused by risk treatments that introduce new risks and/or opportunities. For example, the decision to transfer risk to a business partner may increase risk of that partner becoming disloyal.
Very few organizations have fully adopted risk management standards in any aspect of their business, and IT departments are no exception. Forrester recommends providing common guidance for all risk groups, collaborating with peers in functions such as audit and compliance, and settling on policies and procedures before turning to risk management technologies. These steps should help IT risk management programs improve their ability to work closely with the business and achieve a level of commitment in line with the level of risk they're expected to address.
About the author:
Chris McClean is an analyst with Cambridge, Mass.-based Forrester Research Inc. He contributes to Forrester's offerings for the security & risk professional, leading the company's coverage of governance, risk, and compliance (GRC). He is also a thought leader on the related issues of corporate social responsibility (CSR) and sustainability. He is a frequent speaker on these subjects at vendor events as well as conferences run by industry organizations such as the Risk Management Association.