Risk Quantification

Risk quantification involves evaluating risks and risk interactions to assess the range of possible project outcomes. It is primarily concerned with determining which risk events warrant response.

It is complicated by a number of factors including, but not limited to:

Opportunities and threats can interact in unanticipated ways (e.g., schedule delays may force consideration of a new strategy that reduces overall project duration). A single risk event can cause multiple effects, as when late delivery of a key component produces cost overruns, schedule delays, penalty payments, and a lower-quality product. Opportunities for one stakeholder (reduced cost) may be threats to another (reduced profits). The mathematical techniques used can create a false impression of precision and reliability. Well, we will use a Risk matrix based on two vectors.

The two vectors we will use in this case will be Probability and Impact. The Risks you identify must each be assessed according to these two vectors. Probability refers to the chances of occurrence of any item for e.g. If there is a very high probability that a Risk may be realized, then it is clear that it should have the attention of the team.

The probability chart can be something like:

• If the probability is 5 then we can describe it as 91 – 100% or Very likely to occur

• If the probability is 4 then we can describe it as 61 – 90% or Likely to occur

• If the probability is 3 then we can describe it as 41 – 60% or May occur about half of the time

• If the probability is 2 then we can describe it as 11 – 40% or Unlikely to occur

• If the probability is 1 then we can describe it as 0 – 10% or Very unlikely to occur

Impact

The Impact of a Risk is a measure of its affect on the project. It can range from Minimal (1) at the low end where the consequences would be very small up to Extreme (5) at the high end. One should definitely devise wording to describe each Impact level to suit the realities of your project. Whatever you decide upon should be consistent throughout the entire project. The wording should not be viewed as a set of rules – instead, it is a set of guidelines.

Let’s understand it by some example

Factors for Estimating Impact. When considering the impact of a successful attack, it's important to realize that there are two kinds of impacts. The first is the "technical impact" on the application, the data it uses, and the functions it provides. The other is the "business impact" on the business and company operating the application. Ultimately, the business impact is more important. However, you may not have access to all the information required to figure out the business consequences of a successful exploit. In this case, providing as much detail about the technical risk will enable the appropriate business representative to make a decision about the business risk.

Technical Impact Factors

Technical impact can be broken down into factors aligned with the traditional security areas of concern: confidentiality, integrity, availability, and accountability. The goal is to estimate the magnitude of the impact on the system if the vulnerability were to be exploited.

Business Impact Factors

The business impact stems from the technical impact, but requires a deep understanding of what is important to the company running the application. In general, you should be aiming to support your risks with business impact, particularly if your audience is executive level. The business risk is what justifies investment in fixing security problems.

Many companies have an asset classification guide and/or a business impact reference to help formalize what is important to their business. These standards can help you focus on what's truly important for security. If these aren't available, then it is necessary to talk with people who understand the business to get their take on what's important. The factors below are common areas for many businesses, but this area is even more unique to a company than the factors related to threat agent, vulnerability, and technical impact.

Risk Rating

Now that we have identified the important Risks that threaten the success of a project, what should we do about them? We should make Risk Planning as comprehensive as we wish, but like most things in life, the simplest approach is often the best approach. Unlike Impact and Probability Assessment, your wording should not be considered a guideline. For each of the various Risk Ratings, we want specific things to occur because the risk thresholds are triggers to mobilize the team or stakeholder to take action to mitigate the Risk. Here is some suggested wording for your Risk Planning.

The wording you use in your project can be different than this and reflect the realities of your organization, but it is important that the wording be focused on Actions to manage the Risk

Risk Register

To track and manage Risk on a project the usage of Risk Register/ board is essential. The risk register should have list of identified risks, their mitigation strategies (Avoid, Mitigate, Evade, Contain) post brainstorming sessions with the teams along with some mitigation plan. The Scrum Master must seek input from team members as well as stakeholders and possibly even end users. The risk register or risk log becomes essential as it records identified risks, their severity, and the actions steps to be taken. It can be a simple document, spreadsheet, or a database system, but the most effective format is a table. A table presents a great deal of information in just a few pages.

Managers should view the risk register as a management tool through a review and updating process that identifies, assesses, and manages risks down to acceptable levels. The register provides a framework in which problems that threaten the delivery of the anticipated benefits are captured. Actions are then instigated to reduce the probability and the potential impact of specific risks. Make your risk register visible to project stakeholders so they can see that risks are being addressed. They may flag risks you haven't identified and give other options for risk mitigation. There is no standard list of components that should be included in the risk register.

Some of the most widely used components are as follows:

Dates: As the register is a living document, it is important to record the date that risks are identified or modified. Optional dates to include are the target and completion dates.

Description of the Risk: A phrase that describes the risk.

Risk Type (business, project, stage): Classification of the risk: Business risks relate to delivery of achieved benefit; project risks relate to the management of the project such as time frames and resources, and stage risks are risks associated with a specific stage of the plan.

• Likelihood of Occurrence: Provides an assessment on how likely it is that this risk will occur.

• Severity of Effect: Provides an assessment of the impact that the occurrence of this risk would have on the project.

• Countermeasures/ Mitigation Plan: Actions to be taken to prevent, reduce, or transfer the risk. This may include production of contingency plans.

• Owner: The individual responsible for ensuring that risks are appropriately engaged with countermeasures undertaken.

• Status: Indicates whether this is a current risk or if risk can no longer arise and impact the project.

• Example classifications are: C-current or E-ended.

Risk Review

• Post responding to risks the review of risk register is very important.

• Revisit the impact & probability of open risks.

• Create a Risk burn down chart and metrics analysis in review meetings.

• Risk Review should occur on a continuous basis throughout the project life cycle.