Risky Business (part 1) - The Number Game (Page 4 of 4 )
Next, it's time for a little meditation. Study the risks that have been discovered so far, and evaluate them using the following steps:
1. Classify the risks: The risks that have been recorded should be categorized in terms of probability of occurrence, frequency of occurrence, impact and possibility of recurrence. Embrace a strategic method to dig into the wherewithal of the company and underscore endangered areas.
2. Formulate risk statements: Every risk has a reason for occurrence, and some impact that it would have after its occurrence. Try and devise "risk statements" that explain this relationship. For example,
Cause: there is no backup power supply to support the system.
Effect: there could be data loss in the event of sudden power failure.
The above "cause and effect" risk statement suggests that the system might risk data loss if the power supply suddenly collapses. The precaution to be taken here is simple: keep a backup power supply on hand. 3. Prioritize the threats: Judge the impact of the risks, and prioritize those that are likely to cause more damage to the assets of the company. Deal with them in that order of precedence. A good approach here is to deploy a scale for acceptable levels of impact severity or occurrence frequency, such as the example below:
Probability Value Description
-----------------------------------------
very low 1 1% or less
low 2 1-5%
medium 3 6-10%
high 4 11-25%
very high 5 26% and more
The table above contains a "risk probability scale", where a numeric value is assigned to the probability of occurrence of a specific risk. By assigning values to each level of probability, it becomes possible to decide and state acceptable levels of risk occurrence. Risks with a larger value (say, 4) will be higher on the priority list than risks with a smaller value (say, 2).
Along the same lines, you can also put together a "risk impact scale", as in the following table:
Severity Value Description-----------------------------------------------Minor A Partial or complete loss of information. Information is retrievable from other sources.Significant B Partial loss of information. Information can be reconstructed from other sources.Serious C Complete loss of information. Information irretrievable.Very Serious D Partial, irreversible, irretrievable loss of information.Catastrophic E Irreversible, irretrievable loss of information.
In the above table, risks tagged as "Catastrophic" (value E) pose the highest level of danger, while risks tagged as "Minor" (value A) have the smallest impact.
4. Calculate risk factors: The probability of occurrence of a risk and its impact form the skeleton of a risk factor calculation. These factors can be estimated numerically using various formulae, as below:
* Risk Exposure (RE) = Probability Of Occurrence x Impact
Risk Exposure is defined as the product of the probability of occurrence of a risk and the severity of its impact on occurrence. In other words, the value of RE signifies the magnitude of loss that the organization suffers due to a risk, in terms of money or other valuable assets.
* Risk Coverage (RC) = Total Assets x Number Of Risks x Vulnerabilities
Risk Coverage is defined as a value that signifies the total risk associated with the vulnerable assets of a company.
* Risk Reduction Leverage (RRL) = (RE before - RE after) / Risk Reduction Cost
RRL is derived from RE and is defined as the amount of financial resources spent in risk reduction activities.
5. Analyze assumptions: Always probe the assumptions made concerning a project and the people associated with it. For example, if it is assumed that the developers required for the project will be hired in a week's time, make sure that they are, or else all dependent tasks will start falling behind schedule as well.
6. Perform a critical path analysis: A critical path is defined a key sequence of actions that must be taken for a project to be completed on time. Slippages in this critical path can harm the end product, by delaying associated tasks and events. For example, a budget explosion identified on the critical path must be considered a potentially serious risk, as it could lead to problems regarding the availability of funds in a later stage.
7. Scrutinize records of past projects: As history repeats itself, perform a thorough study of past projects with special attention to:
- the risks encountered
- the corrective action taken
- the success rate
- obstacles in implementing corrective action
- the extent to which the risk management plan succeeded in achieving its goals
This reduces work and also speeds it up, as you will quickly get an idea of what has to be done and what are the focus areas in the current project.
8. Create a risk factors chart: Sum up all the information gathered so far for each risk in a systematic and organized manner by preparing a risk factors chart. This chart should contain a tabular representation of the data you have gathered so far, with special attention to the source, priority, probability of occurrence and priority of each risk. Numerical estimates of risk exposure and coverage may also be added to this chart if available.
This chart provides an organization with the information needed to better handle risk in future projects as well - if a similar risk scenario is detected, then it knows exactly what needs to be done to eliminate it.
If information on all the risks discovered is maintained in this fashion, then a risk knowledge base may be created; this is helpful not only for the current project, but also for future undertakings.
That's about it for the first part of this article. In the next (and concluding) segment, I will continue this discussion with a focus on the remaining steps of the SRM process: implementation, monitoring and auditing. See you then!
Note: Examples are illustrative only, and are not meant for a production environment. Melonfire provides no warranties or support for the source code described in this article. YMMV!
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
/ 7 
