ISO 14971 vs AAMI TIR57: Hazard Analysis Meets Cybersecurity Risk

Direct Answer

How do ISO 14971 and AAMI SW96 work together?

ISO 14971 handles safety hazard analysis, scoring risk as severity times probability of occurrence, while AAMI TIR57 and its normative successor ANSI/AAMI SW96 handle security risk, scoring severity times exploitability against a deliberate adversary. These are two separate risk files, not one merged document, but they must converge at a shared patient-harm taxonomy. The most common FDA deficiency is inconsistent harm definitions between the two files or security hazards that never trace into the safety file.

Safety risk and security risk are two parallel processes. They use different inputs, they score risk differently, and they live in different files. But they must converge at the harm column - and that is where most submissions fail.

Last reviewed: June 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 safety risk management standard. It assumes unintended events - use error, component failure, environmental conditions - and scores risk as severity x probability of occurrence of harm. AAMI TIR57 (and its normative successor ANSI/AAMI SW96) is the security risk management standard. It assumes a deliberate adversary, scores risk as severity x exploitability, and uses the vocabulary uncontrolled risk -> risk controls -> controlled (residual) risk -> acceptability. The FDA's February 2026 final guidance is explicit: the two are parallel processes that share a single harm taxonomy. Get the convergence wrong and your submission gets a deficiency on threat modeling, security risk management, or both.

Two parallel lanes - safety (ISO 14971) and security (AAMI TIR57 / SW96) - flowing left to right and 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 RMF and the security SRMR. Drop it into your submission package and tune the rows to your device.

Why these two standards exist separately

ISO 14971 was written for a world of mechanical failures, sterility, biocompatibility, and use error. Its probability model assumes the harm is unintended - a battery cell vents, a sterile barrier fails, a clinician misreads a screen. You can estimate probability with reliability data, field history, and human-factors testing.

That model breaks down for cybersecurity. An attacker is not a random failure. Probability is meaningless when a motivated adversary can re-roll the dice until they win. AAMI TIR57 replaces probability with exploitability - a function of attack vector, complexity, privileges required, and the existence of public exploits. SW96:2023 normatively codifies this and is the standard FDA cites in current deficiency letters.

The two standards exist separately because their threat models are different. They are not interchangeable, and trying to force security findings into the 14971 probability column is one of the fastest ways to get a deficiency letter.

The side-by-side mapping

Dimension	ISO 14971 (safety)	AAMI TIR57 / SW96 (security)
Trigger	Unintended event: use error, failure, environment	Deliberate adversary action
Top of the chain	Hazard	Threat (often STRIDE-categorized)
Middle	Hazardous situation	Vulnerability exposed in a hazardous situation
Bottom	Harm	Harm (shared with safety)
Risk formula	Severity x Probability of Occurrence of Harm	Severity x Exploitability
Risk vocabulary	Initial risk -> risk controls -> residual risk	Uncontrolled risk -> risk controls -> controlled risk
Acceptability driver	Benefit-risk, ALARP, clinical context	Same benefit-risk, plus FDA controlled vs uncontrolled gate
Primary file	Risk Management File (RMF)	Security Risk Management Report (SRMR)
FDA touchpoint	Always required	Required for cyber devices under FD&C Act Section 524B
Lifecycle scope	Cradle to grave	Cradle to grave, with explicit postmarket loop (TIR97)

The columns are different. The bottom row - harm - is the same.

The one thing reviewers flag

The most common deficiency on this convergence question is not "you didn't do threat modeling." It is more subtle: the safety RMF and the security SRMR use inconsistent harm definitions, or the security file contains hazards that never trace into the safety file at all.

A worked example. Your safety RMF defines a Severity 4 harm as "delayed therapy, hospitalization required." Your security SRMR independently defines a Severity 4 harm as "device unavailable for > 1 hour." These look similar. They are not the same. A reviewer reading both files in sequence will ask: which one is the source of truth for patient harm? If you cannot point to a single harm taxonomy that both files inherit from, you have a finding.

The fix: one harm taxonomy, two risk files. The safety team owns the taxonomy because it predates the security work and ties to clinical evidence. The security team consumes it. Every security hazard rolls up to a harm entry that the safety RMF already recognizes. Severity values are the same number on both sides because they describe the same patient outcome.

How a security hazard converges into the safety file

The convergence happens at three specific points.

1. Harm vocabulary. The SRMR references the RMF's harm taxonomy by ID. If safety calls a harm HARM-04: Delayed therapy requiring hospitalization, severity 4, the SRMR uses HARM-04 verbatim. No parallel scheme.

2. Severity scale. Both files use the same 1-5 severity scale anchored to the same clinical descriptions. A "4" means the same thing in both files. Exploitability lives only in the SRMR; probability of occurrence of harm lives only in the RMF. Severity is shared.

3. The benefit-risk acceptance decision. ISO 14971 requires an overall benefit-risk evaluation. Security residual risk is one input to that evaluation. The SRMR feeds its controlled (residual) risk decisions into the RMF's overall residual risk section so the benefit-risk evaluator sees both safety and security residuals in one place.

If those three points are wired correctly, the FDA convergence question is answered before the reviewer asks it.

Where the FDA 2026 guidance lands

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

Threat modeling is required and must produce inputs into the security risk assessment. Threats become hazards, hazards roll into harm.
Security risk management is a parallel process to 14971 safety risk management, not a substitute. Both files are expected in the submission.
The controlled vs uncontrolled risk determination drives postmarket reporting. A vulnerability that would push a previously-controlled risk into uncontrolled territory starts the postmarket guidance timelines (customer communication within 30 days, a fix within 60 days, or a correction and removal report), regardless of what the safety RMF says.

That last point is why the harm taxonomy alignment matters operationally, not just for the submission. Postmarket teams use the same harm scale years after launch to decide whether a new CVE requires an FDA report. If safety and security use different scales, your postmarket triage breaks.

A worked traceability example

A connected infusion pump has a Bluetooth pairing surface.

Threat (STRIDE): Spoofing - an attacker pairs an unauthorized controller during the 30-second pairing window.

Vulnerability: Pairing PIN is fixed at 0000 and not rotated.

Hazardous situation: Unauthorized controller can issue dose commands.

Harm: HARM-07: Unintended drug delivery, severity 5 (defined in the safety RMF)

Uncontrolled risk: Severity 5 x Exploitability 4 = 20 (high)

Risk controls: Rotating PIN, pairing limited to maintenance mode under physical key, signed command authentication.

Controlled risk: Severity 5 x Exploitability 1 = 5 (acceptable per the documented acceptability criteria)

Acceptability decision: Accepted. Justification cites the layered controls and the benefit-risk evaluation in the RMF.

Notice what is shared with the safety file and what is not. The harm (HARM-07) and its severity (5) come from the safety RMF and are not re-defined in the SRMR. The exploitability, the controls, and the controlled risk score are security-specific and live only in the SRMR. The acceptability decision references the RMF's overall benefit-risk section so the safety team sees the residual.

This is the loop ThreatGoat's exported threat model implements end-to-end. The structure is not novel - it is what AAMI TIR57 has prescribed since 2016 - but the discipline of getting every security hazard into that shape is what separates a clean submission from a deficiency.

How Blue Goat Cyber approaches this

We treat hazard analysis convergence as a build-time problem, not a documentation problem. 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 report that uses the AAMI TIR57 / SW96 vocabulary explicitly (uncontrolled risk, controlled risk, residual acceptability).
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.

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

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 the FDA cites in deficiency letters. Use SW96 as the standard you conform to and TIR57 as the implementation guidance.

Can I just extend my 14971 RMF to cover cybersecurity?

No, and the FDA will flag it. The probability model in ISO 14971 does not work for adversarial threats. You need a separate SRMR using TIR57 / SW96 vocabulary. The two files share a harm taxonomy, not a structure.

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 30-day postmarket 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 convergence failures, both are avoidable, and both are flagged in the AI deficiency screen before a human reviewer even opens the file.

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.