Iso 14971 Risk Assessment Template

Building a Functional Risk Assessment Template for ISO 14971

Most people think ISO 14971 compliance is about filling out a form correctly. It isn't. The form is the last step. The actual work happens before you open any spreadsheet. You need to understand the device well enough to predict where it will fail, who it will harm, and how often that failure might occur. Then you build a template around that understanding instead of building a generic one and trying to make the device fit it. The template itself is straightforward if you stop overcomplicating it. Here are the columns that actually matter, in this order: Column 1: Hazard identification. What can go wrong? Not the failure mode. The hazard itself. Electrical shock, biological hazard, software error leading to incorrect dosage. Be specific. "Device malfunctions" is useless. "Software fails to display low battery warning, causing unexpected shutdown during a procedure" tells you exactly what to mitigate.

Column 2: Situation that produces the harm. This is the bridge between the hazard and the outcome. A lot of people skip this or merge it with the hazard. They shouldn't. The situation matters because it determines your estimation of probability. A hazard that exists only in a maintenance scenario has a completely different probability profile than one present during normal use. Column 3: Harm to people. Injury, not damage to property. Death, tissue damage, allergic reaction, psychological harm, extended procedure time leading to complications. If you're writing "financial loss" here, you've already lost the room. ISO 14971 is about patient and user safety, not warranty claims. Column 4: Estimated severity. Use a consistent scale. I use S1 through S4. S1 is negligible. S4 is death or permanent severe injury. The scale should match your intended use and regulatory environment. Medical device software in the EU under MDR needs a severity scale that maps cleanly to clinical impact classifications. Don't just copy someone else's scale without checking it against your actual risk analysis.

Column 5: Estimated probability of occurrence. This is where most templates become worthless. Probability isn't a guess. It's derived from historical data, failure mode data from similar devices, or component supplier documentation. If you don't have data, state that explicitly and use a qualitative estimate with a justification. "Because it hasn't failed yet" is not a justification. I once had a reviewer reject my probability estimate for a software watchdog timer with a single sentence: "No field data referenced." That was fair. I had to go back to the embedded development team and pull the FIT rate tables from their component supplier. Took three weeks. Column 6: Initial risk estimate. Severity crossed with probability. Most people use a simple matrix. A 5x5 matrix works fine for initial screening. But I recommend a 4x4 at most. The extra granularity in a 5x5 creates a false sense of precision. Risk matrices compress continuous data into arbitrary cells. The difference between a risk in cell (3,4) and cell (4,3) is meaningless numerically, but reviewers treat it like it matters. Column 7: Is the risk acceptable? This is where most templates fail structurally. Acceptability isn't a column. It's a decision point that requires evidence. The column should instead be labeled "Justification for residual risk acceptability." One sentence isn't enough. Reference the mitigation measures applied, the standards relied upon, and the clinical benefit that justifies accepting whatever risk remains.

Column 8: Mitigation measures. Inherent safe design, protective measures, information for safety. These are the three categories ISO 14971 recognizes. You should show the hierarchy. If you've achieved a risk reduction through inherent design, that's preferable to relying on a warning label. The template should make this obvious. Color-code the rows by mitigation type if you have to. I color-code mine. It helps during review. Column 9: Residual risk estimate. After mitigation, what's left? Re-estimate severity and probability. Severity usually doesn't change. Mitigation rarely changes how bad the harm is. It changes how likely the harm is. But there are exceptions. A redundant system changes severity because it changes the failure mode entirely. Don't assume probability drops and severity stays constant. Check both. Column 10: Overall residual risk. Is it still acceptable? Same requirement as column 7. Evidence-based justification.

The Edge Case Nobody Prepares For

Here's a specific problem I ran into that isn't covered in any template guide. You're assessing risk for a device with both active and passive modes. An infusion pump, for example. Active mode: delivering medication. Passive mode: sitting in a line, fluid gravity-feeding when power is lost. The hazard profiles are different. The same failure mode — a valve sticking closed — produces different situations and different harm in each mode. Your template needs to handle this without creating duplicate rows that confuse reviewers. My workaround was to add a Mode of Operation column before the hazard identification column, then reference it throughout. Each row specifies whether it applies to active, passive, or both. It adds one column but prevents the alternative, which is branching your entire risk file into two documents. Reviewers hate that. They want a single traceable thread from hazard to residual risk, and they want to see the operating context clearly attached to each entry. Another thing: your template should have a section for composite risk. ISO 14971:2019 explicitly requires you to assess risks arising from the combination of multiple hazards and their interactions. A battery failure that disables a warning alarm while simultaneously causing an incorrect dosage is a composite event. Most templates don't account for this because combining probabilities multiplicatively gets messy fast. I handle it by adding a separate tab in the spreadsheet for composite scenarios. The main template tracks individual hazard chains. The composite tab tracks interactions. Cross-reference them with unique identifiers so reviewers can follow the logic.

What Most People Get Wrong

They treat the template as the deliverable. It isn't. The deliverable is the risk file, and the template is just a format for capturing decisions. Auditors know this. They'll flip past your nicely formatted spreadsheet and ask to see the raw data behind your probability estimates. If you can't produce the source documentation, the template looks like window dressing. Keep your sources organized in linked files or a referenced appendix. "Supplier qualification report SR-2024-087, section 4.3" is better than "per supplier data." Another common error: using the same severity scale for software and hardware hazards. They shouldn't be the same. Software hazards often propagate differently. A software glitch might not cause immediate physical harm but could cascade into a wrong dosage after several iterations of user interaction. The severity might be moderate (S2), but the probability estimate needs to account for the interaction complexity. A hardware short circuit is more direct. Match your severity assessment to the mechanism of harm, not just the outcome. You also need a benefit-risk analysis section. ISO 14971 requires you to weigh the remaining risk against the clinical benefit. This isn't optional. Some teams treat it as an afterthought and write one paragraph at the end. It should appear alongside each significant residual risk, not buried in a summary document. When a reviewer sees a high-severity residual risk with no benefit analysis attached, they assume you haven't done the analysis. Make them look for it, and they'll note it as an observation.

Limitations to Be Honest About

This template approach works well for Class IIa and some Class IIb devices. It starts breaking down for Class III and implantable devices where the consequence of failure is fundamentally higher and the evidence requirements are stricter. For those, you may need to supplement the spreadsheet with FMEA documentation, fault tree analysis, or even failure effect analysis depending on the hazard type. The template alone won't satisfy the technical documentation requirements. Don't try to force it. Another limitation: templates become outdated quickly if your regulatory environment changes. The 2019 revision of ISO 14971 introduced software documentation references and composite risk requirements that older templates don't address. If you're working with a legacy template from 2007, you're going to miss several requirements. Check the revision date on any template you adapt from another company or consultant. I've seen templates that reference ISO 14971:2007 still being used in 2024. That's a regulatory gap waiting to happen. If you need a starting point, the structure I described above is standard enough that you can build it in any spreadsheet tool. You don't need specialized software for most devices. Specialized risk management software becomes necessary when you have thousands of risk entries, complex traceability requirements, or multiple product families sharing a common risk library. Until then, a well-structured Excel file with proper version control and backup is sufficient.

The file should include a changelog. Every time you add a hazard, revise a probability estimate, or close a risk control measure, log it with a date and a reason. Reviewers will check this. If your risk assessment shows no changes across a two-year development cycle, they'll assume you didn't do ongoing risk analysis, which is a requirement under ISO 14971. The template isn't a static document. It's a living record.