Acquisition
MIL-STD-882E system safety and risk matrix
MIL-STD-882E defines system safety hazard analysis, risk assessment, mitigation, and acceptance. Change 1 is current; software uses a criticality index.
Nov 10, 20267 min read5 sources
Why it matters
A traceable hazard record lets the responsible authority judge the remaining risk before people or equipment face it.
The short version
- 1MIL-STD-882E with Change 1, dated September 27, 2023, remains active; ASSIST lists no published revision F.
- 2The 8 process elements connect hazard identification, risk reduction, verification, acceptance, and life-cycle management.
- 3Software control category and severity determine a criticality index that selects analysis and testing, rather than a risk rating.
MIL-STD-882E defines a system safety process to identify hazards, reduce risk, document acceptance, and manage risk throughout system life. It covers hardware, software, equipment, and infrastructure from design through disposal. (MIL-STD-882E, scope)
The standard combines an engineering process with risk assessment rules. A completed matrix supports a decision; it does not perform the analysis or authorize acceptance by itself.
What is the current MIL-STD-882 revision?
MIL-STD-882E with Change 1, dated September 27, 2023, is the current published version. The Acquisition Streamlining and Standardization Information System (ASSIST) lists it as active. The revision history lists no MIL-STD-882F. (ASSIST record)
Revision E originally appeared on May 11, 2012. Notice 1 validated it on February 10, 2022. Change 1 is incorporated into the current document.
When a contract requires the standard without naming specific tasks, sections 3 and 4 are mandatory. Additional task requirements depend on what the contract specifies. Identify that scope before promising a particular set of analyses. (ASSIST scope; MIL-STD-882E, section 4.1)
What are the 8 elements of the system safety process?
The 8 elements run from documenting the approach through managing risks after fielding. Section 4.3 permits iteration between them. (MIL-STD-882E, section 4.3)
- Document the system safety approach, including responsibilities and the method for tracking hazards.
- Identify and document hazards across hardware, software, interfaces, users, and operating conditions.
- Assess and document risk using potential mishap severity and probability.
- Identify and document candidate measures to eliminate hazards or reduce risk.
- Reduce risk by selecting and implementing measures.
- Verify, validate, and document whether those measures work.
- Obtain risk acceptance from the appropriate authority and document the decision.
- Manage life-cycle risk as configurations, operations, and evidence change.
A Hazard Tracking System (HTS) connects hazards, assessments, controls, verification results, and acceptance records. The record should show how the current conclusion follows from the evidence. (Engineering of Defense Systems Guidebook, section 3.3.4.3)
What does system safety hazard analysis examine?
System safety hazard analysis examines how the system, its users, and its environment could combine to cause a mishap. Hardware failures, software behavior, and human interfaces all belong in that assessment.
Naval Air Systems Command (NAVAIR) describes system-level hazard analysis as addressing hardware, software, and human-interface causes. It also calls for tracing safety-critical requirements into implementation and testing. (NAVAIR safety guidance)
MIL-STD-882E provides named analysis tasks. Task 202 covers preliminary hazard analysis; Task 205 covers system hazard analysis; Task 208 covers functional hazard analysis. The selected tasks need to match the contract and the system. (MIL-STD-882E, tasks)
A trade study can compare proposed controls. Keep the hazard, expected reduction, implementation cost, and supporting evidence visible for each alternative.
What are the severity categories and probability levels?
Severity describes the potential consequences; probability describes how likely the mishap is to occur. Table I defines severity using personnel, environmental, and monetary consequences. Any applicable consequence can establish the category. (MIL-STD-882E, Table I)
| Category | Personnel consequence | Environmental consequence | Monetary loss |
|---|---|---|---|
| 1, Catastrophic | Death or permanent total disability | Significant, irreversible impact | At least $10 million |
| 2, Critical | Permanent partial disability, or injury/illness potentially hospitalizing at least 3 people | Significant, reversible impact | At least $1 million but below $10 million |
| 3, Marginal | Injury/illness causing at least 1 lost workday | Moderate, reversible impact | At least $100,000 but below $1 million |
| 4, Negligible | Injury/illness without a lost workday | Minimal impact | Below $100,000 |
Table II distinguishes the life of an individual item from experience across a fleet or inventory. The following descriptions paraphrase its qualitative levels. (MIL-STD-882E, Table II)
| Level | Individual item | Fleet or inventory |
|---|---|---|
| A, Frequent | Expected often during its life | Experienced continuously |
| B, Probable | Expected several times during its life | Expected frequently |
| C, Occasional | Expected sometime during its life | Expected several times |
| D, Remote | Unlikely, but possible during its life | Unlikely, but reasonably expected |
| E, Improbable | Unlikely enough that it may never occur during its life | Unlikely, but possible |
| F, Eliminated | Hazard removed; occurrence impossible | Hazard removed; occurrence impossible |
Document numerical probability definitions when using them. Training, warnings, or protective equipment cannot justify level F. The hazard must actually be absent. (MIL-STD-882E, section 4.3.3)
These categories describe potential mishap consequences. For reporting an actual event, consult the separate mishap classification rules.
How does the MIL-STD-882 risk assessment matrix work?
The matrix combines a severity category and probability level to assign High, Serious, Medium, or Low risk. A Risk Assessment Code (RAC) records the pair. For example, 1A means Catastrophic and Frequent. (MIL-STD-882E, Table III)
| Probability | Catastrophic, 1 | Critical, 2 | Marginal, 3 | Negligible, 4 |
|---|---|---|---|---|
| A, Frequent | High | High | Serious | Medium |
| B, Probable | High | High | Serious | Medium |
| C, Occasional | High | Serious | Medium | Low |
| D, Remote | Serious | Medium | Medium | Low |
| E, Improbable | Medium | Medium | Medium | Low |
| F, Eliminated | Eliminated | Eliminated | Eliminated | Eliminated |
An improbable catastrophic mishap therefore remains Medium in this matrix. A low probability estimate does not erase severe consequences.
Use these definitions and matrix unless a tailored alternative receives formal approval under component policy. Keep the assumptions and supporting data with the assessment.
How is software safety criticality determined?
Software safety criticality combines potential mishap severity with the degree of control software exercises. MIL-STD-882E says software risk cannot rely solely on severity and probability estimated like hardware reliability. (MIL-STD-882E, section 4.4)
First assign a Software Control Category (SCC). The following table summarizes Table IV; the full definitions govern classification.
| SCC | Name | Defining relationship |
|---|---|---|
| 1 | Autonomous | Controls safety-significant hardware without predetermined safe detection and intervention |
| 2 | Semi-autonomous | Allows independent safety intervention; also covers safety-significant displays requiring immediate operator action |
| 3 | Redundant fault tolerant | Commands need a control entity to complete them, with redundant, independent fault-tolerant mechanisms; also covers safety-critical decision information backed by such mechanisms |
| 4 | Influential | Supplies safety-related decision information without requiring operator action to prevent a mishap |
| 5 | No safety impact | Has no safety-significant control or information role and does not transport safety-significant or time-sensitive data |
Next combine the SCC with severity. Each cell below is a Software Criticality Index (SwCI), as defined by Table V. (MIL-STD-882E, Tables IV and V)
| SCC | Catastrophic, 1 | Critical, 2 | Marginal, 3 | Negligible, 4 |
|---|---|---|---|---|
| 1 | 1 | 1 | 3 | 4 |
| 2 | 1 | 2 | 3 | 4 |
| 3 | 2 | 3 | 4 | 4 |
| 4 | 3 | 4 | 4 | 4 |
| 5 | 5 | 5 | 5 | 5 |
The SwCI selects minimum level-of-rigor tasks. It is not a risk rating.
SwCI 1 requires requirements, architecture, design, and code analysis plus in-depth safety-specific testing. SwCI 2 removes code analysis from that minimum set. SwCI 3 requires requirements and architecture analysis with in-depth safety-specific testing.
SwCI 4 requires safety-specific testing. SwCI 5 needs no safety-specific analysis or verification after safety engineering assesses it as having no safety impact. These distinctions do not replace system hazard analysis. (MIL-STD-882E, Table V)
Incomplete required work has a separate consequence. Table VI assigns High, Serious, Medium, or Low contributions to risk for unfinished SwCI 1, 2, 3, or 4 tasks, respectively. Those findings enter the hazard record and formal decision process. (MIL-STD-882E, section 4.4.3 and Table VI)
How should a program reduce and accept risk?
A program should first seek to eliminate hazards through design, then reduce remaining risks and obtain the required acceptance. The standard ranks design changes and engineered protections ahead of warnings, procedures, training, and protective equipment. (MIL-STD-882E, section 4.3.4)
Department of Defense Instruction (DoDI) 5000.88 requires acceptance before exposure to known system-related hazards. User representatives participate throughout the life cycle and formally concur before Serious or High risk acceptance. Record that decision separately from the analysis that supports it. (DoDI 5000.88, section 3.6)
What to do next
- Confirm the contract's standard revision, selected tasks, and approved tailoring.
- Define hazards and mishap outcomes before assigning matrix cells.
- Record severity, probability assumptions, controls, and verification evidence in the hazard tracking system.
- Classify software control and complete the required criticality-based analyses and tests.
- Obtain the required risk acceptance and revisit it when the system or evidence changes.
Azcuna's LEDGER turns a trade study into a Decision Package in which every number cites its source and AI agents draft but never decide. It was proposed to the Army under SBIR Phase I topic ARM26BX06-NV012, and the proposal was submitted on October 21, 2026.
Questions people ask
What is MIL-STD-882E?
MIL-STD-882E is the Department of Defense standard practice for system safety. It provides a process for identifying hazards, assessing and reducing their risks, documenting acceptance, and managing risk throughout the system life cycle. The scope covers hardware, software, equipment, and infrastructure.
Does MIL-STD-882F exist?
The ASSIST revision history lists MIL-STD-882E with Change 1, dated September 27, 2023, as active. It lists no released revision F. Revision E originally appeared on May 11, 2012, followed by a validation notice in February 2022 and the incorporated change in 2023.
What are the MIL-STD-882 severity categories?
Table I of MIL-STD-882E defines Catastrophic as category 1, Critical as 2, Marginal as 3, and Negligible as 4. Classification considers potential injury or death, environmental consequences, and monetary loss. These are potential mishap consequences used in system risk assessment.
What does eliminated probability mean in MIL-STD-882E?
Level F means the hazard has been removed so the associated occurrence is impossible. MIL-STD-882E section 4.3.3 says training, warnings, cautions, doctrine, and personal protective equipment cannot justify that level. A hazard with a very low probability remains distinct from an eliminated hazard.
Is the software criticality index a risk rating?
No. MIL-STD-882E Table V combines software control category and mishap severity to select minimum analysis and testing tasks. The software criticality index is not a risk assessment. Table VI separately addresses contributions to risk when the required level-of-rigor tasks are unspecified or incomplete.
Are all MIL-STD-882E tasks mandatory?
When a solicitation or contract requires MIL-STD-882E without specifying tasks, sections 3 and 4 are mandatory. Additional tasks apply when the contract selects them. The standard's section 5 describes tailoring the task set, so review the actual contractual requirements before defining the required analyses and deliverables.
Sources
- 1MIL-STD-882E with Change 1, System Safety · Department of Defense
- 2ASSIST-QuickSearch Document Details: MIL-STD-882 · Defense Logistics Agency
- 3Engineering of Defense Systems Guidebook, Change 2, October 2024 · Office of the Under Secretary of Defense for Research and Engineering
- 4NAVAIR safety guidance · Naval Air Systems Command
- 5DoDI 5000.88, Engineering of Defense Systems · Department of Defense
Where this shows up in our work
- LEDGER, auditable Army acquisition decisions turns a trade study into a package where every number cites its source and AI drafts but never decides.
- ELLMENT, the offline LLM for E-2D crews answers a crew's question from the aircraft's own manuals and cites the page, with no network.
- TRACE, the offline S1000D and IETM viewer opens S1000D, MIL-STD-3001 and PDF technical manuals on a tablet with every marking intact.