FDA Deficiency: Missing Cybersecurity Risk Assessment

What FDA reviewer language looks like

Paraphrased patterns from real deficiency letters. Not verbatim FDA quotes.

• Pattern 1

  The submission does not contain a cybersecurity risk assessment that is distinct from, but integrated with, the device's safety risk management file. Provide a security risk assessment consistent with AAMI TIR57 and demonstrate how it informs the ISO 14971 risk management file.

• Pattern 2

  The methodology used to score cybersecurity risk is not described. Provide the rationale for the chosen exploitability and impact scales and how they are combined to determine residual risk.

• Pattern 3

  Several threats identified in the threat model do not appear to be carried through to the cybersecurity risk assessment. Provide updated documentation that traces each identified threat to a corresponding risk evaluation and risk control.

Why this happens

• Teams treat security risk as a chapter in the safety risk file rather than its own assessment with its own methodology.
• Exploitability is omitted because the scoring rubric was copied from a clinical safety template that has no concept of attacker capability.
• The risk assessment is authored separately from the threat model, and the two have no shared identifiers or traceability.
• Residual risk is recorded as a single 'acceptable' verdict with no derivation, so reviewers cannot reproduce the conclusion.

How to fix it

• Author a standalone cybersecurity risk assessment using AAMI TIR57's structure: assets, threats, vulnerabilities, controls, residual risk.
• Use a documented exploitability scale (e.g., based on CVSS environmental + temporal metrics or a custom scale you justify) combined with a patient-harm scale derived from the safety risk file.
• Provide the integration mapping: which security risks elevate which safety hazards, and where in the ISO 14971 file the resulting residual risk is recorded.
• Trace every threat-model entry into the risk assessment and every risk into a control and verification activity.

Two risk worlds, one integrated file

ISO 14971 was written for hazards that arise from the device itself, where probability is largely a function of failure modes, use error, and environmental conditions. Cybersecurity risks have a different probability driver: an intentional, adaptive adversary. AAMI TIR57 exists precisely because you cannot estimate the probability of an exploit using the same techniques you use to estimate the probability of a component failure. FDA reviewers expect to see both methodologies acknowledged: a security-specific assessment that uses exploitability, and an integration mapping that translates security exploit scenarios into hazardous situations evaluated under ISO 14971. Most deficiencies in this area come from teams that picked one methodology and tried to do both jobs with it.

Make the math visible

Reviewers do not want to take the residual-risk verdict on faith. The risk assessment should make the math visible: the exploitability score and its rationale, the patient-harm severity from the safety file, the combination rule, the resulting raw risk, the control(s) applied, and the residual risk. Submissions that show this derivation in a table — even a simple one — almost never draw a methodology deficiency. Submissions that present a one-word verdict almost always do.

Standards involved

• AAMI TIR57AAMI TIR57:2016 (R2023) - Principles for Medical Device Security - Risk Management
• ISO 14971ISO 14971:2019 - Medical Devices - Application of Risk Management to Medical Devices
• FDA 2026FDA Premarket Cybersecurity Guidance (Feb 3, 2026)
• ANSI/AAMI SW96ANSI/AAMI SW96:2023 - Standard for Medical Device Security - Security Risk Management

Already responding to this deficiency?

Our deficiency response engagement rebuilds the underlying artifact and produces a reviewer-ready response narrative.