ISO 14971 is the international standard for the application of risk management to medical devices, and it is the process that sits underneath nearly every other medical device requirement. It is recognized by the FDA and harmonized under the EU Medical Device Regulation, which means that if a device is placed on a serious market, its manufacturer must be able to demonstrate a 14971-conformant risk management process across the entire life of the product. Where IEC 62304 governs the software development lifecycle, ISO 14971 governs the device risk itself, and the two interlock: the software standard explicitly draws its safety classification from the hazard analysis the risk standard produces.
The standard defines risk management as a life-cycle process, not a one-time report. It runs from establishing a risk management plan, through risk analysis, risk evaluation, risk control, evaluation of overall residual risk, and into production and post-production monitoring that feeds discoveries back into the analysis. The output is a risk management file, the living body of evidence that ties every identified hazard to its controls and its residual risk. A manufacturer does not conform to 14971 by writing a document once; it conforms by maintaining the file as the device is designed, changed, manufactured, and used in the field.
Risk analysis is where the process begins and where most of the intellectual work lives. The standard asks the manufacturer to identify the intended use and reasonably foreseeable misuse, enumerate the hazards the device could present, and for each one trace the sequence of events by which the hazard could lead to a hazardous situation and then to harm. For each hazardous situation, the risk is characterized in terms of the probability of harm occurring and the severity of that harm. This hazard-to-harm chain is the analytical heart of 14971, and it is deliberately more structured than a generic risk register: it forces the manufacturer to reason explicitly about how a failure actually reaches a patient.
Risk evaluation is the step where analysis meets judgment. For each estimated risk, the manufacturer decides, against criteria defined in the risk management plan, whether risk reduction is required. The important shift in the current edition of the standard is that it no longer speaks of an acceptable-risk threshold in the old sense; instead it drives the manufacturer to reduce risk as far as reasonably practicable and then to weigh what remains. Every risk that warrants reduction moves into risk control, and every risk that remains after control moves into the residual-risk evaluation. The discipline is in not letting any identified hazard escape this loop unexamined.
Risk control is governed by a strict order of priority that the standard makes non-negotiable. First, reduce risk by inherently safe design and manufacture. Second, where that is not sufficient, add protective measures in the device itself or in the manufacturing process. Third, and only as the last resort, provide information for safety, warnings, labeling, and training. The ordering matters because it prevents the common shortcut of papering over a design hazard with a warning label. A control measure must itself be verified as implemented and validated as effective, and the standard requires the manufacturer to check that new controls have not introduced new hazards, closing the loop so that risk control does not quietly create fresh risk.
Residual risk and the benefit-risk judgment are where 14971 refuses to pretend that risk can always be eliminated. After all individual controls are applied, the manufacturer must evaluate the overall residual risk of the device as a whole, not just hazard by hazard, because a device that is acceptable on every individual risk can still carry too much aggregate risk. Where a residual risk remains, the standard requires a benefit-risk analysis: does the medical benefit the device delivers outweigh the residual risk it carries? That judgment, documented and defensible, is often the crux of a regulatory submission, because it is the manufacturer stating plainly why a device with known residual risks should nonetheless reach patients.
Production and post-production is the phase teams most often underweight, and the standard treats it as integral rather than optional. The risk management process does not end at release. The manufacturer must collect and review information from manufacturing and from the field, complaints, adverse events, and production data, and feed it back into the risk analysis. New information can invalidate an earlier risk estimate, reveal a hazard that was not foreseen, or shift a benefit-risk conclusion. A risk management file that is frozen at launch is a file that has stopped conforming; the standard expects it to keep breathing for as long as the device is on the market.
The connection to the software lifecycle is direct and worth making explicit. IEC 62304 assigns each software item a safety class based on the severity of harm a software failure could cause, after considering external risk control measures, and both the harm severities and those external controls come straight out of the 14971 hazard analysis. A team that runs its risk management well hands its software team a clean, traceable set of hazards and controls to classify against. A team that treats 14971 as a compliance afterthought forces its software team to guess at classifications that should have been derived. The two standards are designed to be operated together, with the risk file feeding the software process.
Keeping the risk management file traceable and current across a changing device is exactly the problem methodology-native tooling is built to solve. Hitt Hosting SE's Medical Device pack treats hazards, hazardous situations, risk controls, and residual-risk judgments as first-class, linked data rather than a spreadsheet that drifts out of date. Each control links to the requirement and verification that implement and prove it, each hazard links to the software items and design elements it touches, and a change to a control or a requirement flags the affected risks for reassessment. The risk management file a regulator asks to see is generated from the live data, so it reflects the device as it actually is rather than as it was at the last manual update.