Risk assessment matrix (MIL-STD-882E)

0:00 Intro

The risk assessment matrix, for the ASP exam. Every rule and number here is cited to its primary source, on screen.

0:08 Learning objectives

In this lesson, you'll learn to: define a Risk Assessment Code, read the risk level that Table III assigns, explain how risk acceptance decisions are documented and revisited, and explain why software is assessed differently.

0:25 Building a RAC

An assessed risk is expressed as a Risk Assessment Code, or RAC. A RAC combines one severity category and one probability level. Take 1A.

0:42 Table III

The 1 is Catastrophic severity, and the A is Frequent probability. Table III assigns a risk level to each RAC. There are four levels: High, Serious, Medium, and Low. Find the cell for that severity category and probability level. The cell gives the risk level.

1:05 Worked example A

Risk level is the result you read off the matrix, not something you pick. Example. A hazard is rated Catastrophic and Frequent. Catastrophic is the first severity category. Frequent is probability level A. Join them: severity first, then the letter.

1:25 Which definitions apply

The RAC is 1A. Then you read 1A in Table III for the risk level. Several tasks in the standard point back to the same tables. The SSPP, the HMP and the PHA must use the definitions in Tables I and II, and the RACs in Table III.

1:48 Risk acceptance

The exception: tailored definitions or a tailored matrix, formally approved under DoD Component policy. Risk acceptance decisions have to be recorded. Each risk acceptance decision shall be documented in the Hazard Tracking System. Risk can change after fielding. Mishap reports, user feedback or similar systems may reveal new hazards, or show a known hazard's risk is higher or lower than thought.

2:14 Software

02. Software risk cannot rely solely on severity and probability. The probability of failure of a single software function is difficult at best and cannot be based on historical data. Table IV defines the software control categories. Table V, the SSCM, assigns SwCI numbers to each cross-referenced block of its matrix.

2:50 Worked example B

The SSCM shall define the LOR tasks tied to each SwCI. They are the minimum set needed to assess software's contribution to system-level risk. Example. Two hazards are assessed. The first is rated 1A. The second is Catastrophic severity but a different probability level, so its RAC is not 1A.

3:16 On the job

Split a RAC: the number is the severity category, the letter is the probability level. Then read each RAC in Table III for its risk level. The level comes from the table, not a guess. You manage safety for a fielded system. Mishap reports show a known hazard's risk is higher than assessed.

3:44 Common exam traps

First, reassess: pick the severity category and probability level, then form the new RAC. Next, read the RAC in Table III for its risk level. 02 and documented in the HTS. Now, five traps that catch people on exam day. One: a RAC is one severity category and one probability level. Two: in 1A, Catastrophic is severity and Frequent is probability. Three: four risk levels, High, Serious, Medium, and Low.

4:20 Recap quiz

Four: the SSCM resembles the risk matrix but is not an assessment of risk. Five: software risk considers severity and the degree of control over hardware. Question 1. In the standard, a RAC of 1A is which combination? A: Frequent severity, Catastrophic probability. B: Catastrophic severity, Frequent probability. C: Critical severity, Probable probability. D: Catastrophic severity, Improbable probability. B. 1A is Catastrophic severity combined with Frequent probability. Question 2. What does Table III assign to each RAC? A: A cost estimate. B: A software control category. C: A risk level of High, Serious, Medium, or Low. D: A required PPE level. C. Table III assigns High, Serious, Medium, or Low to each RAC. Question 3. A team wants to rate software risk using only severity and probability. What does the standard say? A: Fine, use Table III alone. B: Not solely: also consider software control over hardware. C: Use historical failure data for each function. D: Table V is the risk matrix, so use it. B. Software risk also considers how much control software has over the hardware. Want to see where you stand on every ASP domain? com.

25 questions, free, no card. You get a readiness score for each ASP domain.