Decision matrices acceptable risk

The purpose of a risk management matrix is to (a) provide a logical framework for hazard analysis and risk assessment and (b) assist risk decision makers in arriving at their risk reduction and risk acceptance or declination conclusions. The implicit goal is to achieve acceptable risk levels. Several standards and guidelines now include the concepts of residual risk and acceptable or tolerable risk (e.g., ANSl/Bll TR3, ISO/IEC Guide 51, SEMI SIO—see references for full titles). 

Earlier in this chapter, reference was made to a speaker who reviewed the hazard analysis and risk assessment methods used in his company, which relied on typical risk assessment and decision-making matrices, to achieve acceptable risk levels. Use of such matrices is a method some organizations apply to arrive at acceptable risk levels. Table 15.1 is an example of such a risk assessment matrix. Using the results from Table 15.1, levels of remedial action or risk acceptance for individual risk categories can be established, as in Table 15.2. 

If RACs are, in fact, going to serve as the drivers in the system and the basis for risk acceptance and resource allocation decisions, the numbers generated must have a positive correlation to the risk involved and to the resources required to control the hazard. A universal RAC matrix would provide a means of comparing relative risks associated with multiple projects, evaluating the allocation of funds, and determining the cost-effectiveness of various controls. Ideally, this universal risk assessment code matrix could provide an evaluation of risks in absolute as well as relative terms. Chapter 12 contains a proposed universal RAC matrix (Total Risk Exposure Codes). The use of a meaningful, quantified, expanded universal RAC matrix may represent a practical approach to probabilistic risk assessment. 

The information taken from the risk profiles is then put into a risk management matrix. A risk management matrix is a decision-making tool that indicates which risks the company is willing to accept. It is very important that the risk management matrix is developed before any analysis is started. 

Definitions of the levels of probability and severity used in risk assessment matrices vary greatly. This reflects the differences in the perceptions of risk that people have. Since a risk assessment matrix is a management decision tool, management personnel at the appropriate level must agree on the definitions of the terms to be used. In so doing, management establishes the levels of risk that require reduction and those that are acceptable. 

Five examples of risk assessment matrices follow. First, an adaptation is shown in Table 7 of the Mishap risk categories and mishap acceptance levels as in the working draft of MIL-STD-882E, the Department of Defense Standard Practice For System Safety. A comment in Appendix A of 882E is pertinent here A mishap assessment matrix allows classification by mishap severity and mishap probability and assists in managing the decision-making to achieve the necessary risk elimination or reduction to an acceptable level. ... 

A hazard analysis and risk assessment matrix must be used in determining risk levels and the risk reduction actions to be taken. A good hazard analysis/risk assessment model will enable decision makers to understand and categorize the risks and to determine the methods and costs to reduce risks to an acceptable level. 

This is the person, or persons, that have the authority to accept potential mishap risk. Typically, the mishap risk for a hazard falls into one of several different possible levels based on the risk matrix, and a person of higher rank or authority is required to accept the corresponding level of risk. DoDINST 5000.2 states that high, serious, medium, and low risk must be accepted by the CAE, PEO, PM, and PM, respectively. In theory, the risk level should be pushed down, through design measures, to the lowest level in order that the risk can be accepted by the lowest level decision authority. In reality, this is not always possible due to various system constraints, thus requiring a decision authority hierarchy. 

---