ISO 14971 is the risk management standard for medical devices. It describes how hazards are identified, risks estimated and evaluated, and risks brought under control across the life cycle of the device. The accompanying guidance is ISO/TR 24971.
The MDR requires risks to be reduced “as far as possible” (Annex I, section 2). That means not merely reaching an acceptable level, but going to the lowest level achievable without adversely affecting the benefit-risk balance. Whether your risk acceptance criteria reflect that approach is one of the first things an auditor looks at.
What is in the risk management file?
The file is a chain that follows the life cycle of the device:
- Plan and acceptance criteria — scope, responsibilities, risk acceptability criteria and the method of verification.
- Hazard analysis — hazards, hazardous situations and harms, based on the intended purpose and reasonably foreseeable misuse.
- Risk estimation and evaluation — a justified estimate of probability and severity.
- Risk control — inherently safe design first, then protective measures, and information for safety last. The MDR sets that order in Annex I.
- Verification — evidence that each control measure was implemented and is effective.
- Overall residual risk and benefit-risk evaluation — assessed in total, not measure by measure.
- Production and post-market information — complaint, nonconformity and literature data flowing back into the file.
Links with other files
Risk management is not a folder that works on its own. Clinical evaluation, biocompatibility, usability and software files feed the risk file; risk control measures in turn shape verification and validation plans. Those links have to be traceable in the file: from a harm you should be able to reach the relevant test report.
What it covers
- Risk management plan and acceptance criteria
- Hazard analysis; design, usability and process risks (including FMEA)
- Implementation of risk control measures and verification of their effectiveness
- Overall residual risk and benefit-risk evaluation, risk management report
- Keeping the file current with production and post-market data
How are risk acceptance criteria written?
ISO 14971 asks for the criteria used to decide risk acceptability to be written in the risk management plan up front. The most common mistake is to multiply probability by severity and treat everything below a threshold as acceptable. The MDR does not regard that as sufficient on its own: Annex I, section 2 requires risks to be reduced as far as possible.
Writing the criteria means justifying several things: what each severity and probability step corresponds to, which combinations demand further control, and which clinical benefit balances the residual risk you accept. If the probability estimate is not based on numerical data, say so — a weak estimate is not the problem, hiding it is. The accompanying guidance, ISO/TR 24971, gives examples of how those decisions can be documented.
Usability, software and cybersecurity
A significant share of harms comes not from the device failing but from it being used incorrectly. IEC 62366-1 treats use error as a source of hazard and ties the usability engineering file to the risk file: use scenarios, critical tasks, formative and summative usability studies.
If the device contains software, IEC 62304 applies. The software safety class (A, B, C) follows the severity of the possible harm and determines how deep the life cycle activities have to go. If the software is connected to a network, cybersecurity is part of the risk file too; the guidance used in Europe is MDCG 2019-16.
These files may sit in separate folders but they are links in one chain: the outputs of biocompatibility and validation work are tied to the same risk file.
When do you reopen the file?
Risk management is not a one-off exercise. Typical events that reopen the file: a design or material change, a new supplier, a change in the manufacturing process, a new complaint type or an increase in complaint frequency, a new harm reported in the literature, safety notices on similar devices, and an extension of the intended purpose.
Each time, it is not only the affected line that is reviewed but also the control measures it touches and the overall residual risk evaluation. Whether the change counts as a significant change is assessed separately; if it does, the notified body has to be notified.
How do production and post-market data return to the file?
The last step of the standard is the weakest link in most files. Nonconformities from production, complaints, service records and new findings in the literature have to be collected at a defined frequency and compared with the assumptions in the file: is the probability we estimated confirmed in the field, has a harm appeared that we did not foresee?
Where this works, the comparison runs on the same calendar as the post-market surveillance report and its output is written in two places: the updated section of the risk management report and, where needed, a new control measure. If data is collected but never leads to a decision, the loop is not closed — and that is how an auditor reads it.
Common problems
The most common finding is a risk file closed when the design was finished and never opened again. Complaints, production nonconformities and new harms reported in the literature should flow back into it. Another is treating warnings on the label as a risk control measure on their own. The MDR asks for safety by design first, then protective measures, and information to the user last.
