Risk Assessment and Treatment:

Risk Management

Risk management is the process of measuring, or assessing, risk and developing strategies to manage it. Strategies include transferring 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. Traditional risk management focuses on risks stemming from physical or legal causes (e.g. natural disasters or fires, accidents, death, and lawsuits).

Streamlined Explanation

An article written by [Michael D. Peters] was published in August 2012 provides an accessible approach to IT security risk management and may be found here: Risky Business: IT Security Risk Management Demystified

Explanation

In ideal risk management, a prioritizing process is followed whereby the risks with the greatest loss and the greatest probability of occurring are handled first, and risks with lower probability of occurrence and lower loss are handled later. In practice the process can be very difficult, and balancing between risks with a high probability of occurrence but lower loss vs. a risk with high loss but lower probability of occurrence can often be mishandled.

Intangible risk management identifies a new type of risk (A risk that has a 100% probability of occurring but is ignored by the organization due to a lack of identification ability). For example, knowledge risk occurs when deficient knowledge is applied. Relationship risk occurs when collaboration ineffectiveness occurs. Process-engagement risk occurs when operational ineffectiveness occurs. These risks directly reduce the productivity of knowledge workers, decrease cost effectiveness, profitability, service, quality, reputation, brand value, and earnings quality. Intangible risk management allows risk management to create immediate value from the identification and reduction of risks that reduce productivity.

Risk management also faces difficulties allocating resources. This is the idea of opportunity cost. Resources spent on risk management could have been spent on more profitable activities. Again, ideal risk management minimizes spending while maximizing the reduction of the negative effects of risks.

GLBA risk assessments should cover all IT risk management functions including security, outsourcing, and business continuity. Senior management should ensure IT-related risk identification and assessment efforts at the enterprise-wide level are coordinated and consistent throughout the organization. A strong, high-level, risk assessment process provides the foundation for more detailed assessments within the functional risk management areas. An effective IT risk assessment process will improve policy and internal controls decisions across the organization.

Senior management can use risk assessment data to make informed risk management decisions based on a full understanding of the operational risks. Small institutions with less complex systems may have a more simplified risk assessment process. Regardless of the complexity, the process should be formal and should adapt to changes in the IT environment. Examiners should measure the effectiveness of the process by evaluating management’s understanding and awareness of risk, the adequacy of formal risk assessments, and the effectiveness of the resulting policies and internal controls.

Consider these four points to successfully manage risk in your organization:

Availability of systems and processes. Keeping them up and running is critical to the business.
Access to IT and business systems. Whether you're a local business or a global organization, it is very important to manage and limit access to your systems. This includes access for your employees, partners and even customers.
Accuracy counts. What you present as part of your company profile, financial information and data should accurately represent a single, uniform view to your customer and the public. Compliance now provides legal ramifications for those public companies not accurately representing data and company information.
Agility in the enterprise. It's important for the IT organization to be agile and timely when it comes to changing systems and processes to meet the needs of the business.

Steps in the Risk Management Process

Establish the Context

Establishing the context involves:

Planning the remainder of the process.
Mapping out the scope of the exercise, the identity and objectives of stakeholders, and the basis upon which risks will be evaluated.
Defining a framework for the process and an agenda for identification.
Developing an analysis of risk involved in the process.

Identification and Ongoing Data Collection

Understanding the institution's environment is the first step in any risk assessment process. Senior management should incorporate information on IT issues such as resource limitations, threats, priorities, and key controls from several sources.

In developing a formal risk assessment, management should collect and compile information regarding the organization’s information technology environment from several locations including:

IT systems inventories are critical to understanding and monitoring the tactical operations of the institution’s information technology as well as to identifying the access and storage points for confidential customer and corporate information.
IT strategic plans provide insight into the organization’s planning process. Review and analysis of the strategic plans as part of the risk assessment process may spotlight developing risk exposures or other deficiencies that limit the institution’s ability to implement strategic priorities.
Business recovery and continuity plans prioritize the availability of various business lines to the institution and often encompass restoration and provision of control, customer service, and support. The plans can offer insight into the organization’s critical operating systems and the control environment.
Due diligence and monitoring of service providers can present valuable information on the servicer control environment. The information is necessary for a complete risk assessment of institution’s information technology environment.
Call center issue tracking reports can often indicate potential performance or control issues if the problem reports are aggregated and analyzed for repetitive or common issues.
Department self-assessments on IT-related controls can provide early identification of policy noncompliance or weaknesses in controls.
IT audit findings provide insight into the veracity and responsiveness of the institution’s staff and management, commitment to policy compliance and internal controls.

After establishing the context, the next step in the process of managing risk is to identify potential risks. Risks are about events that, when triggered, cause problems. Hence, risk identification can start with the source of problems, or with the problem itself.

Source analysis Risk sources may be internal or external to the system that is the target of risk management. Examples of risk sources are: stakeholders of a project, employees of a company or the weather over an airport.
Problem analysis Risks are related to identified threats. For example: the threat of losing money, the threat of abuse of privacy information or the threat of accidents and casualties. The threats may exist with various entities, most important with shareholder, customers and legislative bodies such as the government.

When either source or problem is known, the events that a source may trigger or the events that can lead to a problem can be investigated. For example: stakeholders withdrawing during a project may endanger funding of the project; privacy information may be stolen by employees even within a closed network; lightning striking a Boeing 747 during takeoff may make all people on-board immediate casualties.

The chosen method of identifying risks may depend on culture, industry practice and compliance. The identification methods are formed by templates or the development of templates for identifying source, problem or event. Common risk identification methods 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. Objective-based risk identification is at the basis of COSO's Enterprise Risk Management - Integrated Framework
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.
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. Taxonomy-based risk identification in software industry can be found in CMU/SEI-93-TR-6.
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.

Environmental Survey

To effectively identify, assess, monitor, and manage the risks associated with IT operations, management should have a comprehensive understanding of the institution’s operations universe. Technology is increasingly embedded in business lines, in functional support areas, at the physical location of a business partner or affiliate, or at multiple data centers. An environmental survey allows the institution to gain an enterprise-level view by documenting resources, physical locations, hardware and software configurations, and interfaces and interdependencies. The survey should track the capture, processing, flow, and storage of data throughout the institution. As an integral part of the environmental survey, management should perform and maintain an inventory of information technology assets.

With a comprehensive understanding of the institution’s technology environment, management can promote resource allocation, appropriate capital expenditures, and adequate support for business activities, customer service, and product delivery. More narrowly, this understanding will facilitate cost control, configuration and standards management, root cause and problem analysis, prevention of loss or misuse of corporate resources, and license management. Management will also be able to control the purchasing process and prevent the introduction of unauthorized software and hardware. A thorough environmental survey and inventory also serve as the foundation for managing and monitoring daily operations. The survey and inventory provide information vital to the assessment of other important control processes such as information security, business continuity planning, and outsourcing risk management.

Management should ensure documentation of the technology environment is current, appropriate to the size and complexity of the institution, and prioritized based upon the criticality of the function supported and the location of equipment. Regardless of institution size, management should possess a basic inventory of resources as well as a topology or network map. For large, complex institutions, documentation should provide an overview with sufficient detail describing subordinate processes and systems. As an alternative to detailed documentation, there are also network management tools available to create a database or an electronic repository of inventory and topology information. Smaller and less complex institutions may be able to operate with less detailed or sophisticated documentation, but should nonetheless be responsible for understanding the inventory and topology of their IT environment. As the size and complexity of the institution increases, documentation should expand to include business processes and data flow maps. Management should ensure the survey and inventory are updated on an on-going basis to reflect the institution’s technology environment at any point in time.

Technology Inventory

Hardware

The hardware inventory should be comprehensive. In addition to identifying institution-owned assets, it should also identify equipment owned by other parties but located within the environment. To the extent possible, hardware items should be marked with a unique identifier, such as a bar code, tamper-proof tag, or other label.

The inventory should encompass stand-alone computing devices, including:

Environmental control terminals
Physical access control systems
Service-provider-owned equipment, such as automated teller machine (ATM) administrative terminals
Terminals
Bank customer-owned equipment
Vendor-owned equipment
Personal computers (PCs)
Mainframes
Servers

The following are examples of useful information to capture in hardware inventories:

Mainframe, midrange or server

Vendor and model
Processor capacity in million instructions per second (MIPS)
Core or main memory
Storage (internal and external tapes, tape silos, direct access storage device (DASD), etc.)
Function
Location

Desktop or stand-alone computing devices

Vendor and model
Owner and purpose
Network connectivity (not applicable to stand-alone)
Dial-out capability
Location

Network devices

Vendor and model
Type
Native storage (random access memory)
Internet protocol (IP) address

Item processing equipment

Vendor and model
Type

Inventories of telecommunication equipment should contain similar information and should document use and connectivity. This is especially important when an institution uses either private branch exchanges (PBX) or voice over Internet protocol (VOIP) to provide voice and data connectivity.

Inventories of telecommunications interconnections should include the following information:

Number and configuration of trunks
Circuit numbers
Entry points to the premises
Central office connectivity
Types of service supplied, including

POTS – plain old telephone service
SONET – synchronous optical network
ISDN – integrated services digital network
Frame relay
Wireless

Software

There are at least three major categories of software institutions should include in the software inventory: operating systems, application software, and back-office and environmental applications. Application software includes core processing applications, as well as desktop and workstation office productivity software. Back-office and environmental software consists of applications that reside above the operating system and that support primary applications. Examples of back office and environmental software include database engines, back-up and storage management software, Internet servers and application support software, file transmission systems, system performance monitoring applications, scheduling and change control systems, utilities, front-end processors (for mainframes only), and problem and issue tracking software.

The following provides examples of information to capture in software inventories:

Type or application name (e.g. general ledger, payroll)

Manufacturer or vendor
Serial number
Version level
Patch level
Number of copies installed
Number of licenses owned
Types of licenses owned (e.g. site, individual)

Network Components And Topology

The institution’s network infrastructure is critical to all facets of business operations. Voice and data communication networks form the backbone for information sharing and data transfer and facilitate tight integration of technology systems. In addition to maintaining a complete inventory of hardware and software connected to and operating on the network, management should also fully document the network configuration.

Depending on the size and complexity of the institution’s network, management should develop and maintain high-level topologies that depict wide area networks (WANs), metropolitan area networks (MANs), and local area networks (LANs).

The topologies should have sufficient detail to:

Facilitate network maintenance and troubleshooting
Facilitate recovery in the event of a disruption
Plan for expansion, reconfiguration, or addition of new technology

Topologies should also:

Identify all internal and external connectivity (including Internet and modems)
Describe the type of connectivity (digital subscriber line (DSL), dial-up, cable modem, wireless)
Note the bandwidth of connectivity within and between network segments
Identify and describe encrypted or otherwise secure communication channels
Depict the type and capacity of network segment linkages (switches, routers, hubs, gateways, etc.)
Portray information security systems (firewalls, intrusion detection systems, and hacker-trapping “honey pots”)
Identify primary vendors of telecommunications services
Identify what information is available and where it resides

The network topology should be a technical blueprint of the network structure. Management should collect other important network documentation. Institutions should identify and document the type, location, and volume of information stored and transmitted on their networks. Management should develop a complete description of all network management tools and network administration console capability.

Management should also develop data flow diagrams to supplement its understanding of information flow within and between network segments as well as across the institution’s perimeter to external parties.

Data flow diagrams should identify:

Data sets and subsets shared between systems
Applications sharing data
Classification of data (public, private, confidential, or other) being transmitted

Data flow diagrams are also useful for identifying the volume and type of data stored on various media. In addition, the diagrams should identify and differentiate between data in electronic format, and in other media, such as hard copy or optical images.

Media

Documentation of storage media should complement network topologies and hardware and software inventories without being redundant. Descriptive information should identify the type, capacity, and location of the media. It should also identify the location, type, and classification (public, private, confidential, or other) of data stored on the media. Additionally, management should document source systems, data ownership, back up frequency and methodology (tape, remote disk, compact disk (CD), or other), and the location of back-up media if other than at the primary off-site storage facility.

Assessment and Analysis

Management should use the data collected on IT assets and risks to analyze the potential impact of the risks on the institution. The analysis should identify various events or threats that could negatively affect the institution strategically or operationally. Management should evaluate the likelihood of various events and rank the possible impact.

Once risks have been identified, they must then be assessed as to their potential severity of loss and to the probability of occurrence. These quantities can be either simple to measure, in the case of the value of a lost building, 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.

Some examples of events that could affect the institution include the following:

Security breaches - Security breaches that can affect the institution include external and internal security breaches, programming fraud, computer viruses, or denial of service attacks.
System failures - Common causes of system failures include network failure, interdependency risk, interface failure, hardware failure, software failure, or internal telecommunication failure.
External events - Institutions are also exposed to external threats including weather-related events, earthquakes, terrorism, cyber attacks, cut utility lines or wide spread power outages that bring about system or facility failures.
Technology investment mistakes - Mistakes in technology investment including strategic platform or supplier risk, inappropriate definition of business requirements, incompatibility with existing systems, or obsolescence of software may constrain profitability or growth.
Systems development and implementation problems - Common system development and implementation problems include inadequate project management, cost and or time overruns, programming errors (internal/external), failure to integrate and/or migrate successfully from existing systems, or failure of system to meet business requirements.
Capacity shortages - Shortages in capacity result from lack of adequate capacity planning, including the lack of accurate forecasts of growth.

Once the institution has identified the universe of risks, management should estimate the probability of occurrence as well as the financial, reputation, or other impact to the organization. Organizational impacts are highly variable and not always easy to quantify, but include such considerations as lost revenue, flawed business decisions, data recovery and reconstruction expense, costs of litigation and potential judgments, loss of market share, and increases to premiums or denials of insurance coverage. Typically, risk analysis ranks the results based on the relationship between cost and probability.

Prioritization

Prioritizing Risk Mitigation Efforts Once an institution identifies and analyzes the universe of risks, management should prioritize risk mitigation actions based on the probability of occurrence and the financial, reputational or legal impact to the institution. Organizational impacts are variable and not always easy to quantify, but include such considerations as lost revenue, loss of market share, increased cost of insurance premiums, litigation and adverse judgment costs, and data recovery and reconstruction expense. Management should prioritize the risk assessment results based on the business importance of the associated systems. The probability of occurrence and magnitude of impact provide the foundation for establishing or expanding controls for safe, sound, and efficient operations appropriate to the risk tolerance of the organization.

The overall risk assessment results should be a major factor in decision making in most IT management responsibility areas including:

Technology budgeting, investment, and deployment decisions
Contingency planning
Policies and procedures
Internal controls
Staffing and expertise
Insurance
IT performance benchmarks
Service levels for internal and outsourced IT services
Policy enforcement and compliance

Risk Scoring System

A successful risk-based IT audit program can be based on an effective scoring system. In establishing a scoring system, the board of directors and management should ensure the system is understandable, considers all relevant risk factors, and, to the extent possible, avoids subjectivity.

Major risk factors commonly used in scoring systems include the following:

The adequacy of internal controls
The nature of transactions (for example, the number and dollar volumes and the complexity)
The age of the system or application
The nature of the operating environment (for example, changes in volume, degree of system and reporting centralization, sensitivity of resident or processed data, the impact on critical business processes, potential financial impact, planned conversions, and economic and regulatory environment)
The physical and logical security of information, equipment, and premises
The adequacy of operating management oversight and monitoring
Previous regulatory and audit results and management’s responsiveness in addressing issues
Human resources, including the experience of management and staff, turnover, technical competence, management’s succession plan, and the degree of delegation
Senior management oversight

Auditors should develop written guidelines on the use of risk assessment tools and risk factors and review these guidelines with the audit committee or the board of directors. The sophistication and formality of guidelines will vary for individual institutions depending on their size, complexity, scope of activities, geographic diversity, and various technologies used. The institution can rely on standard industry practice or on its own experiences to define risk scoring. Auditors should use the guidelines to grade or assess major risk areas and to define the range of scores or assessments (e.g., groupings such as low, medium, and high risk or a numerical sequence such as 1 through 5).

Consider using color coded icons for illustrative purposes such as:

No Risk.

Low Risk.

Medium Risk.

High Risk.

NA.

The written risk assessment guidelines should specify the following elements:

A maximum length for audit cycles based on the risk scores. (For example, some institutions set audit cycles at 12 months or less for high-risk areas, 24 months or less for medium-risk areas, and up to 36 months for low-risk areas. Audit cycles should not be open-ended.)
The timing of risk assessments for each department or activity. (Normally risks are assessed annually, but more frequent assessments may be needed if the institution experiences rapid growth or significant change in operation or activities.)
Documentation requirements to support scoring decisions
Guidelines for overriding risk assessments in special cases and the circumstances under which they can be overridden. (For example, the guidelines should define who can override assessments, and how the override is approved, reported and documented.)

Numerous industry groups offer resources where institutions can obtain matrices, models, or additional information on risk assessments. Among these groups are: ISACA, American Bankers Association (ABA), American Institute of Certified Public Accountants (AICPA), and IIA. Day-to-day management of the risk-based audit program rests with the internal audit manager, who monitors the audit scope and risk assessments to ensure that audit coverage remains adequate. The internal audit manager also prepares reports showing the risk rating, planned scope, and audit cycle for each area. The audit manager should confirm the risk assessment system’s reliability at least annually or whenever significant changes occur within a department or function. Operating department managers and auditors should work together in evaluating the risk in all departments and functions by reviewing risk assessments to determine their reasonableness.

Auditors should periodically review the results of internal control processes and analyze financial or operational data for any impact on a risk assessment or scoring. Accordingly, operating management should be required to keep auditors up to date on all major changes in departments or functions, such as the introduction of a new product, implementation of a new system, application conversions, or significant changes in organization or staff.

The fundamental difficulty in risk assessment is determining the rate of occurrence since statistical information is not available on all kinds of past incidents. Furthermore, evaluating the severity of the consequences (impact) is often quite difficult for immaterial assets. Asset valuation is another question that needs to be addressed. Thus, best educated opinions and available statistics are the primary sources of information. Nevertheless, risk assessment should produce such information for the management of the organization that the primary risks are easy to understand and that the risk management decisions may be prioritized. Thus, there have been several theories and attempts to quantify risks.

HORSE FACTS: Numerous different risk formula exist, but perhaps the most widely accepted formula for risk quantification is: (Rate of occurrence multiplied by the impact of the event equals risk)

Later research has shown that the financial benefits of risk management are less dependent on the formula used but are more dependent on the frequency and how a risk assessment is performed.

In business it is imperative to be able to present the findings of risk assessments in financial terms.

Potential Risk Treatments

Once risks have been identified and assessed, all techniques to manage the risk fall into one or more of these four major categories:

Tolerate (aka retention)
Treat (aka mitigation)
Terminate (aka elimination)
Transfer (aka buying insurance)

HORSE FACTS: Remember as 4 T's!

Ideal use of these strategies may not be possible. Some of them may involve trade-offs that are not acceptable to the organization or person making the risk management decisions.

Risk Avoidance

Includes not performing an activity that could carry risk. An example would be not buying a property or business in order to not take on the liability that comes with it. Another would be not flying in order to not take the risk that the airplane were to be hijacked. Avoidance may seem the answer to all risks, but avoiding risks also means losing out on the potential gain that accepting (retaining) the risk may have allowed. Not entering a business to avoid the risk of loss also avoids the possibility of earning profits.

Risk Reduction

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. This method may cause a greater loss by water damage and therefore may not be suitable. Halon fire suppression systems may mitigate that risk, but the cost may be prohibitive as a strategy.

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 phase of development; any problems encountered in earlier phases meant costly rework and often jeopardized the whole project. By developing in iterations, software projects can limit effort wasted to a single iteration.

Risk Retention

Involves accepting the loss when it occurs. True self insurance falls in this category. Risk retention is a viable strategy for small risks where the cost of insuring against the risk would be greater over time than the total losses sustained.

All risks that are not avoided or transferred are retained by default.

This includes risks that are so large or catastrophic that they either cannot be insured against or the premiums would be infeasible. War is an example since most property and risks are not insured against war, so the loss attributed by war is retained by the insured. Also any amounts of potential loss (risk) over the amount insured is retained risk. This may also be acceptable if the chance of a very large loss is small or if the cost to insure for greater coverage amounts is so great it would hinder the goals of the organization too much.

Risk Transfer

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 a risk 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 financially manage risk.

Some ways of managing risk fall into multiple categories. Risk retention pools are technically retaining the risk for the group, but spreading it over the whole group involves transfer among individual members of the group. This is different from traditional insurance, in that no premium is exchanged between members of the group up front, but instead losses are assessed to all members of the group.

Creating the Plan

Decide on the combination of methods to be used for each risk. Each risk management decision should be recorded and approved by the appropriate level of management. For example, a risk concerning the image of the organization should have top management decision behind it whereas IT management would have the authority to decide on computer virus risks.

The risk management plan should propose applicable and effective security controls for managing the risks. For example, an observed high risk of computer viruses could be mitigated by acquiring and implementing anti virus software. A good risk management plan should contain a schedule for control implementation and responsible persons for those actions.

Risk Assessment Tools

One of the most powerful tools is the IT Audit Machine which asside from being the best assessment tool available, allows for the more progressive continuous auditing methodology.

There are a variety of good tools at your disposal to help get through effectively an IT risk assessment. One of these tools is the '''Information Technology Risk Calculator''' shown here: .

Implementation

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.

Review and Evaluation of the Plan

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 made in dealing with the risks being faced.

Risk analysis results and management plans should be updated periodically. There are two primary reasons for this:

to evaluate whether the previously selected security controls are still applicable and effective
to evaluate the possible risk level changes in the business environment. For example, information risks are a good example of rapidly changing business environment

Monitoring

Management and the board should monitor risk mitigation activities to ensure identified objectives are complete or in process. Monitoring should be ongoing, and departments should provide progress reports to management on a periodic basis. Ongoing monitoring further ensures that the risk assessment process is continuous instead of a one-time or annual event.

Key elements of an effective monitoring program include:

Mitigation or corrective action plans
Clear assignment of responsibilities and accountability
Management reporting

Limitations

If risks are improperly assessed and prioritized, time can be wasted in dealing with risk of losses that are not likely to occur. Spending too much time assessing and managing unlikely risks can divert resources that could be used more profitably. Unlikely events do occur but if the risk is unlikely enough to occur it may be better to simply retain the risk and deal with the result if the loss does in fact occur.

Prioritizing too highly the risk management processes could keep an organization from ever completing a project or even getting started. This is especially true if other work is suspended until the risk management process is considered complete.

It is also important to keep in mind the distinction between risk and uncertainty. Risk can be measured by impacts x probability.

Enterprise Risk Management

In enterprise risk management, a risk is defined as a possible event or circumstance that can have negative influences on the Enterprise in question. Its impact can be on the very existence, the resources (human and capital), the products and services, or the customers of the enterprise, as well as external impacts on society, markets, or the environment.

In addition, every probable risk can have a pre-formulated plan to deal with its possible consequences (to ensure contingency if the risk becomes a liability).

From the information above and the average cost per employee over time, or cost accrual ratio, a project manager can estimate:

The cost associated with the risk if it arises, estimated by multiplying employee costs per unit time by the estimated time lost (cost impact, C where C = cost accrual ratio * S).
The probable increase in time associated with a risk (schedule variance due to risk, Rs where Rs = P * S):
- Sorting on this value puts the highest risks to the schedule first. This is intended to cause the greatest risks to the project to be attempted first so that risk is minimized as quickly as possible.
- This is slightly misleading as schedule variances with a large P and small S and vice versa are not equivalent. (The risk of the RMS Titanic sinking vs. the passengers' meals being served at slightly the wrong time).
The probable increase in cost associated with a risk (cost variance due to risk, Rc where Rc = P*C = P*CAR*S = P*S*CAR)
- Sorting on this value puts the highest risks to the budget first.
- See concerns about schedule variance as this is a function of it, as illustrated in the equation above.

Risk Management Activities

Risk management includes the following activities:

Planning how risk management will be held in the particular project. Plan should include risk management tasks, responsibilities, activities and budget.
Assigning a risk officer - a team member other than a project manager who is responsible for foreseeing potential project problems. Typical characteristic of risk officer is a healthy skepticism.
Maintaining live project risk database. Each risk should have the following attributes: opening date, title, short description, probability and importance. Optionally a risk may have an assigned person responsible for its resolution and a date by which the risk must be resolved.
Creating anonymous risk reporting channel. Each team member should have possibility to report risk that he foresees in the project.
Preparing mitigation plans for risks that are chosen to be mitigated. The purpose of the mitigation plan is to describe how this particular risk will be handled; what, when, by who and how will be done to avoid it or minimize consequences if it becomes a liability.
Summarizing planned and faced risks, effectiveness of mitigation activities and effort spend for the risk management.

Risk Management and Business Continuity

Risk management is simply a practice of systematically selecting cost effective approaches for minimizing the effect of threat realization to the organization. All risks can never be fully avoided or mitigated simply because of financial and practical limitations. Therefore all organizations have to accept some level of residual risks.

Whereas risk management tends to be preemptive, business continuity planning (BCP) was invented to deal with the consequences of realized residual risks. The necessity to have BCP in place arises because even very unlikely events will occur if given enough time. Risk management and BCP are often mistakenly seen as rivals or overlapping practices. In fact these processes are so tightly tied together that such separation seems artificial. For example, the risk management process creates important inputs for the BCP (assets, impact assessments, cost estimates etc). Risk management also proposes applicable controls for the observed risks. Therefore, risk management covers several areas that are vital for the BCP process. However, the BCP process goes beyond risk management's preemptive approach and moves on from the assumption that the disaster will realize at some point.

It is vital to identify from a prioritized perspective what components of your business are most important for the continuation of your business. How much down time can a business sustain before permanent damage to reputation or revenue puts a business into bankruptcy? A Disaster Recovery Requirements Analysis should be performed to answer these mission critical questions before a catastrophe strikes. Prudent proactive planning will always be a good business decision.

Associations

--Mdpeters 08:42, 15 February 2007 (EST)

Risk Assessment and Treatment:

Contents

Risk Management

Streamlined Explanation

Explanation