Risk Mitigation Tools

-Tools and processes used to “fortify” your business by developing defenses ahead of time.
Alternate Data Centers
Contracting secondary locations will enable an organization to recover critical technologies if the primary technology infrastructure fails.

Alternate Suppliers
Seeking out and documenting contingency agreements with alternate suppliers for your organization’s critical inputs will allow you to continue normal activities in the event that one of your critical suppliers experiences an interruption or ceases to supply you for any reason.

Backup Power
Securing backup power will enable your core activities to continue as normal with minimal, if any, downtime or loss in productivity.

Change Management Processes
Initiating and controlling organizational, process, technology or resource adjustments with the end objective of ensuring an appropriate level of performance and availability throughout the transition.
Cross-Trained Personnel
Ensuring that multiple staff members can fulfill the duties of each critical job within your organization will remove any personnel single points of failure and enable regular activities to continue even if an employee is absent, unable to work or is no longer employed by the organization.

Data Backup
Replicating data at an alternate location and/or on alternate media will help protect against the loss of the primary data source and also simplify and expedite recovery efforts, thus minimizing downtime.

Fire Protection Systems
Developing working relationships with your local fire department and other first responders, as well as taking fire protective measures of your own (i.e. using fire retardant file cabinets and ensuring that sprinkler systems work properly), will not only help protect personnel, information and facilities, but also minimize the effects of a fire on your core operational activities.

Insurance
Carrying appropriate insurance can help minimize financial complications as a result of major facility or equipment loss, an inability to deliver products or services or if one or more of your employees are injured in an accident

IT Security Measures
Taking appropriate measures to protect hardware, software, data storage, and communications technology will reduce downtime and organization inefficiency (i.e. access controls, mal-ware protections, etc.).

Media Monitoring
Employing a media monitoring process can provide your organization with early warning regarding reputation issues, as well as other threats that could result in a near-term interruption.

Physical Security Controls
Keeping unauthorized persons out of restricted areas will reduce the potential for data loss or business process disruption due to vandalism, theft or other forms of sabotage.

Safety Stock
Storing an appropriate amount of finished product or raw materials in an off-site location will limit the impact of downtime resulting from a loss of the organizations primary storage or production capabilities.

Business case

Central to the notion of risk management is the idea of clearly describing impact. Without a clear and compelling tie to either business or mission consequences, technical risks, software defects, and the like are not often compelling enough on their own to spur action. The risks we focus on in this portal are all tied directly to software and all have clear security ramifications. However, unless these risks are described in terms that business people and decision makers understand, they will not likely be addressed. The ever-increasing integration of business processes and IT systems means that software risks can often be linked to serious and specific impacts on the mission of an organization or business. Since resources are rarely unlimited, mitigation of software risks can and should be prioritized according to the severity of the related business risks.

Hence, software risk management can only be successfully carried out in a business context. Risks are unavoidable and are a necessary part of software development. Management of risks, including the notion of risk aversion and technical tradeoff, is deeply impacted by business motivation. Thus, the first stage of software risk management involves assessing the business situation. Commonly, business goals are neither obvious nor explicitly stated. In some cases, you may even have difficulty expressing these goals clearly and consistently. During this stage, the analyst must extract and describe business goals, priorities, and circumstances in order to understand what kinds of software risks to care about and which business goals are paramount. Business goals include, but are not limited to, increasing revenue, meeting service level agreements, reducing development costs, and generating high return on investment.

The activities of identifying, tracking, storing, measuring, and reporting software risk information cannot be overemphasized. Successful use of the RMF depends on continuous and consistent identification and storage of risk information as it changes over time. A master list of risks should be maintained during all stages of RMF execution and continually revisited. Measurements regarding this master list make excellent reporting information. For example, the number of risks identified in various software artifacts and/or software life-cycle phases can be used to identify problematic areas in software process. Likewise, the number of software risks mitigated over time can be used to show concrete progress as risk mitigation activities unfold. Links to descriptions or measurements of the corresponding business risks mitigated can be used to clearly demonstrate the business value of the software risk mitigation process and the risk management framework.

Measurement and Reporting on Risk

The activity of identifying, tracking, storing, measuring, and reporting software risk information cannot be overemphasized. Successful use of the RMF depends on continuous and consistent identification and storage of risk information as it changes over time. A master list of risks should be maintained during all stages of RMF execution and continually revisited. Measurements regarding this master list make excellent reporting information. For example, the number of risks identified in various software artifacts and/or software life-cycle phases can be used to identify problematic areas in the software process. Likewise, the number of risks mitigated over time can be used to show concrete progress as risk mitigation activities unfold.

Fix the Problems and Validate the Fixes

Once a mitigation strategy has been defined, it must be executed. Those artifacts where problems (e.g., architectural flaws in a design, requirements collisions, or problems in testing) have been identified should be rectified. Risk mitigation is carried out according to the strategy defined in stage four. Progress at this stage should be measured in terms of completeness against the risk mitigation strategy. Good metrics include, but are not limited to, progress against risks, open risks remaining, and any artifact quality metrics previously identified.

This stage also involves application of those validation techniques previously identified. The validation stage provides some confidence that risks have been properly mitigated through artifact improvement and that the risk mitigation strategy is working. Testing can be used to demonstrate and measure the effectiveness of risk mitigation activities. The central concern at this stage is to validate that software artifacts and processes no longer bear unacceptable risks. This stage should define and leave in place a repeatable, measurable, verifiable validation process that can be run from time to time to continually verify artifact quality. Typical metrics employed during this stage include artifact quality metrics as well as levels of risk mitigation effectiveness.

Define the Risk Mitigation Strategy

Given a set of risks and their priorities from stage three, the next stage is to create a coherent strategy for mitigating the risks in a cost effective manner. Any suggested mitigation activities must take into account cost, time to implement, likelihood of success, completeness, and impact over the entire corpus of risks. A risk mitigation strategy must be constrained by the business context and should consider what the organization can afford, integrate, and understand. The strategy must also directly identify validation techniques that can be used to demonstrate that risks are properly mitigated. Typical metrics to consider in this stage are financial in nature and include estimated cost takeout, return on investment, method effectiveness in terms of dollar impact, and percentage of risk coverage (related in terms of removing costly impact).

Synthesize and Prioritize Risks

Large numbers of risks will be apparent in almost any given system. Identifying these risks is important, but it is the prioritization of these risks that leads directly to creation of value. Through the activities of synthesizing and prioritizing risks, the critical "Who cares?" question can (and must) be answered. Synthesis and prioritize should be driven to answer questions such as "What shall we do first given the current risk situation?" and "What is the best allocation of resources, especially in terms of risk mitigation activities?" Clearly, the prioritization process must take into account which business goals are the most important to the organization, which goals are immediately threatened, and how likely technical risks are to manifest themselves in such a way as to impact the business. This stage creates as its output a list of all the risks and their appropriate priority for resolution. Typical risk metrics include, but are not limited to, risk likelihood, risk impact, risk severity, and number of risks emerging and mitigated over time.

Identify Business and Technical Risks

Business risks directly threaten one or more of a customer's business goals. The identification of such risks helps to clarify and quantify the possibility that certain events will directly impact business goals. Business risks have impacts that include direct financial loss, damage to brand or reputation, violation of customer or regulatory constraints, exposure to liability, and increase in development costs. The severity of a business risk should be expressed in terms of financial or project management metrics. These include, but are not limited to, market share (%), direct cost, level of productivity, and cost of rework.

Business risk identification helps to define and steer use of particular technical methods for extracting, measuring, and mitigating software risk given various software artifacts. The identification of business risks provides a necessary foundation that allows software risk (especially impact) to be quantified and described in business terms.

The key to making risk management work for business lies in tying technical risks to business context in a meaningful way. The ability to identify and deeply understand risks is thus essential. Uncovering and recognizing technical risks is a high-expertise undertaking that usually requires years of experience.

Central to this stage of the RMF is the ability to discover and describe technical risks and map them (through business risks) to business goals. A technical risk is a situation that runs counter to the planned design or implementation of the system under consideration. For example, a technical risk may give rise to the system behaving in an unexpected way, violating its own design strictures, or failing to perform as required. Technical risks can also be related to the process of building software. The process an organization follows may offer too many opportunities for mistakes in design or implementation. Technical risks involve impacts such as unexpected system crashes, avoidance of controls (audit or otherwise), unauthorized data modification or disclosure, and needless rework of artifacts during development.

Technical risk identification is supported by the software security best practices described on this portal, especially those best practices that involve artifact analysis.

Understand the Business Context

Software risk management occurs in a business context. Risks are unavoidable and are a necessary part of software development. Management of risks, including the notions of risk aversion and technical trade off, is deeply impacted by business motivation. Thus, the first stage of software risk management involves getting a handle on the business situation. Commonly, business goals are neither obvious nor explicitly stated. In some cases, you may even have difficulty expressing these goals clearly and consistently. During this stage, the analyst must extract and describe business goals, priorities, and circumstances in order to understand what kinds of software risks to care about and which business goals are paramount. Business goals include, but are not limited to, increasing revenue, meeting service level agreements, reducing development costs, and generating high return on investment.

Risk Management Framework

A continuous risk management process is a necessary part of any approach to software security. Software security risk includes risks found in artifacts during assurance activities, risks introduced by insufficient process, and personnel related risks. An overall risk management framework (described here) can help make sense of software security. Note that we are explicitly teasing apart architectural risk analysis (one of the critical software security best practices) and use of the risk management framework.

A risk management framework is an essential philosophy for approaching security work. Following the risk management framework introduced here is by definition a full life-cycle activity. For the purposes of this description, consider risk management a high-level approach to iterative risk analysis that is deeply integrated throughout the software development life cycle (SDLC).

The RMF described here is a condensed version of the Cigital RMF, a mature process that has been applied in the field for almost ten years. This RMF is designed to manage software-induced business risks. Through the application of five simple activities, analysts use their own technical expertise, relevant tools, and technologies to carry out a reasonable risk management approach.

The purpose of an RMF like this is to allow a consistent and repeatable expertise-driven approach to risk management. As we converge on and describe software risk management activities in a consistent manner, the basis for measurement and common metrics emerges. Such metrics are sorely needed and should allow organizations to better manage business and technical risks given particular quality goals; make more informed, objective business decisions regarding software (e.g., whether an application is ready to release); and improve internal software development processes so that they in turn better manage software risks.

Risk Response Options

Risk identification, assessment, and analysis exercises form the basis for sound risk response options. A series of risk response actions can help agencies and their industry partners avoid or mitigate the identified risks. Wideman, in the Project Management Institute standard Project and Program Risk Management: A Guide to Managing Risks and Opportunities, states that a risk may be the following:
Unrecognized, unmanaged, or ignored (by default).
Recognized, but no action taken (absorbed by a mater of policy).
Avoided (by taking appropriate steps).
Reduced (by an alternative approach).
Transferred (to others through contract or insurance).
Retained and absorbed (by prudent allowances).
Handled by a combination of the above.

The above categorization of risk response options helps formalize risk management planning. The Caltrans Project Risk Management Handbook suggests a subset of strategies from the categorization defined by Wideman above.(6) The Caltrans handbook states that the project development team must identify which strategy is best for each risk and then design specific actions to implement that strategy. The strategies and actions in the handbook include the following:
Avoidance-The team changes the project plan to eliminate the risk or to protect the project objectives from its impact. The team might achieve this by changing scope, adding time, or adding resources (thus relaxing the so-called triple constraint).
Transference-The team transfers the financial impact of risk by contracting out some aspect of the work. Transference reduces the risk only if the contractor is more capable of taking steps to reduce the risk and does so. (This strategy is discussed in depth in Chapter.
Mitigation-The team seeks to reduce the probability or consequences of a risk event to an acceptable threshold. It accomplishes this via many different means that are specific to the project and the risk. Mitigation steps, although costly and time consuming, may still be preferable to going forward with the unmitigated risk.
Acceptance-The project manager and team decide to accept certain risks. They do not change the project plan to deal with a risk or identify any response strategy other than agreeing to address the risk if it occurs.

Given a clear understanding of the risks, their magnitude, and the options for response, an understanding of project risk will emerge. This understanding will include where, when, and to what extent exposure will be anticipated. The understanding will allow for thoughtful risk planning.

Objectives of Risk Mitigation and Planning

The objectives of risk mitigation and planning are to explore risk response strategies for the high risk items identified in the qualitative and quantitative risk analysis. The process identifies and assigns parties to take responsibility for each risk response. It ensures that each risk requiring a response has an owner. The owner of the risk could be an agency planner, engineer, or construction manager, depending on the point in project development, or it could be a private sector contractor or partner, depending on the contracting method and risk allocation.

Risk mitigation and planning efforts may require that agencies set policies, procedures, goals, and responsibility standards. Formalizing risk mitigation and planning throughout a highway agency will help establish a risk culture that should result in better cost management from planning through construction and better allocation of project risks that align teams with customer-oriented performance goals.

Once the agency planner, engineers, and construction managers have thoroughly analyzed the critical set of risks, they are in a better position to determine the best course of action to mitigate those risks. Pennock and Haimes of the Center for Risk Management of Engineering Systems state that three key questions can be posed for risk mitigation.
What can be done and what options are available?
What are the trade offs in terms of all costs, benefits, and risks among the available options?
What are the impacts of current decisions on future options?

An understanding of these three questions is critical to risk mitigation and risk management planning. Question 1 addresses the available risk response options, which are presented in the following section. An understanding of questions 2 and 3 is necessary for risk planning because they determine the impact of both the immediate mitigation decisions and the flexibility of risk mitigation and planning on future events.

What is Risk Mitigation and who will involve in Risk mitigation plan

Risk Mitigation is nothing but ensuring the smooth
functioning of day to day business and making it sure that
the process is completed by sticking to quality and
compliance.This naturally eliminates much of the system
error and human mistakes.If at all a mistake is committed
it has to be rectified before it could hurt the business.

Ideally there is an individual or group of individuals who
have vast experience of the process and are well aware
about the human mistakes, system error and manipulations
that could hurt the process. They are also capable of
identifying mistakes error and possible manipulations.


Further Risk Mitigation involves identifying the grey areas
and eliminating them out of the process.This ensures that
the same error dont happen in the future.

Risks and Mitigation

Any risks that will affect the testing process must be
listed along with the mitigation. By documenting the risks
in this document, we can anticipate the occurrence of it
well ahead of time and then we can pro actively prevent it
from occurring. Sample risks are dependency of completion
of coding, which is done by sub-contractors, capability of
testing tools etc.