Safety Risk vs. Cybersecurity Risk: Two Processes, One Device

In medical device development, safety risk management and cybersecurity risk management are often discussed as if they were the same activity with different vocabulary. They are not. They answer different questions, use different inputs, and are judged against different criteria. Yet on a connected device, neither one is complete without the other. Understanding where they differ, and exactly where they meet, is one of the most practical things a manufacturer can do to build a defensible risk file and a safer product.

Two disciplines, two questions

Safety risk management under ISO 14971 asks a patient-centered question: what can go wrong with this device that could lead to harm? It works from hazards, sequences of events, and hazardous situations, and it estimates risk as a combination of the probability of harm and its severity. The output is a set of risk controls and an overall judgment that residual risk is acceptable when weighed against benefit.

Security risk management, described in ANSI/AAMI SW96 and the companion guidance in AAMI TIR57, asks an adversary-centered question: how could someone deliberately exploit this device, and what would that compromise? It works from assets, threats, and vulnerabilities, and it considers the impact on confidentiality, integrity, and availability of the device and its data.

Both are risk management. But one models failure and misuse, and the other models intent.

Why they cannot simply be merged

It is tempting to fold cybersecurity into the existing hazard analysis and call it done. That approach usually breaks down for three reasons.

First, probability does not translate well. ISO 14971 relies on estimating how likely a sequence of events is. A determined attacker does not behave like a random failure, so security assessments typically evaluate exploitability, meaning how easily a vulnerability could be exploited, instead of a statistical probability of occurrence.

Second, not every security risk is a safety risk. A breach that exposes patient data, or a compromise that lets an attacker pivot into a hospital network, may never cause physical harm through the device itself. Those risks still matter, to patients, to customers, and to regulators, and they need a home in the security risk process even though they never appear in the safety risk file.

Third, the threat landscape changes on its own schedule. New vulnerabilities are disclosed in third-party components long after a device is released. Security risk management has to be continuous in a way that a design-phase hazard analysis was never built to handle.

Where the two meet

The relationship becomes clear at the point where a security event can lead to harm. If an attacker can alter a dose, disable an alarm, corrupt a measurement, or make a therapy unavailable, that security risk has become a source of a hazardous situation. At that point it must flow into the ISO 14971 analysis, where severity and the acceptability of residual risk are judged in safety terms.

The connection runs in both directions through risk controls as well:

• A security control can create a safety risk. Strong authentication that locks a clinician out during an emergency is a classic example.
• A safety feature can create a security risk. A service mode, a debug port, or a fail-safe default can open an attack path that did not exist before.
• A single design change can affect both files at once, so each discipline needs visibility into the other's controls before either declares residual risk acceptable.

In other words, the two processes stay distinct, but they share an interface. Managing that interface well is where most of the real engineering work happens.

Making the relationship work in practice

Manufacturers that handle this well tend to build a few habits into their quality system:

• A shared system architecture and threat model that both the safety and security teams work from.
• Traceability from every security risk with potential safety impact to the corresponding hazardous situation in the ISO 14971 file.
• Joint review of new risk controls, so a mitigation in one file is checked for side effects in the other.
• Consistent criteria for when a security finding must be escalated into the safety risk analysis.
• Postmarket processes where each new vulnerability is assessed for both security impact and patient safety impact, with outcomes feeding CAPA and change control.

None of this requires merging the two processes into one document. It requires connecting them deliberately and showing that connection in the records.

The regulatory view

FDA's premarket cybersecurity guidance expects manufacturers to perform security risk management as a process distinct from safety risk management, while making sure the two are linked. The agency reissued that guidance on February 3, 2026, primarily to align its references with the Quality Management System Regulation and ISO 13485, without adding new technical expectations. ANSI/AAMI SW96 is FDA-recognized as a consensus standard for security risk management, and TIR57 remains a recognized source of implementation guidance. Notified Bodies reviewing EU MDR technical documentation look for the same thing: evidence that cybersecurity risks with safety consequences were identified, evaluated, and controlled as part of the overall risk management of the device.

Closing perspective

Safety risk management and cybersecurity risk management are partners, not substitutes. One protects patients from what can go wrong; the other protects the device from what someone might do to it. When the two are kept distinct but tightly connected, manufacturers get a clearer risk file, fewer surprises in review, and a product that holds up in a connected clinical environment. When they are blurred together or kept in isolation, the gaps show up exactly where they are most costly: in the submission, in the field, and at the patient's bedside.