The simplest view of the risk management process is that the six steps described previously supply information for a collection of risk lists. These various risk lists can be thought of as a database of risks affecting operations. The concept of a risk database is technology-independent; it could be as crude as a set of index cards, although that would make certain functions (such as sorting, searching, and linking) very labor-intensive and prone to error. The list can be implemented simply as a Microsoft Word document or a Microsoft Excel worksheet, or it can be more effectively implemented using a database application or Microsoft Project.

Note:

The size of the risk database is more an indicator of the IT group's thoroughness than an indicator of the health or stability of the IT infrastructure. Using a database application for this purpose should allow you to create customized views or queries into the stored risk information. Four suggested views are: the master risks list, the risks by services list, the top risks list, and the retired risks list. Understanding these views make the six steps for risk management easier to learn and understand.

To access an online example risk list, see Operations Templates.

The master risks list identifies the condition causing each risk, the potential adverse effect (consequence), outcome (frequently called the downstream effect), and the criterion or information used for ranking, such as probability, impact, and exposure. When sorted by the ranking criterion level (high-to-low), the master risks list provides a basis for assigning priorities in the planning process.

During each step in the risk management process, the process owners gather information about operational risks and add that information to the master risks list. It is a regularly updated, or "living," document that forms the basis for the ongoing risk management process and should be kept up-to-date throughout the cycle of risk analysis, planning, and monitoring. Each step in the risk management process builds on the previous step by adding more elements of the risk or draws on the current elements to support decision making. For example, the analyzing step initially adds information about a risk's impact and probability. The process is cyclic, so future passes through the analyzing step may review and revise those impact and probability estimates.

The master risks list is the fundamental document for supporting active or proactive risk management. It enables group decision-making by providing a basis for:

• Assigning priorities.
  
• Identifying critical actions.
  
• Highlighting dependencies.
  

The risks by services list is a useful view that allows operations to look at each risk where the consequences of that risk affect a specific business function or service, such as e-mail, customer relationship management (CRM), or payroll. By being able to easily and quickly link risks to their impact on end-to-end services provided by the IT infrastructure, the quality of information, prioritization, and decision making is improved.

Before a risks by services list can be created, it is recommended that IT operations produce a service catalog that lists all of the services currently being provided, a summary of their characteristics, and details of their users and those responsible for their ongoing maintenance.

Managing risk takes time and effort away from daily operations activities, so it is important for the operations staff to balance the overhead of risk management against the expected savings. This usually means identifying a small number of major risks that are most deserving of limited time and resources. One way to do this is to prioritize the master risks list. The risks at the top of the list, the ones that are important enough to be actively managed, make up a separate top risks list. The size of this list will vary among IT groups, and within one IT group it is likely to vary over time.

The master risks list holds all the risks that have been identified, whether or not they are important enough to appear on the top risks list. Some of those risks never go away, such as those related to natural disasters. Others reach a point where they are no longer relevant. For example, the probability of the risk might be reduced to zero, or the source of the risk may leave the environment. Risks specific to an outdated software application are no longer relevant after that application has been completely phased out.

Whenever a risk becomes irrelevant, it is moved from the master risks list to the retired risks list. This list serves as a historical reference from which others can draw on in the future. For example, when risks related to service desk processes are tracked and recorded, and the service desk function is outsourced to another company, some of the service desk risks might be retired. If the service desk function is later brought back in-house, the operations staff can refer to the retired risks list for guidance. Also, people may consult this list as a starting point for identifying new risks.

Finally, if IT operations reduces a risk's probability or impact to zero, then the notes about what was done may benefit other people facing similar risks.