Core Identity Fields
| Name | Type | Default | Description |
|---|
| ID | String | Auto-generated | Unique identifier for the risk record (e.g., RR-001) |
| Title | String | Required | Descriptive title of the risk being assessed (e.g., “Sensor failure in adverse weather”) |
| Description | Text | Optional | Detailed narrative describing the risk scenario and context |
| Status | Enum | Draft | Current lifecycle state: Draft, In Progress, In Review, Pending Approval, Approved, Rejected, Obsolete |
| Assignee | User | Optional | Team member responsible for risk assessment and mitigation tracking |
| Created | DateTime | Auto | Timestamp of risk record creation |
| Modified | DateTime | Auto | Timestamp of last modification |
Risk Scenario Definition
| Name | Type | Default | Description |
|---|
| Hazardous Situation | Text | Required | Text field capturing the scenario where a hazard combines with operational context to create potential for harm. Describes the specific conditions and sequence of events. Example: “Vehicle traveling at highway speed when forward-looking camera detects obstacle but ECU processing delay prevents timely brake signal transmission to ABS module.” |
| Severity | Enum | — | Harm severity classification (e.g., Catastrophic, Critical, Marginal, Negligible) typically linked from related Harm or Hazard work items. Describes consequences if the risk materializes. |
| Benefit | Text | Optional | Field for documenting clinical or operational benefits when performing risk/benefit analysis. Required for medical device scenarios where risk acceptance depends on benefit justification (ISO 14971 Annex C). Example: “AEB system provides collision avoidance benefit even with residual latency risk.” |
Pre-Mitigation Probability Assessment
The three-probability model implements ISO 14971 risk analysis methodology, allowing fine-grained assessment of where risk reduction measures should focus.
| Name | Type | Default | Description |
|---|
| P1 (Pre-Mitigation) | Enum | — | Probability that the hazardous situation will occur (hazard probability). Scale: 0.0–1.0 or categorical (e.g., Remote, Low, Moderate, High). Reflects likelihood of hazard occurrence independent of harm. |
| P2 (Pre-Mitigation) | Enum | — | Probability that, given the hazardous situation, harm will result (conditional probability). Addresses whether exposed parties can escape or mitigate consequences. Scale: 0.0–1.0 or categorical. |
| Control Probability (Pre-Mitigation) | Enum | — | Probability that existing safety controls will successfully prevent or mitigate the risk. Represents effectiveness of current design or process controls before additional risk controls. Scale: 0.0–1.0 (inverse logic: 1.0 = fully effective control). |
| Pre Risk | Enum | Computed | Overall pre-mitigation risk level derived from severity combined with P1, P2, and control probability. Typically: High, Medium, Low based on risk matrix lookup. Computed via Risksheet formula or manually assessed. |
Example Pre-Mitigation Assessment:
Hazard: Sensor failure in rain
P1 = 0.15 (Low probability of rain event + sensor exposure)
P2 = 0.8 (High probability of collision if sensor fails during rain)
Control = 0.6 (Current redundancy check catches 60% of failures)
Pre Risk = High (because P2 is high despite low P1)
Post-Mitigation Probability Assessment
After risk controls are defined and implemented, post-mitigation values document the achieved risk reduction.
| Name | Type | Default | Description |
|---|
| P1 (Post-Mitigation) | Enum | — | Revised probability of hazardous situation after risk controls are implemented. May decrease if controls reduce hazard occurrence (e.g., improved sensor reliability, redundancy). |
| P2 (Post-Mitigation) | Enum | — | Revised probability of harm given hazard, after mitigation. May decrease if controls improve escape/response (e.g., faster braking response, operator warnings). |
| Control Probability (Post-Mitigation) | Enum | — | Revised effectiveness of safety controls post-implementation. Should improve from pre-mitigation value if new controls are added. Example: 0.92 after adding watchdog timer and diagnostic coverage improvements. |
| Post Risk | Enum | Computed | Residual risk level after all controls implemented. Computed from post-mitigation probabilities using same risk matrix. Must meet acceptance criteria for risk to be closed. Example values: Acceptable, Conditional, Unacceptable. |
Example Post-Mitigation Reassessment:
Same hazard with new controls:
P1 = 0.08 (enhanced sensor shielding reduces exposure)
P2 = 0.5 (predictive mode warning gives driver 2s response time)
Control = 0.95 (added triple-redundant detection with 95% coverage)
Post Risk = Low (significant reduction achieved)
Risk Acceptance and ALARP Determination
| Name | Type | Default | Description |
|---|
| Risk/Benefit Result | Enum | — | Formal decision whether benefits outweigh risks (for medical devices or safety vs. availability trade-offs). Values: Benefits Justify Risk, Risk Marginally Acceptable, Risk Unacceptable, Deferred for Further Analysis. Required when benefit field is populated. |
| Additional Controls Possible | Enum | Yes | Boolean (yes/no) indicating whether further risk reduction measures are technically or economically feasible. Implements ALARP principle: “Yes” means cost-benefit justifies further mitigation; “No” means state-of-the-art limits reached or cost disproportionate. |
| Final Risk | Enum | — | Ultimate risk acceptance decision after considering post risk, ALARP principle, and risk/benefit result. Values: Accepted, Conditionally Accepted, Not Accepted, Deferred. Completes risk management lifecycle and indicates workflow progression. Document must answer: Is residual risk acceptable? |
| Justification | Text | Optional | Narrative justification for final risk decision, especially when “Not Accepted” or when additional controls are deemed not feasible. Should reference standards compliance (ISO 14971 equivalence to HARA ASIL, FMEA action priority) and business rationale. |
| Post Risk | Additional Controls Possible | Risk/Benefit Result | Final Risk Decision |
|---|
| Acceptable | No | — | Accepted |
| Acceptable | Yes | — | Conditionally Accepted (may pursue further mitigation) |
| Unacceptable | No | Benefits Justify | Conditionally Accepted (risk/benefit exception) |
| Unacceptable | No | Risk Marginally Acceptable | Conditionally Accepted (ALARP satisfied) |
| Unacceptable | Yes | — | Not Accepted (further controls required) |
Traceability and Relationships
Risk Records connect to other work item types to support comprehensive risk management traceability.
| Relationship | Target Type | Role | Description |
|---|
| Linked Hazard | Hazard | assesses | Incoming link from Hazard or Harm work item that triggered this risk record. Enables navigation from hazard identification to risk assessment. |
| Linked Safety Goal | Safety Goal | mitigated by | Link to safety goal(s) derived to control this risk. Establishes ISO 26262 Part 3 linkage. |
| Risk Controls | Risk Control | implements | Outgoing link to one or more riskControl work items defining specific mitigation measures. Tracks what controls are assigned to address this risk. |
| Related Failure Modes | Failure Mode | analyzes | May link to FMEA failure modes representing the same risk from a different analysis perspective (HARA vs. FMEA comparison). |
| Verification Evidence | Test Case | verified by | Links to test case(s) or verification activities that demonstrate effectiveness of risk controls. Supports V&V traceability requirements. |
Workflow Lifecycle
| State | Allowed Transitions | Description |
|---|
| Draft | → In Progress | Initial state when risk record is created. Assessment not yet complete. |
| In Progress | → In Review, → Draft | Risk analysis underway: probabilities being assessed, controls being defined. |
| In Review | → Pending Approval, → In Progress | Peer review active. Reviewers validate severity assessment, probability estimates, and proposed controls. |
| Pending Approval | → Approved, → In Progress | Awaiting formal risk acceptance by safety authority. All supporting evidence and justification complete. |
| Approved | → Obsolete | Risk record formally accepted with final risk decision. Controls are implemented or deferred per acceptance justification. |
| Rejected | → In Progress | Assessment rejected during review. Requires rework before resubmission. |
| Obsolete | — | Risk record no longer applicable (e.g., feature removed, design changed fundamentally). Retained for traceability audit trail. |
Custom Fields for Risk Management
Extended fields enable ISO 14971 process automation and automotive safety compliance tracking.
| Field Name | Type | Default | Description |
|---|
| Risk Category | Enum | — | Classification of risk type: Hazard Risk, Use-Related Risk, Residual Risk, Post-Market Risk. Helps organize risk records by source and lifecycle phase. |
| Applicable Standards | Multi-Select | — | Which standards govern this risk assessment: ISO 14971, ISO 26262, ISO 21448 SOTIF, AIAG-VDA FMEA, IATF 16949. Used to determine applicable severity scales and traceability requirements. |
| Risk Control References | Text | — | External references to control specifications, design documents, or process procedures implementing risk mitigation. Example: “SDS-04-250 Sensor Reliability Spec, Process WI-08 AEB Calibration.” |
| Residual Risk Documentation | Attachment | — | File uploads for risk analysis supporting evidence: calculation spreadsheets, test data, failure mode analysis reports, risk/benefit justifications. Supports compliance audit trails. |
| Risk Assessment Date | Date | — | Date on which pre-mitigation risk assessment was completed. Enables tracking of assessment freshness and triggering re-assessment intervals. |
| Reassessment Date | Date | — | Date post-mitigation risk was reassessed. Records when control effectiveness was verified. Used to schedule periodic re-evaluation per ISO 14971 lifecycle. |
Risk Record in Risksheet Contexts
Risk Records appear in two Nextedy Risksheet configurations, each with specific column layouts and workflow progression.
HAZID/HARA Risksheet Integration
Risk Records are created from Hazard work items during ISO 26262 Part 3 Hazard Analysis and Risk Assessment. The HARA risksheet captures:
- Hazardous situation (combines operational context with hazard)
- Severity, Exposure, Controllability assessment
- Automatic ASIL calculation
- Safety Goal derivation
- Link to underlying Risk Record for detailed pre/post probability assessment
Risk Control Plan Risksheet Integration
Risk Records feed the Risk Control Plan risksheet, which organizes risk controls by associated risk record:
- Lists all assigned risk controls with responsibility and due dates
- Tracks verification status (controls tested/verified)
- Displays pre-mitigation and post-mitigation risk levels
- Links downstream to Design Characteristics and Process Steps affected by controls
Risk Records are owned by Safety Engineering. Modification of pre-mitigation assessment, ALARP determination, or final risk decision requires Safety approval. Other roles (Design, V&V) can propose new controls and verify effectiveness but cannot change risk acceptance decision unilaterally.
Examples
Example 1: Sensor Failure in Adverse Weather (Medical Device Context)
<riskRecord>
<id>RR-AEB-001</id>
<title>Sensor Failure During Heavy Rain</title>
<hazardousSituation>
Vehicle traveling at 60 km/h; forward-looking camera and radar simultaneously
lose lock on obstacle due to rain showers and water spray; ECU enters degraded
mode but continues autonomous braking with reduced confidence.
</hazardousSituation>
<severity>Catastrophic</severity> <!-- Collision risk without braking -->
<benefit>
AEB system reduces collision speed by average 40%, substantially improving
occupant survival probability even if sensor temporarily degrades.
</benefit>
<!-- Pre-mitigation Assessment -->
<p1_pre>0.12</p1_pre> <!-- Low: rain events are infrequent -->
<p2_pre>0.85</p2_pre> <!-- High: if sensors fail, collision likely -->
<control_pre>0.65</control_pre> <!-- Moderate: current sensor fusion catches ~65% of failures -->
<preRisk>High</preRisk>
<!-- Post-mitigation Assessment (after adding predictive mode warning + sensor redundancy) -->
<p1_post>0.10</p1_post> <!-- Slightly better: improved sensor shielding -->
<p2_post>0.40</p2_post> <!-- Improved: predictive warning gives driver 2s response -->
<control_post>0.94</control_post> <!-- Excellent: triple-redundant detection -->
<postRisk>Acceptable</postRisk>
<riskBenefitResult>Benefits Justify Risk</riskBenefitResult>
<additionalControlsPossible>No</additionalControlsPossible>
<finalRisk>Accepted</finalRisk>
<justification>
Residual risk is acceptable per ISO 14971 Annex C risk/benefit methodology.
Benefits (40% speed reduction in collisions) substantially outweigh residual
sensor failure risk. Additional controls would require vision system upgrade
(cost $5M+) for marginal 5% improvement. State of the art for automotive
sensors limits further risk reduction without major component redesign.
</justification>
</riskRecord>
Example 2: Power Supply Failure (Automotive Safety Context)
<riskRecord>
<id>RR-AEB-002</id>
<title>12V Power Supply Loss to ECU</title>
<hazardousSituation>
Vehicle charging system fails or battery disconnects while vehicle is moving
and engaged in autonomous braking; ECU loses power, triggering uncontrolled
brake release or erratic AEB response.
</hazardousSituation>
<severity>Critical</severity>
<!-- Pre-mitigation: Minimal existing controls -->
<p1_pre>0.05</p1_pre> <!-- Very low: charge system is reliable, faults rare -->
<p2_pre>0.95</p2_pre> <!-- Very high: power loss = immediate loss of braking -->
<control_pre>0.40</control_pre> <!-- Poor: only simple brownout detection exists -->
<preRisk>High</preRisk>
<!-- Post-mitigation: Supercapacitor backup + watchdog timer -->
<p1_post>0.03</p1_post> <!-- Unchanged: failure cause not addressed -->
<p2_post>0.15</p2_post> <!-- Much improved: supercap sustains brake hold for 500ms -->
<control_post>0.98</control_post> <!-- Excellent: watchdog detects undervoltage in <5ms -->
<postRisk>Low</postRisk>
<additionalControlsPossible>No</additionalControlsPossible>
<finalRisk>Accepted</finalRisk>
<justification>
Residual risk meets ISO 26262 target ASIL B requirements. Further risk reduction
would require larger supercapacitor (space constraint in ECU enclosure) or dual
battery systems (cost and weight penalties exceed benefit). Current design with
supercapacitor backup and enhanced diagnostics represents cost-effective ALARP solution.
</justification>
</riskRecord>
Related Pages
