Risk Management, Risk Assessment and Risk Analysis

To identify the risks that your project may be subjected to, it is important to first study the problems faced by previous projects. Study the project plan properly and check for all the possible areas that are vulnerable to some of the other types of risks.

The best way of analyzing a project plan is by converting it to a flowchart and examine all essential areas. It is important to conduct few brainstorming sessions to identify the known unknowns that can affect the project. Any decision taken related to technical, operational, political, legal, social, internal, or external factors should be evaluated properly.

Identification of risk is part of the product lifecycle, before the integration of new technologies and when introducing new and untested infrastructure changes.

Software Risk Analysis a very important aspect of risk management. In this phase, the risk is identified and then categorized. After the categorization of risk, the level, likelihood (percentage), and impact of the risk are analyzed. The likelihood is defined in percentage after examining what are the chances of risk to occur due to various technical conditions. These technical conditions can be:

• Complexity of the technology
• Technical knowledge possessed by the testing team
• Conflicts within the team
• Teams being distributed over a large geographical area
• Usage of poor quality testing tools

With impact we mean the consequence of a risk in case it happens. It is important to know about the impact because it is necessary to know how a business can get affected:

• What will be the loss to the customer?
• How would the business suffer?
• Loss of reputation or harm to society?
• Monetary losses are how big?
• Legal actions against the company?
• Cancellation of a business license?

Consequences of Risks

1. Loss of Integrity: system and data integrity refers to the requirement that information is protected from improper modification. Integrity is lost if unauthorized charges are made to the data or IT system by either intentional or accidental acts. If the loss of system or data integrity is not corrected, continued use of the contaminated system or corrupted data could result in inaccuracy, fraud, or erroneous decisions. Also, violation of integrity may be the first step in a successful attack against system availability or confidentiality. For all these reasons, loss of integrity reduces the assurance of an IT system.

2. Loss of Availability: if a mission-critical IT system is unavailable to its end users, the organization's mission may be affected. Loss of system functionality and operational effectiveness, for example, may result in loss of productive time, thus impeding the end users' performance of their functions in supporting the organization's mission.

3. Loss of Confidentiality: system and data confidentiality refers to the protection of information from unauthorized disclosure. The impact of unauthorized disclosure of confidential information can range from the jeopardizing of national security to the disclosure of Privacy Act data. Unauthorized, unanticipated, or unintentional disclosure could result in loss of public confidence, embarrassment, or legal action against the organization.

Level of risk is identified with the help of:

1. Qualitative Risk Analysis: Here you define risk as:

• High
• Low
• Medium

1. Quantitative Risk Analysis: can be used for software risk analysis but is considered inappropriate because risk level is defined in % which does not give a very clear picture.

Risk-Level Matrix

The purpose of this step is to assess the level of risk to the IT system. The determination of risk for a particular threat vulnerability pair can be expressed as a function of

• The likelihood of a given threat source's attempting to exercise a given vulnerability;
• The magnitude of the impact should a threat-source successfully exercise the vulnerability;
• The adequacy of planned or existing security controls for reducing or eliminating risk.

To measure risk, a risk scale and a risk-level matrix must be developed. The final determination of mission risk is derived by multiplying the ratings assigned for threat likelihood (e.g., probability) and threat impact.

Example:

The probability assigned for each threat likelihood level is 1.0 for High, 0.5 for Medium, 0.1 for Low

The value assigned for each impact level is 100 for High, 50 for Medium, and 10 for Low

Risk Scale: High ( >50 to 100); Medium ( >10 to 50); Low (1 to 10)

| Threat Likelihood | Impact | Rating | |-------------------|-----------|-------------------| | High (1.0) | Low | 10 * 1.0 = 10 | | High (1.0) | Medium | 50 * 1.0 = 50 | | High (1.0) | Low | 100 * 1.0 = 100 | | | | | | Medium (0.5) | Low | 10 * 0.5 = 5 | | Medium (0.5) | Medium | 50 * 0.5 = 25 | | Medium (0.5) | Low | 100 * 0.5 = 50 | | | | | | Low (0.1) | Low | 10 * 0.1 = 1 | | Low (0.1) | Medium | 50 * 0.1 = 5 | | Low (0.1) | Low | 100 * 0.1 = 10 |

Software risk planning is about:

1. Defining preventive measures that would lower down the likelihood or probability of various risks.
2. Define measures that would reduce the impact in case a risk happens.
3. Constant monitoring of processes to identify risks as early as possible.

your organization follows NIST's recommendations for risk management. When control actions must be taken, the following rule applies:

"Address the greatest risks and strive for sufficient risk mitigation at the lowest cost, with minimal impact on other mission capabilities."

Risk mitigation is a systematic methodology used by senior management to reduce mission risk. Risk mitigation can be achieved through any of the following risk mitigation options:

• Risk Assumption: to accept the potential risk and continue operating the IT system or to implement controls to lower the risk to an acceptable level;
• Risk Avoidance: to avoid the risk by eliminating the risk cause and/or consequence (e.g., forgo certain functions of the system or shut down the system when risks are identified);
• Risk Limitation: to limit the risk by implementing controls that minimize the adverse impact of a threat's exercising a vulnerability (e.g., use of supporting, preventive, detective controls);
• Risk Planning: to manage risk by developing a risk mitigation plan that prioritizes, implements, and maintains controls
• Research and Acknowledgment. To lower the risk of loss by acknowledging the vulnerability or flaw and researching controls to correct the vulnerability;
• Risk Transference: to transfer the risk by using other options to compensate for the loss, such as purchasing insurance.

Senior management, the mission owners, knowing the potential risks and recommended controls, may ask, "When and under what circumstances should I take action?" or "When shall I implement these controls to mitigate the risk and protect your organization organization?".

Software risk monitoring is integrated into project activities and regular checks are conducted on top risks. Software risk monitoring comprises of:

1. Tracking of risk plans for any major changes in actual plan, attribute, etc.;
2. Prioritize mitigation measures based on Risk Determination;
3. Evaluate proposed controls and conduct a cost-benefit;
4. Preparation of status reports for project management;
5. Review risks and risks whose impact or likelihood has reached the lowest possible level should be closed;
6. Regularly search for new risks.

To ensure that risks remain at the forefront of project management activities, it's best to keep the risk management plan as simple as possible. For both conventional and agile software project management methodologies, a risk register is a proven tool for organizing and referring to known project risks. A comprehensive risk register would contain consist of the following attributes:

• Description of risk — Summary description of the risk—easy to understand;
• Recognition Date — Date on which stakeholders identify and acknowledge the risk;
• Probability of occurrence — Estimate of probability that this risk will materialize (%);
• Severity — The intensity of undesirable impact to the project—if the risk materializes;
• Owner — This person monitors the risk and takes action if necessary;
• Action — The contingent response if the risk materializes;
• Status — current team view of the risk: potential, monitoring, occurring, or eliminated;
• Loss Size — Given in hours or days, this is a measure of the negative impact to the project;
• Risk Exposure — Given in hours or days, this is is a product of probability and loss size;
• Priority (optional) — This is either an independent ranking or the product of probability and severity. Typically, a higher-severity risk with high probability has higher relative priority.

Risk Register example entry:

| Risk Description | Probability of Occurrence | Loss Size (Days) | Risk Exposure (Days) | |-----------------------------------------------------------|-----|----|-----| | Insufficient QA to validate on all browsers and OS types | 45% | 6 | 2.7 | | Insufficient staff until very late in SDLC | 25% | 7 | 1.8 | | Following end-user testing, more effort may be required | 25% | 18 | 4.5 | | Backup & restore requires 3rd Party solutions | 20% | 12 | 2.4 | ||||| | Total Risk Exposure | 18.2 |