Building Your Risk Management File Under ISO 14971

The risk management file is not a document — it is a record

One of the first things to understand about ISO 14971 is that the "risk management file" is not a single document you write and submit. It is a collection of records that demonstrate your risk management process was actually carried out — and is still being carried out. That distinction matters because many manufacturers produce a polished risk document at the end of development and call it done. Notified Bodies and auditors can tell.

The file must contain: your risk management plan, records of hazard identification and risk analysis, your risk evaluation decisions, records of risk control measures and their verification, residual risk assessments, the benefit-risk determination, and records of post-production information that feeds back into the process. Producing these as a coherent set — one that traces a device's risks through its lifecycle — is the actual task.

Starting with the risk management plan

Before you analyse anything, write a plan. The plan scopes the process: which device, what intended use and reasonably foreseeable misuse, the intended user population, what risk acceptability criteria you will apply, and who is responsible for what. Teams often skip or underweight the plan because they want to get to the analysis. This is a mistake — the plan is what allows an auditor to evaluate whether your analysis was thorough and whether your acceptability decisions are coherent.

The risk acceptability criteria in particular deserve attention. You need to define these in the plan, not decide them after the analysis. Criteria based purely on probability × severity matrices are common but often inadequate — ISO 14971:2019 puts significant weight on state of the art and the expectation that all risks are reduced as far as possible (ALARP), not just brought below a numeric threshold. Getting this right in the plan prevents later arguments about whether a residual risk was actually acceptable.

Hazard identification and risk analysis

This is where the real work of risk management happens — and where the depth of your thinking will be most visible to a reviewer. Start with the intended use and intended users, then work through foreseeable misuse. Use a structured approach: energy-based hazards, biological hazards, software hazards, environmental hazards, use error, and so on. The FMEA format (failure mode and effects analysis) is widely used and well understood, but the standard does not mandate it.

One thing that trips up a lot of teams: hazard identification stops at the device boundary. It shouldn't. Consider the use environment — home use versus clinical use has very different risk profiles for the same device. Consider the user — a trained clinician and a lay person are not the same population. And consider the interaction with other devices or therapies. Narrow hazard identification produces a narrow risk file, and a narrow risk file leaves gaps that clinical evidence or post-market data later has to explain.

Each identified hazard needs an associated harm, an estimate of probability of occurrence of that harm, and a severity classification. Document your reasoning, not just your conclusions — especially for probability estimates, which are often based on judgment rather than data.

Risk control and the hierarchy

When you have analysed the risks, the next step is control — and the order matters. ISO 14971 requires you to follow a hierarchy: inherently safe design first, then protective measures (guards, alarms, technical safeguards), then information for safety (labelling, instructions for use, training requirements). Labelling and instructions are not acceptable as primary risk controls for significant risks. If a device poses a serious hazard that can only be controlled by telling users to be careful, the design hasn't adequately addressed the risk.

For each control measure, verify that it actually works and doesn't introduce new risks. Secondary risk introduction is a common oversight — an alarm that reduces the risk of an undetected fault but introduces the risk of alarm fatigue is a real trade-off that needs to be documented and evaluated.

Residual risk and the benefit-risk determination

After controls are in place, residual risks remain. The standard requires that you evaluate the overall residual risk — not just individual residuals — and determine whether the overall benefit of the device outweighs the overall residual risk. This is where many files fall short: teams evaluate each risk individually, find it acceptable, and consider the job done. The overall benefit-risk determination is a separate step with its own documentation requirement.

The benefit-risk determination should reference the clinical benefit of the device — which means it needs to connect to your clinical evaluation. A device with limited clinical evidence of benefit needs a higher bar for residual risk acceptability. This connection between the risk file and the clinical evaluation is one of the key integration points that reviewers look for.

Keeping it live

A risk management file that isn't updated after launch is incomplete. Post-production information — complaints, incident reports, post-market surveillance data, literature updates, changes in state of the art — must feed back into the risk management process. If post-market data reveals a new hazard or changes your probability estimates, the file needs to be updated and the impact on acceptability reassessed. This lifecycle obligation is not optional, and it is one of the areas most commonly flagged in Notified Body surveillance audits.