Free Hazard Log Template
Your identified hazards need a living register, not a snapshot.
A free hazard log spreadsheet for medical device and regulated product development. Tracks every identified hazard from initial scoring through risk control implementation, verification, and final acceptability determination, across the full product lifecycle. Use it standalone or alongside the RTMify Requirements Tracking Template and FMEA Template. No account, no gate.
Linked REQ / Linked Risk ID / Linked FMEA ID cross-references.What a hazard log requires you to do
ISO 14971 clause 4.4 requires maintaining a risk management file throughout the product lifecycle. The hazard log is the core artifact in that file. It must capture every identified hazard, the hazardous situation and potential harm, risk scoring, control measures and their verification status, and a final acceptability determination. It is not a one-time document. It lives with the product from design through post-market surveillance.
Hazard vs. failure mode vs. harm
ISO 14971 distinguishes three levels: the hazard (source of potential harm), the hazardous situation (circumstances of exposure), and the harm (injury or damage). All three must be documented. Conflating them is a common audit finding: writing "speaker failure causes hearing loss" instead of separating the hazard (excessive acoustic energy), situation (patient wearing earpiece), and harm (hearing loss).
Risk controls must be verified
Documenting a risk control is not the same as verifying it works. The Verification Status column tracks where each control stands: Not Started, In Progress, Verified, or Failed. An unverified control is an open risk. Auditors look specifically for hazards with Unacceptable or ALARP initial risk where verification is still Not Started or In Progress.
ALARP requires justification
A residual risk at the ALARP level is not automatically acceptable. ISO 14971 requires that you demonstrate further risk reduction is impracticable or that the clinical benefit outweighs the residual risk. That benefit-risk justification must be documented in the Notes column. "ALARP" without a rationale is an audit finding.
Hazard log vs. FMEA
These two artifacts serve different purposes and operate at different levels of analysis. Both are typically required for regulated medical device development. They are designed to be used together.
Hazard log: top-level register
The hazard log lists every identified hazard and tracks it through the full risk management lifecycle: evaluation, control, verification, and final acceptability. It is the document an auditor reviews to confirm that all known hazards have been addressed. ISO 14971 clause 4.4 requires maintaining it.
Hazards come from multiple sources: preliminary hazard analysis, FMEA findings, use-case analysis, regulatory requirements, and post-market surveillance.
FMEA: bottom-up analysis method
The FMEA identifies failure modes for specific components or functions, analyzes their downstream effects, and scores them with Severity × Occurrence × Detection. FMEA findings feed the hazard log: when a failure mode analysis surfaces a new hazard, that hazard gets a row in the register.
The Linked FMEA ID column creates the explicit trace from hazard log entry back to the FMEA analysis that identified it. FMEA template →
Typical workflow: run the FMEA during design, transfer identified hazards to this log, document risk controls as requirements in the RTM, verify controls through testing, update the log with residual risk and acceptability status.
Field reference: Hazard Log tab
One row per identified hazard. If a single hazard produces multiple hazardous situations, each situation gets its own row and Hazard ID.
| Column | What goes here |
|---|---|
| Hazard ID | Unique identifier (HAZ-001, HAZ-002…). One hazard per row. If a single hazard produces multiple hazardous situations, each gets its own row. |
| Hazard | The potential source of harm. Describe the hazard itself, not the failure mode or the harm: "Excessive acoustic energy", not "Speaker driver failure" (that is a cause) and not "Hearing damage" (that is harm). |
| Hazardous Situation | The circumstance in which a person is exposed to the hazard. ISO 14971 distinguishes hazard from hazardous situation from harm; this column captures the middle link. |
| Potential Harm | The injury or damage to health that could result. Be specific about severity: "Temporary hearing threshold shift" vs. "Permanent sensorineural hearing loss." This directly informs the Severity score. |
| Initial Severity | How serious is the harm if it occurs? 1 = negligible, 5 = catastrophic. See Risk Matrix tab. Use the same scale as the RTM Risks tab. |
| Initial Probability | How likely is the hazardous situation to result in harm? 1 = remote, 5 = frequent. This is the probability of the complete sequence: cause, hazardous situation, and resulting harm. |
| Initial Risk Level | Auto-calculated from the Risk Matrix tab based on Severity and Probability: Acceptable, ALARP, or Unacceptable. See the Risk Matrix section below. |
| Risk Control Measure(s) | What has been done or will be done to reduce the risk. ISO 14971 requires controls to be considered in priority order: inherent safety by design first, then protective measures, then information for safety. |
| Risk Control Type | Design (inherent safety, eliminating or reducing the hazard by design), Protective (guards, alarms, interlocks), or Information (labeling, IFU warnings). Auditors check that you considered Design controls before falling back to Information for safety. |
| Risk Control Verification | How was the control verified? Reference test IDs, inspection records, or design review minutes. If the control is a requirement in the RTM, the Tests tab provides the verification evidence. |
| Verification Status | Not Started, In Progress, Verified, or Failed. This is the column that reveals whether your risk controls are actually confirmed effective, not just planned. |
| Residual Severity | Severity after controls are applied. Usually unchanged. Controls rarely reduce the severity of harm; they reduce the probability that harm occurs. If it changes, document why. |
| Residual Probability | Probability after controls are applied. This is where effective controls make a measurable difference. A well-designed protective measure or information control reduces the likelihood that the hazardous situation results in harm. |
| Residual Risk Level | Auto-calculated from the Risk Matrix tab. If residual risk is Unacceptable, further controls are required. If ALARP, benefit-risk justification is required in the Notes column. |
| Risk Acceptability | Final determination: Acceptable, Acceptable (ALARP with benefit-risk justification), or Unacceptable. This is a deliberate decision against criteria in your Risk Management Plan, not the same as the calculated Risk Level. |
| Linked REQ | Requirement ID from the RTMify Requirements Tracking Template. Each risk control measure should trace to a verifiable requirement (ISO 14971 §5.5). |
| Linked Risk ID | Risk ID from the RTM Risks tab (RSK-101, RSK-102…). Maps this hazard to the summary risk register for bidirectional traceability. |
| Linked FMEA ID | FMEA ID from the RTMify FMEA Template (FMEA-001, FMEA-002…). Traces back to the failure mode analysis that identified this hazard. Not all hazards originate from FMEA. Some come from preliminary hazard analysis, use-case analysis, or regulatory requirements. |
| Status | Lifecycle status: Open (identified, not yet controlled), Mitigated (controls in place, not yet verified), Closed (controls verified, residual risk acceptable), or Transferred (risk accepted by another party via labeling). |
| Notes | Rationale, regulatory citations, audit notes. Document benefit-risk justification here for ALARP determinations. Without a documented rationale, "ALARP" is not an acceptable risk acceptability finding. |
The Risk Matrix tab
The Risk Matrix tab provides a 5×5 Severity vs. Probability reference and auto-calculates risk levels for the Initial Risk Level and Residual Risk Level columns. Adapt the thresholds to your Risk Management Plan. The matrix here is a starting point, not a universal standard.
Risk is broadly acceptable. No additional controls required. Document the rationale in the hazard log.
As Low As Reasonably Practicable. Risk is tolerable only if further reduction is impracticable or the clinical benefit outweighs the residual risk. Benefit-risk justification required in the Notes column.
Risk exceeds acceptance threshold. Additional risk controls are required. If risk cannot be reduced, the hazard must be eliminated by design change.
The Severity 5 special case
The matrix treats all Severity 5 (catastrophic) hazards as at least ALARP, even at Probability 1 (remote). A Severity 5 / Probability 1 combination scores as ALARP rather than Acceptable.
This reflects a common risk management principle: catastrophic outcomes (death or irreversible serious harm) require explicit justification even when probability is very low. The formula in the Hazard Log tab is: Unacceptable if S×P ≥ 15; ALARP if S×P ≥ 6 or S ≥ 5; Acceptable otherwise. Modify the formula if your Risk Management Plan defines different thresholds.
Standards coverage
The hazard log is the primary artifact for risk management evidence across all major regulated-product standards. The specific clause, terminology, and documentation requirements differ by standard.
| Standard | Relevant clause | Why the template helps |
|---|---|---|
| ISO 14971:2019 | Clause 4.4 risk management file, §5.3–5.7 full risk cycle, §8 post-production | The hazard log is the core artifact in the ISO 14971 risk management file. Captures the complete clause 5 cycle: hazard identification, risk estimation, evaluation against criteria, control documentation, and residual risk assessment. Clause 8 post-market inputs feed back into the same log. |
| ISO 13485:2016 | §7.1 risk-based approach, §7.3.3 design inputs, §7.3.5 design verification | Hazards with Unacceptable or ALARP initial risk level must produce design inputs (§7.3.3). The Linked REQ column creates that trace. Verification Status and Risk Control Verification columns document §7.3.5 evidence. |
| IEC 62304:2006+A1 | §7 software risk management integrated with ISO 14971 | Software-specific hazards (data corruption, timing failures, UI misinterpretation) belong in the hazard log alongside hardware hazards. Software safety classification (A/B/C) drives which lifecycle activities are mandatory. Note the safety class in the Notes column for software-related hazards. |
| AS9100 Rev D | §6.1 actions to address risks and opportunities, §8.3.5 design verification | AS9100 does not mandate a hazard log by name, but it is standard practice for product-level risk tracking in aerospace programs. The log provides the evidence trail from risk identification through control verification that auditors expect under §6.1 and §8.3.5. |
| ISO 26262:2018 | Part 3 §7 Hazard Analysis and Risk Assessment (HARA) | HARA produces safety goals and ASIL assignments that feed this register. Note the ASIL in the Notes column for each hazard. For automotive, "Probability" maps to the Exposure and Controllability components of ASIL determination. The hazard log tracks safety goals through functional safety concept, technical safety requirements, and verification. |
Using this alongside the RTM and FMEA templates
The hazard log connects to both the RTMify Requirements Tracking Template and the RTMify FMEA Template through three cross-reference columns and a shared scoring scale.
References requirement IDs (REQ-001…) from the RTM Requirements tab. Each risk control measure should trace to a requirement that can be verified in the test plan.
References risk IDs (RSK-101…) from the RTM Risks tab. Creates bidirectional traceability between the detailed hazard log and the summary risk register.
References FMEA entries (FMEA-001…) in the RTMify FMEA Template. Traces each hazard back to the failure mode analysis that identified it, where applicable.
Severity and Probability use the same 1–5 scales as the RTM Risks tab and the FMEA template. Risk assessments across all three documents are directly comparable.
Download the hazard log template
Free hazard register for ISO 14971, ISO 13485, IEC 62304, AS9100, and ISO 26262. Works in Excel and Google Sheets.