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.

Exchange Rate Risk

The uncertainty of returns for investors that acquire foreign investments and wish to convert them back to their home currency. This is particularly important for investors that have a large amount of over-seas investment and wish to sell and convert their profit to their home currency. If exchange rate risk is high - even though a substantial profit may have been made overseas, the value of the home currency may be less than the overseas currency and may erode a significant amount of the investments earnings. That is, the more volatile an exchange rate between the home and investment currency, the greater the risk of differing currency value eroding the investments value.

Market Risk

The price fluctuations or volatility increases and decreases in the day-to-day market. This type of risk mainly applies to both stocks and options and tends to perform well in a bull (increasing) market and poorly in a bear (decreasing) market. Generally with stock market risks, the more volatility within the market, the more probability there is that your investment will increase or decrease.

Country Risk

This is also termed political risk, because it is the risk of investing funds in another country whereby a major change in the political or economic environment could occur. This could devalue your investment and reduce its overall return. This type of risk is usually restricted to emerging or developing countries that do not have stable economic or political arenas.

Financial Risk

Financial risk is the risk borne by equity holders (refer Shares section) due to a firms use of debt. If the company raises capital by borrowing money, it must pay back this money at some future date plus the financing charges (interest etc charged for borrowing the money). This increases the degree of uncertainty about the company because it must have enough income to pay back this amount at some time in the future.

Liquidity Risk

The uncertainty introduced by the secondary market for a company to meet its future short term financial obligations. When an investor purchases a security, they expect that at some future period they will be able to sell this security at a profit and redeem this value as cash for consumption - this is the liquidity of an investment, its ability to be redeemable for cash at a future date. Generally, as we move up the asset allocation table - the liquidity risk of an investment increases.

Business Risk

The uncertainty of income caused by the nature of a companies business measured by a ratio of operating earnings (income flows of the firm). This means that the less certain you are about the income flows of a firm, the less certain the income will flow back to you as an investor. The sources of business risk mainly arises from a companies products/services, ownership support, industry environment, market position, management quality etc. An example of business risk could include a rubbish company that typically would experience stable income and growth over time and would have a low business risk compared to a steel company whereby sales and earnings fluctuate according to need for steel products and typically would have a higher business risk.

The Objectives, Extent, and Scope of Audit Procedures

Audit procedures are called audit programs by examiners, and they merely serve as guidelines and checklists of actions to perform during audit engagements. To provide an example, we focused on the details of the audit procedures for accounts receivables (AR), which we present in the succeeding sections.

In actual practice, audit techniques or styles in performing these procedures, developed by examiners through their skills and expertise, contribute largely to achieving the best audit results within a specified time frame.

The objectives, the extent, and the scope by which these procedures are performed may vary according to the role of the examiner, as internal or external auditor. These roles and objectives are discussed in full in a separate article entitled Financial Statement Audit vs. Forensic Accounting.

The term “extent” refers to the percentage of documents test-checked for completeness or for accuracy of computations involved. An AR audit program may also include the tracing of transactions from the selling point, to payment activities, up to its final disposition as a paid-account, a past due account, a doubtful account, or as a bad debt, as they are verified via random sampling of substantial balances or material amounts.

The term “scope” refers to the period covered based on cut-off dates established by the internal or external financial auditors. To fraud examiners or forensic accountants, the scope refers to the specific account(s) under suspicions of fraud--where dates could go as far back as necessary.

Audit Documentation

Documentation refers to working papers kept by the auditor as regards audit planning, procedures performed, information and explanations obtained from client and conclusions drawn from the work performed.

Objectives of Documentation:
1: Assist in planning and performance of audit
2: Assist in supervision and review of audit work
3: Record the audit evidence resulting from the audit work performed to support the auditor's opinion , including representation that the examination was conducted in accordance with the International standards on auditing…!

Risk Assessment

Risk analysis is the process of defining and analyzing the dangers to individuals, businesses and government agencies caused by potential natural and human-caused adverse and unwanted events. In IT, a risk analysis report can be used to align technology-related objectives with a company's business objectives. A risk analysis report can be either quantitative or qualitative.

In quantitative risk analysis, an attempt is made to numerically determine the probabilities of various adverse events and the likely extent of the losses if a particular event takes place.

Qualitative risk analysis, which is used more often, does not involve numerical probabilities or predictions of loss. Instead, the qualitative method involves defining the various threats, determining the extent of vulnerabilities and devising countermeasures should an attack occur.

Objectives of having an audit:

The primary objective of having an audit is to enable the auditor to form and express a professional and independent opinion on whether the financial statements give a true and fair view of the financial position of the company and of its profit and loss for the period under review.

Other objectives are;

i) To ensure that the financial statements comply with any relevant statuary requirements, e.g. Companies Ordinances.

ii) To detect fraud and error in accounting records.

iii) To provide advice to client for improvements to financial systems and controls with in the business.

iv) To prevent fraud and error and improve the efficiency of operations.

Finance Lease

IAS 17 provides for capitalization of leases where the lease transfers substantially all of the risks and rewards incidents to the ownership of the property to the lessee. In such cases, the lessee records the lease as an assets and a corresponding liability. The lease treats the transactions will treat his investment “lease payments receivable” instead of “Leased asset”.

Risks include the losses due to idle capacity or obsolescence. Rewards mean the benefits associated with the ownership of property. For example profitable operation over the realization of the residual value.

The criteria to determine when the risks and rewards are transferred have been set out in paragraphs 8 and9of the IAS 17.

What risk's Mean:

Risk is the potential that a chosen action or activity (including the choice of inaction) will lead to a loss (an undesirable outcome). The notion implies that a choice having an influence on the outcome exists (or existed). Potential losses themselves may also be called "risks". Almost any human endeavour carries some risk, but some are much more risky then others.

What Audit Means:

The word audit has two meanings. The first is the security audit, whereby a consulting firm comes in and validates a companies security profile. This is similar to how accounting firms review a company's books. The second term is infosec specific, and means an "auditing" subsystem that monitors actions within the system. For example, it may keep a record of everyone who logs onto a system. Such a record is known as an audit trail.