Risks Tab
Hazard and Failure Mode Assessment with Risk Scoring and Traceability
Overview
The Risks tab captures hazards and failure modes with severity × likelihood scoring before and after mitigation. Each risk links to the requirement that controls it via column F, completing the traceability chain: Risk → Requirement → Test. This creates a living document that demonstrates systematic risk management compliant with ISO 13485, ISO 26262, DO-178C, IEC 62304, ISO 21434, and AS9100.
Risk scoring (Severity × Likelihood) identifies risks requiring mitigation. Pre-mitigation scores justify the need for design or process controls. Post-mitigation (residual) scores document that residual risk is acceptable. RTMify's automated Status column flags risks with missing or invalid requirement links, preventing traceability gaps.
Field-by-Field Reference
The Risks tab comprises 9 columns (A–I), each with specific semantics and validation rules:
| Column | Field Name | Data Type | Example | Description |
|---|---|---|---|---|
| A | Risk ID | Text | RSK-101 or RSK-B-101 (ISO 26262) | Unique identifier for each risk. Prefix with ASIL letter (A/B/C/D) for ISO 26262 HARA. ISO 13485 may use risk numbering tied to design history file (DHF). |
| B | Description | Text (400 chars) | Loss of power leads to inability to alert operator | Concise hazard or failure mode description. For ISO 21434 cybersecurity risks, prefix with "TARA:". Include failure mode chain if relevant (cause → event → consequence). |
| C | Initial Severity | Integer 1–5 | 4 | 1=negligible, 2=minor, 3=moderate, 4=major, 5=critical/fatal. ISO 26262: maps to ASIL. ISO 13485: supports risk class determination. DO-178C: informs DAL allocation. |
| D | Initial Likelihood | Integer 1–5 | 3 | 1=very unlikely, 2=unlikely, 3=moderate, 4=likely, 5=very likely. ISO 26262: Exposure × Controllability. ISO 13485: frequency or probability. Justification must exist in design history. |
| E | Mitigation | Text (200 chars) | Implement battery backup with 24-hour autonomy; add low-power alarm circuit | Design control, process control, or requirement that reduces severity or likelihood. May be multiple controls separated by semicolon; link each to corresponding REQ in column F. |
| F | Linked REQ | Requirement ID(s) | REQ-047 or REQ-047; REQ-048 | Reference to requirement(s) that implement the mitigation. If blank, risk is uncontrolled. RTMify flags UNRESOLVED if linked REQ does not exist. Creates traceability: Risk → Requirement → Test. |
| G | Residual Severity | Integer 1–5 | 2 | Severity after mitigation is in place. Must be ≤ Initial Severity. Residual Severity = 1 means mitigation eliminates or reduces to negligible level. |
| H | Residual Likelihood | Integer 1–5 | 2 | Likelihood after mitigation is operational. Must be ≤ Initial Likelihood. Documents that design control achieves acceptable residual risk. |
| I | RTMify Status | Auto-populated (read-only) | RESOLVED or UNRESOLVED | Status indicator. UNRESOLVED if Linked REQ is empty or does not exist. RESOLVED if Linked REQ points to a valid requirement. Helps identify gaps in traceability. |
Risk Scoring: Severity × Likelihood Matrix
Risk Score = Severity × Likelihood. Multiply the values in columns C (Initial Severity) and D (Initial Likelihood) to obtain the pre-mitigation risk score. After mitigation is implemented, compute the residual risk score using columns G (Residual Severity) and H (Residual Likelihood).
5×5 Risk Matrix (Pre-Mitigation or Residual)
| Likelihood → | |||||
|---|---|---|---|---|---|
| 1 (Very Unlikely) | 2 (Unlikely) | 3 (Moderate) | 4 (Likely) | 5 (Very Likely) | |
| 5 (Critical) | 5 | 10 | 15 | 20 | 25 |
| 4 (Major) | 4 | 8 | 12 | 16 | 20 |
| 3 (Moderate) | 3 | 6 | 9 | 12 | 15 |
| 2 (Minor) | 2 | 4 | 6 | 8 | 10 |
| 1 (Negligible) | 1 | 2 | 3 | 4 | 5 |
Read: Severity (rows, 1–5 bottom-to-top) × Likelihood (columns, 1–5 left-to-right).
Risk Level Interpretation
Low (1–4)
Acceptable risk. May proceed with standard engineering practice.
Medium (5–9)
Moderate risk. Mitigation required; monitoring of residual risk needed.
High (10–15)
High risk. Significant mitigation required; design review and traceability essential.
Critical (16–25)
Critical risk. Intensive risk control; executive-level review and acceptance required.
Mitigation and Residual Risk
Pre-mitigation risk score (columns C × D) justifies the need for a control. If the score is 5 or higher, a requirement must be created to lower severity or likelihood. Residual risk score (columns G × H) is computed after the mitigation (requirement) is in place. For acceptance, many organizations require residual risk to fall into the green (1–4) or yellow (5–9) zone. Critical risks (16–25) require executive risk acceptance and continuous monitoring. ISO 13485 and ISO 26262 mandate documented risk acceptance for any risk not reduced to negligible levels.
Standards Guidance
Actions to Address Risks and Opportunities
AS9100 Rev D §6.1 requires the organization to plan and implement actions to address risks and opportunities to the quality management system. This includes determining risks and opportunities arising from external and internal issues, determining how to address them, and implementing planned actions. The Risks tab serves as a risk register documenting hazards and their mitigation. Risk-based thinking is embedded throughout the QMS; the standard is not prescriptive about which risk tool or methodology to use, but traceability from risk to requirement is essential for aerospace compliance (FAA certification).
Risk Management Integration
ISO 13485:2016 requires medical device manufacturers to establish and implement a quality management system that includes risk management (§8.1). Risk management must follow ISO 14971:2019 (Medical Devices — Application of risk management to medical devices) or equivalent. The Risks tab implements ISO 14971 hazard identification, risk estimation, risk evaluation, risk control, and residual risk evaluation.
IEC 62304 §4.2 (Software development processes) explicitly requires risk management per ISO 14971. Safety Class (A/B/C) determined by IEC 60601-1 (or IEC 61508 as fallback) drives the rigor of risk analysis. Class A = minimal risk; Class B = moderate; Class C = high. Residual risk must be documented in the Design History File (DHF) as evidence of compliance.
Safety Assessment Process (SAP)
DO-178C §2.4 defines the Safety Assessment Process (SAP), which includes system hazard analysis and allocation of Design Assurance Levels (DAL: A, B, C, D, E) to software components. Hazards are system-level; the RTMify Risks tab documents these hazards with severity and likelihood. The pre-mitigation risk score informs whether a requirement warrants DAL-A (most rigorous) through DAL-E (least rigorous) treatment. DO-178C is not strictly a risk register methodology—it emphasizes safety assessment at the system level—but hazards identified in the Risks tab feed directly into architectural requirements and DAL allocation, ensuring DO-178C compliance for aviation software.
HARA — Hazard Analysis and Risk Assessment
ISO 26262 §8 mandates Hazard Analysis and Risk Assessment (HARA) to determine Automotive Safety Integrity Levels (ASIL: QM, A, B, C, D). HARA is a top-down, systematic process:
- Hazard Identification: Identify potential system hazards (loss of function, unintended action, etc.).
- ASIL Determination: For each hazard, assess Severity (S: 1–3), Exposure (E: 1–3), and Controllability (C: 1–3). ASIL = f(S, E, C); use ASIL lookup table. ASIL D is highest; QM (quality managed) is baseline non-safety.
- Requirement Allocation: Allocate ASIL to architectural and implementation requirements. Use ASIL-prefixed Risk IDs (e.g.,
RSK-D-101for ASIL D hazard #101). - ASIL Decomposition: ASIL D can be decomposed into lower ASILs if each sub-requirement independently achieves the safety goal.
- Residual Risk Evaluation: After implementation, confirm that architectural controls achieve the target ASIL.
RTMify Risks tab supports ASIL-prefixed Risk IDs in column A. Link each risk to architectural requirements in column F. Residual ASIL is implicit in the residual risk score (columns G × H).
TARA — Threat Analysis and Risk Assessment
ISO 21434 (Cybersecurity and over-the-air updates for road vehicles) requires Threat Analysis and Risk Assessment (TARA) to identify and evaluate cybersecurity risks. TARA is similar in structure to HARA but focuses on threats and vulnerabilities rather than safety hazards. The RTMify Risks tab accommodates cybersecurity risks: prefix descriptions in column B with TARA: to distinguish them from functional safety risks. Severity maps to impact; Likelihood to threat probability. Link to cybersecurity requirements (e.g., REQ-SEC-047) in column F. Residual risk scores document post-mitigation cybersecurity posture.
Risk Integration in System and Software Engineering
ASPICE (Automotive SPICE v3.0) defines capability levels for system and software engineering processes. Risk items (SYS.1 System Requirements Definition, SWE.1 Software Requirements Analysis) feed into functional requirements. MAN.5 Management of Risk is a horizontal process requiring identification, analysis, and mitigation of project and product risks. The Risks tab fulfills both product risk (SYS.1/SWE.1 safety/security requirements) and project risk (schedule, resource, supplier) documentation. Each risk must be mapped to a requirement (column F) and tracked to test (via the Requirements tab and Tests tab). ASPICE audits expect to see this traceability chain.
Linking Risks to Requirements
Column F (Linked REQ) is the critical bridge in traceability. Each risk must be mitigated by one or more requirements. If a risk has no linked requirement, the mitigation exists only on paper—there is no way to verify it is implemented.
Traceability Chain
Risk (RSK-047) ↓ Mitigation Requirement (REQ-047: "Implement battery backup with 24h autonomy") ↓ Implementation & Verification Test (TST-047: "Verify battery lasts ≥24h under idle load") ↓ Acceptance Test Result (PASS)
RTMify Status Validation
RTMify automatically populates column I (RTMify Status) based on column F:
- RESOLVED: Linked REQ exists and points to a valid requirement in the Requirements tab.
- UNRESOLVED: Linked REQ is empty, contains a non-existent requirement ID, or points to a deleted requirement. RTMify flags this to prevent incomplete traceability.
Multiple Mitigations Per Risk
Some risks may require multiple requirements to achieve acceptable residual risk. For example:
Risk: RSK-102 "Loss of communications" Mitigation: "Implement redundant comm paths and watchdog timer" Linked REQ: REQ-053; REQ-054 (REQ-053: "Implement dual CAN bus architecture") (REQ-054: "Implement 500ms watchdog timeout")
Separate multiple requirement IDs with a semicolon (and space). RTMify validates each ID independently.
Orphaned and Dangling Risks
Orphaned Risk: A risk with no Linked REQ (column F is empty). This risk has been identified but no design or process control has been assigned. Decision: either assign a requirement or accept residual risk with documented justification.
Dangling Risk: A risk with a Linked REQ that does not exist (e.g., REQ-047 is listed but does not appear in the Requirements tab). RTMify marks this UNRESOLVED. Corrective action: either create the missing requirement or remove the broken link.