ISO 14971 vs AAMI SW96: Safety Meets Security Risk

Direct Answer

How do ISO 14971 and AAMI SW96 work together?

ISO 14971 governs safety risk. ANSI/AAMI SW96, with AAMI TIR57 as its process companion, extends that framework to cybersecurity. Because a deliberate attacker has no failure rate, SW96 uses exploitability in place of probability. Security risk is found in the threat model, scored in the security risk assessment, and the patient-harm residual is transferred back into the 14971 file for one benefit-risk decision.

Safety risk and security risk are distinct disciplines that meet in one place: patient harm. They are not two separate bodies of work. They are one traceable chain, threat to control to test to residual risk, and that chain is what an FDA reviewer grades.

Last reviewed: October 2026 against the FDA "Cybersecurity in Medical Devices" final guidance (Feb 3, 2026), ISO 14971:2019/A11:2021, AAMI TIR57:2016/(R)2023, ANSI/AAMI SW96:2023, and IEC 81001-5-1:2021.

At a glance

ISO 14971 is the international standard for medical device risk management. It defines the vocabulary everyone else borrows: hazard, harm, severity, risk control, residual risk, and the overall benefit-risk judgment. It expresses risk as the severity of a harm combined with its probability, and that probability comes from failure-rate and historical data.

ANSI/AAMI SW96 was written to extend 14971 to cybersecurity, which is why the two are almost always named together. SW96 keeps the same risk equation but uses exploitability, how feasible it is for an attacker to reach and abuse a weakness, as the accepted proxy for probability (SW96, Note 2 to the risk definition). The FDA points to both SW96 and TIR57 as the basis for a security risk management plan and report.

Two parallel lanes, safety (ISO 14971) and security (SW96 / TIR57), converging at a shared harm taxonomy that feeds a single benefit-risk acceptance decision.

Working template: download our Harm Taxonomy Template (CSV), a starting harm scale with severity anchors, ownership column, and cross-references for both the safety risk file and the security risk report.

How the standards stack

Think of it as layers. ISO 14971 is the safety foundation. SW96 and TIR57 add cybersecurity on top and transfer their results back into it. Beneath them, IEC 62304 and IEC 81001-5-1 govern the software lifecycle, so the controls the risk process calls for actually get built and verified.

Security needs its own process rather than a line item in the safety file for one reason: probability does not carry over. There is no reliable way to calculate the chance that a human attacker will choose to act, and the FDA says so directly. Forcing security findings into a 14971 probability column is one of the fastest ways to get a deficiency.

The side-by-side mapping

Dimension	ISO 14971 (safety)	ANSI/AAMI SW96 (security)
Trigger	Unintended event: use error, failure, environment	Deliberate attacker action
Where risk is found	Hazard analysis	Threat model (for example, STRIDE per element)
Likelihood term	Probability (P1 x P2) from failure-rate data	Exploitability (for example, CVSS v4.0 exploitability metrics)
Second axis	Severity of harm	Severity of harm on the safety matrix; security impact on the security matrix
Risk vocabulary	Initial risk, risk controls, residual risk	Uncontrolled risk, risk controls, controlled risk
Acceptability driver	Benefit-risk in clinical context	Same benefit-risk, plus the FDA controlled vs uncontrolled gate
Primary record	Risk Management File	Security risk management report
FDA touchpoint	Always required	Required for cyber devices under FD&C Act Section 524B

The likelihood term is where the two differ. The harm is where they meet.

Two matrices, one shared factor

A common mistake is to think severity is the shared factor and the security score is simply severity times exploitability. In practice the security assessment runs two matrices:

Safety matrix: exploitability combined with severity of harm from the 14971 scale. This scores patient-harm risk.
Security matrix: exploitability combined with security impact, the effect on the device itself (confidentiality, integrity, availability) rather than on the patient.

Exploitability is the one factor genuinely shared by both. Severity of harm belongs to the safety side only, and security impact belongs to the security side only. Keeping the scales distinct until they are combined keeps the assessment honest, and it is one of the things reviewers look for.

Exploitability is not a second score borrowed into 14971 because it happens to exist. It fills the likelihood slot of the 14971 equation itself, measured as attack feasibility instead of statistical probability.

Set the acceptance criteria before scoring

Before any threat is scored, a security risk management plan, the governing document SW96 and TIR57 call for, fixes the scope, roles, methods (STRIDE, the exploitability rating, the 14971 severity scale, and the risk matrix), and the risk acceptance criteria. Those criteria belong to the manufacturer.

A typical line: Low and Medium residuals are controlled; High and Very High are uncontrolled until reduced. A manufacturer with a different risk appetite draws different lines, but draws them first. Fixing them before scoring stops a risk being argued down to fit a deadline.

Controlled vs uncontrolled residual risk

Controlled: the residual risk of patient harm falls within the manufacturer's predefined acceptability criteria. It can remain in the device, documented with justification.
Uncontrolled: the controls in place are not enough. It cannot be documented and left alone; it must be remediated. In a fielded device, the FDA's postmarket framework generally treats an uncontrolled risk as reportable under 21 CFR Part 806, with defined remediation timelines.

Exploitability is expected to rise over a device's life, so a controlled risk has to be justified across the lifecycle, not just at submission. Anything in CISA's Known Exploited Vulnerabilities catalog is already being exploited and is designed out rather than accepted.

Where security risk hands back to safety

Once a threat's residual risk is understood, its patient-harm result is transferred into the ISO 14971 risk management file. That is the mechanism SW96 exists to define. The device's overall benefit-risk picture then accounts for cybersecurity alongside every other hazard, in the same file a reviewer uses to judge whether the device is safe overall. The method for that transfer, and the criteria for pre- and post-control scoring, are documented and included in the submission.

The most common deficiency here is subtle: the safety file and the security report use inconsistent harm definitions, or security risks never reach the safety file at all. The fix is one harm taxonomy, owned by the safety team and referenced by ID from the security side, so a severity value means the same patient outcome in both places.

Where the FDA 2026 guidance lands

The February 3, 2026 final guidance is explicit on three points relevant to this fit:

Threat modeling is required and must feed the security risk assessment.
Security risk management is a parallel process to 14971 safety risk management, not a substitute. Both are expected in the submission.
The controlled vs uncontrolled determination drives postmarket action. A new vulnerability that pushes a controlled risk into uncontrolled territory starts the postmarket remediation and reporting path, regardless of what the safety file said before.

That is why harm alignment matters operationally, not just for the submission. Postmarket teams use the same scales years after launch to decide whether a new CVE needs a report.

A worked example: a wireless infusion pump

This is an illustrative case, not a specific client engagement.

Threat (STRIDE per element): spoofing on the pump's wireless data flow. An attacker impersonates the controller and issues a dose command. The threat becomes a row in the threat table, tied to a wireless penetration test case and to the harm.

Before any control: high exploitability against a catastrophic harm lands in the Very High cell of the safety matrix. Uncontrolled.

Control 1: mutual authentication over TLS 1.2 with a named cipher suite. This is a design control, not a labeling note, and it lowers exploitability from High to Medium. At catastrophic severity the residual is still High: not controlled. One authentication control alone cannot bring a catastrophic harm to an acceptable residual.

Control 2: an out-of-band pairing step. The pump no longer accepts commands from the general hospital network, only from a control station that has completed a short-range proximity handshake. Exploitability drops to Low.

Residual: Medium, controlled, accepted with documented justification and transferred into the ISO 14971 file.

The threat table row carries all three scores, the test, the result, and the final residual-risk decision: one traceable line from a wireless interface to a patient harm, worked through two rounds of control before it clears the bar. If a later vulnerability disclosure touches either control, the row is rescored against the same criteria.

How Blue Goat Cyber approaches this

We treat hazard analysis convergence as a build-time problem, not a documentation problem. For a step-by-step version, see our risk methodology in plain language. On every submission we ship:

A single harm taxonomy owned by the safety/RA lead, referenced by ID from both files.
A security risk management plan with acceptance criteria approved before any threat is scored.
A security risk management report that uses the SW96 vocabulary explicitly (uncontrolled risk, controlled risk, residual acceptability), with exploitability and severity kept on separate scales until combined.
Bidirectional traceability from threat model -> SRMR -> RMF -> benefit-risk, with every link auditable.
An overall residual risk section in the RMF that explicitly cites the SRMR's controlled risk decisions.
For devices with a Predetermined Change Control Plan, a PCCP cybersecurity appendix that maps each planned change to the threat model and risk rows it can affect, with the triggers that force a full reassessment.

We use the same approach in our threat modeling services and in the Controlled Risk Classifier tool, which applies the controlled/uncontrolled gate to a single vulnerability so postmarket teams can triage CVEs against the same harm scale used premarket.

Want to score a finding yourself? Try the free CVSS v4.0 calculator for medical devices, which gives the vector string and a High, Medium, or Low exploitability rating.

FAQ

Is AAMI TIR57 still current, or has SW96 replaced it?

Both are current and complementary. TIR57:2016/(R)2023 is the Technical Information Report - the explanatory document. ANSI/AAMI SW96:2023 is the normative standard, and the FDA points to both as the basis for a security risk management plan and report. Use SW96 as the standard you conform to and TIR57 as the implementation guidance.

Can I just extend my 14971 RMF to cover cybersecurity?

Not by adding security rows to the probability column. Security needs its own process because a deliberate attacker has no failure rate. The threat model and security risk report are inputs to your 14971 process, not a parallel silo: their patient-harm residuals transfer into the 14971 file, and both sides share one harm taxonomy.

How is scoring exploitability instead of probability compatible with ISO 14971?

The 14971 equation has two inputs: how likely the harm is and how severe it is. Severity comes straight from your 14971 assessment and does not change. Exploitability fills the likelihood slot, measured as attack feasibility rather than statistical probability. SW96 permits this proxy in Note 2 to its risk definition.

Where does IEC 81001-5-1 fit?

IEC 81001-5-1 is the lifecycle process standard - it describes how to run security activities across the development lifecycle (requirements, design, implementation, verification, release, postmarket). TIR57 / SW96 describe what the risk content looks like. They are complementary, not competing. See our IEC 81001-5-1 security risk assessment guide for the lifecycle view.

What about postmarket?

Premarket uses TIR57 / SW96. Postmarket uses AAMI TIR97 plus the FDA postmarket cybersecurity guidance. The harm taxonomy carries over. The controlled vs uncontrolled risk gate is what drives the postmarket remediation and reporting decision. See our TIR57 vs TIR97 comparison.

What is the most common FDA deficiency on this topic?

Inconsistent harm definitions between the safety RMF and the security SRMR, followed by security hazards that never trace into the safety file at all. Both are avoidable when one harm taxonomy is referenced by ID from both sides.

Where this fits in the cluster

Sources

Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions - U.S. Food and Drug Administration, Feb 3, 2026
ANSI/AAMI SW96:2023 - Medical device security - Security risk management for device life cycle - AAMI/ANSI
AAMI TIR57:2016/(R)2023 - Principles for medical device security - Risk management - AAMI
ISO 14971:2019 - Medical devices - Application of risk management to medical devices - ISO
IEC 81001-5-1:2021 - Health software and health IT systems safety, effectiveness, and security - IEC/ISO

Talk to a regulatory cybersecurity team

If you are building the convergence between your safety RMF and your security SRMR for an upcoming submission and want a second pair of eyes, we ship cybersecurity deliverables for medical device manufacturers across 510(k), De Novo, PMA, and EU MDR pathways. Book a discovery session and we will walk your traceability with you.

ISO 14971 vs AAMI TIR57: Hazard Analysis Meets Cybersecurity Risk

Key Takeaways