The Risk Assessment will be conducted by reviewing the functions of the Infrastructure, and then considering the types of events that might occur in both normal and unusual situations. This may be done by challenging the normal assumptions and considering the possibilities of unanticipated situations. For each risk event, the underlying (root) cause should bedetermined that will create the potential risk occurrence.

Risks are ranked by scoring various criteria with appropriate numerical ratings, adding the scores to determine the overall score of each risk, and sorting the risks into descending order based on each score. A risk scoring threshold is established, over which risks must be reduced using adequate design and/or process controls that will protect the system. Those risks that fall below the threshold are either unmitigated or scheduled for later action.

An additional threshold or characteristic of risk can be used to determine the differentiation of non-mitigation versus postponed mitigation.

For each identified risk event, the means of reducing risk (system design or operational features) including manual tasks defined in the system operating procedures, are described in the risk assessment documentation.
Risks with rating scores that meet or exceed the Risk Threshold will require reduction by adding additional technical enhancements or procedural controls to the system.

In order to organise the output from the risk assessment exercise, the following guidelines should be followed

1. Take the output from Risk Assessment Workshop (the Post-It Notes network diagram) and display it on a wall.
2. Each potential risk event is entered into one of the following categories
   • Revenue
   • Cost
   • Asset
3. The risks are considered by major categories:
   • Database Integrity
   • Security
   • Performance/Availability
4. Start at the first Post-It Note. For each risk event, the underlying (root) cause (critical success factor) that creates the risk event is described. In cases where the event could be caused by multiple difference causes, each is individually identified and ask:
   • What can go wrong with this?
   • How likely is that to happen?
   • What effect will that have on the business?
5. Review each risk in turn:
   1. Use a risk matrix such as the one that follows to determine the "risk category" (high, medium, low).
      
   2. Each risk event must be evaluated and scored with numerical rankings based upon the following criteria:
      • Severity

        This ranking indicates the criticality of the event by its impact on the operation of the system. The highest rating is given to a risk that the system might fail if the event occurs, either through the inability of the system to continue, or corruption of the accumulated data occurring. A lower ranking will be used for impacts that do not stop the system, nor corrupt data, and can be offset via other mechanisms, including manual workarounds.

      • Probability

        This ranking indicates the probability that the event will actually occur sometime during the system's life. The highest ranking goes to the event that can be expected to occur at some point, with lower rankings to those events that only might occur, or are not expected to occur at all.

      • Detection

        If the risk event is detected, via other system or manual activities, prior to the time that the risk event causes an impact, that detection likelihood reduces the risk. The highest ranking goes to events that are not likely to be detected, and lower rankings are used for possible or expected degrees of detection of the event.

      • The total Risk Score is the result of multiplying all three risk scores together
   • For high risks, consider ways of reducing the impact or prepare a contingency plan.
   • For medium risks, prepare a contingency plan.
   • For low risks, take no immediate action but continue to monitor they may become more significant.
   Use the risk matrix spreadsheet to evaluate the risk category.
6. Repeat this until every Post-It Note in the network has been evaluated.
7. Take time for the team to review the output so far. Are there any themes or noticeable streams of the project that appear to be problematic?
8. Begin with the high risks: start generating possible ways of dealing with them. Allow all options to be raised. Do not evaluate, just capture the possible risk management actions for later evaluation.
9. Evaluate and agree which risk-management options should be followed and who is accountable for managing each particular risk. Task - strive to eliminate any high risks.
   • Look for alternative way of approaching the work that avoids sequences of risks.
   • Capture your risks in a risk log (similar to below).
10. For each Risk Event that meets or exceeds the Risk Threshold Value, a Risk Mitigation must be determined, based on either a design feature that will prevent the risk event from occurring, or a manual process that is described within an identified system procedure . Providing a description of Risk Mitigation for events that score below the risk threshold level is optional.
11. The Risk Assessment document must be approved by the System Owner, Technical Representative, and Quality Representative.