What is Risk Management?
Risk Management can be defined as the process involving measurement and assessment of risk, and development of strategies to curb and manage such identified risks.
The major strategies to manage risk are usually related to transfer of the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk.
Table of Contents
- 1 What is Risk Management?
- 2 Risk Management Process
- 3 Implementation Review and Evaluation of the Plan
- 4 Practical Actions for Business Managers
Risk management may include assessment and management of risks which have origins in physical or legal causes such as natural disasters or fires, accidents, death,or lawsuits, or may be related to financial aspects.
Business managers are used to recognizing commercial threats and taking appropriate actions – for example, dealing with a new customer who turns out to be a late payer. However, threats associated with the IT used in a business are much newer, a lot less predictable and change much faster.
A useful way of recognising threats is to classify them as follows:
- Physical threats are those that result from physical access or damage to information resources such as servers, network equipment, computer rooms, etc. In some business environments, it is easy to overlook these types of threat. However, if an unauthorised person – employee or not – can enter your computer room unobserved, then all your other IT security measures are essentially redundant.
- Logical threats are those that aim to compromise your business information – and typically come from outside your premises/network, e.g. a hacker accessing your network via your website.
- Technical failure is a common threat to IT systems. For example, if key data is stored only on the hard disk of one server then the failure of that hard disk would be catastrophic. Hard disks in computers will fail eventually, even inexpensive servers.
- Infrastructure failure can be a subtle form of threat. For example, if your business relies on your Internet connection to receive orders from customers, you could miss out on new purchase orders if that connection fails.
- Human error is a major threat. If an honest mistake by a user or system manager could cause an irrevocable loss of data, you need to take action to prevent it from happening.
Regardless of the type of risk management, all sizable organizations usually have specific profiles and process for management of risk– either formally or informally.
Information systems and its resources face multiple sort of risks which again may have multiple origins. Further, the probability of occurrence of all these risks are not equal and neither is their severity of impact.
In practice, this process can be very difficult as balancing the trade-off between types of risks as well as probability of their occurrence and severity of their impact may turn out to be subjective and very difficult.
Another major challenge faced in management of risk is the difficulty in allocating resources properly. The investment on managing risk is usually not much appreciated till the occurrence of a risky event. Further, there may be arguments that the expenditure done on risk management could be instead spent on more productive and profitable activities.
Risk Management Process
Risk management should be seen as an ongoing process, rather than a one-off procedure that is applied to an individual threat. Risk management should also include continuous reassessment of existing threats while actively search for newer ones.
Risk management involves a structured way of controlling risk. There are various ways in which this can be done.
Following is a brief discussion of the usual steps outlined a typical risk management process:
- Identify risk: The foremost activity in management of risk is be able to identify potential threats. This allows for proactive actions in anticipation of the threat, which is better than reacting to a situation where the threat has actually occurred.
- Risk assessment: Though there might be a plethora of risks that an information system may be exposed to, it is not important to treat all of them equally. The firm may not need to invest time and money in reducing all sort of risks, but it may well need to take a measured approach based on an assessment of the importance of the risk to its business.
A risk may warrant actions only if it possesses a serious enough threat to the information system.Some risks, usually low in impact and/or probability of occurrence, may not warrant any action.
- Risk Treatment: There can be multiple strategies to treat risk threats. With many risks the enterprise can implement preventative measures that will significantly reduce the probability of the risk occurring (risk mitigation).
On the other hand, it may not be possible for an enterprise to reduce the probability of occurrence of risks to an acceptable level. Treatment of such risks focusses more on reducing their negative consequences should it actually affect the information system.
- Contingency planning: Organizations usually draw up plans for how to act and respond in case a particular risk threat has occurred. Contingency plans are what the organizations fall to after the worst has happened. A particularly important form of a contingency plan is a disaster recovery plan.
A first step in the process of managing risk is to identify potential risks. Risks are about events that, when triggered, might adversely impact the performance of information system or might lead to loss, misuse, fraud, misrepresentation, destruction, modification or denial of data and other information processing resources that may cause financial or operational hardships.
To manage risks effectively you have to be able to identify potential threats. The objective of risk identification is early and continuous identification of events that pose a threat to the information system. Risk identification starts with an analysis of the source of problems, or with problem itself.
The origin of the sources of the risk may be located with the information system or might be external to it. There are multiple types of risk assessments that can be done, including program risk assessments, risk assessments to support decisions, analysis of alternatives, and assessments of operational or cost uncertainty.
Risk identification needs to match the type of assessment required to support risk-informed decision making. For an information system, the first step is to identify its goals and objectives, which can serve to develop a common understanding across the enterprise of what is needed for its success. This provides the risk identification process a context and scope.
Some of the common methods of identification of risks are:
- Objectives-Based Risk Identification: Organizations and project teams have objectives. Any event that may endanger achieving an objective partly or completely is identified as risk.
- Scenario-Based Risk Identification: In scenario analysis different scenarios are created. The scenarios may be the alternative ways to achieve an objective, or an analysis of the interaction of forces in, for example, a market or battle. Any event that triggers an undesired scenario alternative is identified as risk.
- Taxonomy-Based Risk Identification: The taxonomy in taxonomy-based risk identification is a breakdown of possible risk sources. Based on the taxonomy and knowledge of best practices, a questionnaire is compiled. The answers to the questions reveal risks.
- Common-Risk Checking: In several industries lists with known risks are available. Each risk in the list can be checked for application to a particular situation. An example of known risks in the software industry is the Common Vulnerability and Exposures list found at http://cve.mitre.org.
In practice the risk identification process is easier said than done.
Some practical tips to identify risk can be:
- A good starting point for identifying risk is information or system risk/security surveys routinely conducted by many industry bodies or specialist agencies. These are usually published at a regular interval of time and contain an excellent analysis of the risks that could affect both large and small businesses – in general or may be specific to a particular industry.
- There are good resources online, which are updated more frequently. Though generic in nature, these can be usedto identify the potential risk that your information system may be exposed to.
- Another technique that can help you to identify threats is a what-if analysis. This works better in a small group using a brainstorming approach.
- Start with simple questions and scenarios to see if they can help to identify new risks. For example, ask questions such as “what if the telephone line to the building got cut with adigger?”, or “what if the same happened to our power?”, and see what plans may be needed oralready have in place to cope with these eventualities.
- Another important step in identifying risks is to write them down in a risk register as each of the risk is assessed. Typically, these risk registers contain a description of risk and the probability of the risk occurring. It may also contain responses and course of actions to be followed in case the risk event actually takes place. The risk registers can also serve as a checklist when risks are reviewed periodically.
The next step after identification of risks is to assess them for the probability of their occurrence and their potential severity of impact on the information system. These quantities can be either simple to measure, in the case of the value of a lost computer, or impossible to know for sure in the case of the probability of an unlikely event occurring.
Therefore, in the assessment process it is critical to make the best-educated guesses possible in order to properly prioritize the implementation of the risk management plan. Care should be taken when assessing the risks that the information system may face, organizations would not want to spend time and money avoiding or reducing those risks that pose little or no threat to their business.
Once risk have been identified that do actually pose a threat to the business, it may be helpful to base the risk assessment on the following factors:
- The probability or likelihood of each risk materializing
- The cost or impact of the problem if it did happen
A quantitative assessment of the risks would be the numerical product of these two factors.
For example, if a risk has a high probability and a high cost/impact then it will get a high riskassessment. Unfortunately, quantitative measures of risk like this are only meaningful when suitable data is present.
Organizations may not have the necessary historical data to work out such probabilities, and costestimates as information system related risks change so fast that accurate financial data is rarely available.
Therefore, a more practical approach is to use a qualitative assessment. In this case experts or system users use their judgement to decide whether the probability of occurrence is high, medium or low and similarly for cost/impact. The risk identified and thus assessed can be prioritized accordingly.
The severity of impact may be defined for example as:
- Low: would lose up to half an hour of production
- Medium: would cause complete shutdown for at least three days
- High: would cause irrevocable loss to the business
Using the same principles for the probability of occurrence, the risks may be defined as:
- High probability: something that you expect to happen several times a year.
- Low probability: something that you expect to happen very infrequently.
If the risk assessment exercise indicates unacceptably high levels of risks to the information system or business processes related to it, then some action to counter such threats need to be taken. This would usually call for efforts which may fall in either of following strategies:
- Avoidance of the risk
- Reduction in the probability of the risk affecting the information system
- Limit the impact of the risk if the risk situation actually take place
- Transfer of the risk to a third party
It is, however, very much possible that the enterprise may not be able to apply these strategies as it may involve certain trade-offs that may not be acceptable to all stakeholders of the information system.
One way of doing this is risk avoidance, i.e. avoiding doing the things that could lead to a problem occurring, such as not upgrading to application software, because it carries a risk.
However, this might mean that the enterprise might end up not doing anything new, and hence not being able to benefit fully from business opportunities. Enterprises can instead take a more positive approach by changing the way inwhich they carry out an activity. This is quite appropriate to IT-related risk, and usually involves adopting a best practice approach to acquiring or operating IT systems.
It has been traditional business wisdom and practice to be proactive and try to reduce the probability of the risk affecting the information system in the first place. This involves methods that reduce the severity of the loss.
Examples include sprinklers designed to put out a fire to reduce the risk of loss by fire. However, the risk reduction methods may be chosen only after careful considerations. The above method for reducing risk by accidental fire may actually cause a greater loss by water damage is not installed after due planning and proper positioning.
Such a water-based system may actually not be suitable at all. Alternative systems such as Halon fire suppression systems may be better to mitigate such a risk, but the cost may be prohibitive as a strategy.
On software front, for example, modern software development methodologies reduce risk by developing and delivering software incrementally. Early methodologies suffered from the fact that they only delivered software in the final phaseof development.
Any problems encountered in earlier phases meant costly rework and often jeopardized the whole project. By developing in increments, information system projects can limit effort wasted to a single increment.
There are inevitably some risks to the information systems that can neither be eliminate nor reduced to an acceptable level. For such sort of risk threats, enterprises can only mitigate them by assessing what might happen as a result of the problem and reducing their impact should they occur.
The last strategy to manage risk refers to transfer of the risk to a third party. This means causing another party to accept the risk, typically by contract or by hedging. Insurance is one type of risk transfer that uses contracts.
Other times it may involve contract language that transfers arisk to another party without the payment of an insurance premium. Liability among construction or other contractors is very often transferred this way.
On the other hand, taking offsetting positions in derivatives is typically how firms use hedging to financial risk management: financially managed risk. Sometimes risk transfer clauses can be written into the contracts for deals involving and using information systems. IT risk are, however, difficult or very costly to transfer effectively.
After the risks have identified and assessed, and their treatment identified, the same has be operationalized into a plan. A contingency plan is one of such measure which describe in detail what is to be done and by whom it is to be done, if a particular problem occurs.
Contingency plans are typically developed for situations when:
- The probability of occurrence of an identified risk and severity of its impact is high
- The risks associated cannot be reduced to acceptable levels,
- The residual risk is still so large enough that a structured approach to reduce its likely impact is needed
A typical contingency plan includes:
- Scope: what particular risk the contingency plan is designed for
- Initiation: how you will know when to put the plan into action
- Actions: what sequence of actions you will take in order to control the problem and minimise its impact
- Roles and responsibilities: who will do what and when
Good contingency plans are usually based on the shared experience of managers working together. An important form of contingency plan is a business continuity plan (BCP). This is typically created to cover the most serious of problems, such as the complete loss of all your servers and network infrastructure due to a fire.
Such plans may involve planning for the rapid acquisition of temporary buildings, reciprocal arrangements with other organisations, special staffing arrangements etc.
Implementation Review and Evaluation of the Plan
Follow all of the planned methods for mitigating the effect of the risks. Purchase insurance policies for the risks that have been decided to be transferred to an insurer, avoid all risks that can be avoided without sacrificing the entity’s goals, reduce others, and retain the rest. Initial risk management plans will never be perfect.
Practice, experience, and actual loss results, will necessitate changes in the plan and contribute information to allow possible different decisions to be madein dealing with the risks being faced.
Practical Actions for Business Managers
Risk management is relatively straightforward if you follow some basic principles. Below are some practical hints that you may find useful.
- Actively look for information system-related risks that could impact upon business. If possible, use a small team to identify possible risks. A workshop environment will help to think more imaginatively about risks than working alone.
- Assess information system-related risks using either a quantitative or qualitative approach. This will allow to concentrate on those risks that are really important and not waste time on those that are not. How to actually measure the risk is less important than the activity itself, which aims to help review risks rationally.
- Do not produce contingency plans for every risk that is identified. This is a waste of time and effort. Concentrate on those problems that would have a serious impact, and where there are less chances for reduction in the probability of them happening to an acceptable level.
- A business continuity plan (BCP) is must cover any serious information system-related risks that could jeopardise the business and which cannot be fully controlled.
- Risk management is a continuous process. The risk register are required to be updated regularly to cover all new information system-related risks that arise over a period of time. Similarly, if BCP is not revised or tested for a while, it may have become out of date. A frequent and periodic review of these is needed.
- Even very small businesses need to review information system-related risks. The time taken need only be small, but it gives important assurance.