It Risk Management Process for Itil® V3 & Itsm Environments

Dealing with risk is an important part of deploying new services in an IT service management (ITSM) environment. IT risk can occur in several areas during service delivery, including operational, legal, and financial risks.

Besides minimizing problems in service delivery, many government and regulatory agencies also routinely review organizational risk management policies and responses. Implementing and controlling risk in an ITSM environment is not only smart business; it can also be a regulatory requirement.

IT risk management is a continuous process that has its own lifecycle. Although experts differ on what steps are included in the process, a simple IT risk management process usually includes the elements shown in figure 1.

Step 1: Identification

Specific organizational risks should be identified whenever an item will be added to the service catalogue or when an existing service catalogue item is going to be modified. Risk identification ideally occurs in the Service Design phase or the Continual Service Improvement phase of the ITIL framework, where new services are defined and committed to.

There are several ways to identify risks in rolling out a new service catalogue feature, including:

• Brainstorming. Bring together all the stakeholders who have an interest in the successful implementation of the new service item and categorically review the risks that might be encountered when offering that item. Brainstorming sessions should include not only the IT department, but department heads, service desk personnel, and other supporting personnel involved with the proposed service.
• Organizational historical records. Risks for new service catalogue items may parallel risks for existing items. If you’re running an ITSM application such as BMC Helix ITSM, you can audit service tickets for items relating to services similar to what you’re planning to offer. Service tickets often contain a database of realized risks that may help you discover possible risks for new IT services.
• Internet search, blogs, forums, commercial products, and networking. Risks for new services can also be identified by searching the Internet for the proposed service type and its related problems. You may also find information about possible risks in blog posts, forums, commercial products discussing the service (especially e-books or seminars), or by networking with other organizations that have implemented similar services.

Risk identification should always include a description of the risk and the potential impact that will occur if the risk is realized. Potential impacts should be scored as to whether each risk carries a potential high, medium, or low impact on the business. Scoring impacts will help you decide what (if any) resources, you should allocate to addressing each risk.

(Try the impact, urgency, prioritization matrix.)

Step 2: Prioritizing risk

Probability of risk occurring and prioritizing risks: It’s important to determine the probability that a risk will occur as well as the importance of each risk. Probabilities can also be classified in simple terms such as a low, medium, or high probability.

Take, for example, a new service to provision cell phones where you may identify the following risks and their probabilities of occurring:

• Cell phone hardware doesn’t work = low probability. Cell phones don’t usually fail right out of the box, but it does occasionally happen.
• Mistake in configurations = medium probability. The user receives their new cell phone and a company app was not loaded on the phone or the phone is misconfigured, causing a return and reconfiguration.
• Damage to phone = high probability. The phone is damaged in shipment or the user does something stupid like dropping their phone in the toilet or placing it on the roof of their car and driving away, causing loss of phone and additional costs for replacement

Determining the probability of each risk occurring helps prioritize which risks you’ll need to develop response plans for (see next section) and the order in which each response plan should be developed.