Medical Device & SaMD

Why Your Security Risk Assessment Cannot Live in Your 14971 File

Bill Barksdale, CISSP

In short

Safety risk scores severity against probability of harm. Security risk scores severity against exploitability, because an attacker is not a random failure and does not have a failure rate. The two processes stay separate and converge at one place: the patient harm they both roll up to.

There is a sentence in FDA's guidance that a lot of teams read past, and it governs a document most of them have already written the wrong way.

Security risk management is a distinct process from safety risk management as described in ISO 14971. Not a section of it. Not an extension. Distinct.

Most companies discover this after a reviewer points at their risk file and asks why a cybersecurity threat is being scored with a probability of occurrence.

Why probability is the wrong axis

ISO 14971 has served medical devices well for a long time, and its logic is sound for what it was built for. A component fails at some rate. A user makes an error at some rate. You estimate that rate, multiply it by the severity of the resulting harm, and you have a risk you can rank and control.

That logic requires the world to be indifferent to you. Failure rates work because capacitors do not care whether you are watching.

An attacker cares. An attacker adapts, chooses the weakest point, waits, tries again with better information, and shares what worked. There is no failure rate for a motivated adversary, and any number you assign as one is a number you invented.

So security risk substitutes a different second axis: exploitability. Not how often will this happen, but how hard is this to do - what access does it need, what skill, what equipment, what preconditions, and how much does the attacker learn if they try and fail.

This is why the two assessments cannot share a scoring scheme, and why merging them produces a file that is wrong in a way that is difficult to see and easy for a reviewer to name.

The standards, briefly

ISO 14971 is the safety risk management standard. It is the master document and it stays exactly where it is.

AAMI TIR57 is a technical report that extends 14971's principles to security risk, and defines harm more broadly than physical injury alone.

ANSI/AAMI SW96 takes TIR57's approach and puts it in the form of a standard with requirements rather than guidance, structured to parallel 14971 but focused on security.

The practical read: 14971 for safety, SW96 with TIR57 as its companion for security, and the two files kept separate on purpose.

The convergence point, which is the whole thing

Separate processes, separate inputs, separate scoring. And then exactly one place where they must meet: harm.

Any security threat that could plausibly lead to patient harm has to roll up into the same patient-harm taxonomy your safety file already uses. Same categories. Same severity definitions. Same language.

If your safety file rates a certain injury as serious, your security file cannot rate the same injury as moderate because a different team wrote it with a different scale in mind. Two files describing one patient with two vocabularies is not a documentation inconsistency. It is evidence that nobody reconciled them, and it invites the question of what else was not reconciled.

Commentary on reviewer patterns consistently puts this at the top: submissions where the two files use inconsistent harm definitions, or where security risks never trace to a hazard in the safety file at all, are the most common way the convergence question gets flagged.

The tell is easy to check yourself. Open both files. Find a threat in the security file that could injure someone. Find the corresponding hazard in the safety file. If it is not there, or it is there under a different name with a different severity, you have found the problem before somebody else did. And if the check keeps turning up nothing to reconcile, the question moves upstream to whether the threat model ever produced threats that touch a patient in the first place.

What this looks like in practice

Two registers, one taxonomy. Keep the files separate - they have different inputs, different methods, different reviewers. Share the harm definitions absolutely.

Score security risk on exploitability, and write down what your exploitability levels mean. "High" is not a definition. Access required, skill required, equipment required, preconditions - say what each band means so that two engineers rating the same threat land in the same place.

Reconcile deliberately, as a scheduled activity, not as something that happens if someone notices. Somebody sits with both files open and walks the threats that touch patients.

Residual security risk still gets documented per 14971. The security process is distinct; the obligation to state and justify what is left over is not.

What comes out of the security file is a set of control obligations, and a control is not yet a control until it is written as a testable requirement.

The version of this outside medical devices

Every organization doing risk assessment has some version of this problem: an operational risk register scored on likelihood, and a security threat set that does not behave like a likelihood.

The fix is the same. Score security on exploitability, keep the register separate, and force convergence at the impact definition so that a security-driven outage and an operationally-driven outage of the same magnitude are described identically. Otherwise your board sees two risk numbers and no way to compare them.

This is engineering guidance, not legal or regulatory advice. Risk management strategy for a specific device belongs with your regulatory and quality leads.

This is the work I do - FDA cybersecurity submissions, penetration test remediation, and security ownership for companies too small for a full-time CISO. bill@bato.com.

This is the work I do — FDA cybersecurity submissions, penetration test remediation, and security ownership for companies too small for a full-time CISO. bill@bato.com.

Common questions

Can we use CVSS for security risk scoring?

CVSS is useful as an input and insufficient as the assessment. It scores a vulnerability's technical characteristics in the abstract; it knows nothing about your device, your clinical context, or what happens to a patient. A CVSS 9.8 in a component your product never invokes may be irrelevant, and a CVSS 5 on the path that controls therapy delivery may be the most important row in your file. Use it to inform exploitability, then do the harm analysis yourself.

Do we need to buy SW96 and TIR57?

If you are building security risk management as a repeatable process, yes. They are the reference your reviewers and auditors are working from, and describing a process as aligned to a standard you have not read is a position that does not survive follow-up questions.

Is the security risk assessment part of the submission?

Yes. A security risk management report is expected as part of the cybersecurity documentation, and its relationship to your safety risk file is part of what gets read.

What if a security risk has no patient safety impact at all?

It still belongs in your security file - data confidentiality, service availability, and business impact are real. It simply does not roll up into the safety file, and you should be able to say why not.

Our device is not connected to the internet. Does any of this apply?

Probably, and the connectivity question is broader than people expect - a USB port used for data transfer or a service laptop connection can be enough to put you inside the cyber device definition. Do the scoping analysis before concluding you are outside it.

What Does FDA Actually Want in a Threat Model?Your Security Controls Are Not Requirements Yet FDA Section 524B: What Premarket Cybersecurity Actually Requires Is Your Product a "Cyber Device" Under Section 524B?

← More in Medical Device & SaMD