12 Essential FDA Cybersecurity Risk Assessment Rules

August 20, 2025Jose Bohorquez, PhD

The twelve rules that determine whether your cybersecurity risk assessment will satisfy an FDA reviewer or generate an AI request. Each one mapped to the guidance section it derives from.

If I had to pick the single concept that trips up the most first-time submitters, it's this: FDA expects cybersecurity risk to be scored on exploitability, not probability. Teams come from an ISO 14971 background where probability times severity is the bread and butter. They write a cybersecurity risk assessment using the same template, drop in the same scoring scheme, and wait for the Additional Information request that follows.

The 2023 premarket cybersecurity guidance, reinforced by the 2025 update, is explicit: cybersecurity-related failures are not random component failures. There is no historical failure-rate distribution for "attacker discovers SQL injection." The right question is not "how likely is this?" — it's "how exploitable is this, and what's the impact if it's exploited?"

Below are the twelve rules I use to evaluate every cybersecurity risk assessment that crosses my desk before submission. Each one ties back to a specific section of the FDA guidance or ANSI/AAMI SW96. If your assessment can pass all twelve, you can defend it in a reviewer call.

Quick map: rule → guidance source → where reviewers look

#	Rule	Guidance reference	Reviewer artifact
1	Capture risks and controls from the threat model	SW96 §6; FDA 2023 guidance §V.A.2	Threat model + traceability matrix
2	Score pre- and post-mitigation	SW96 §7.4; FDA 2023 §V.A.3	Risk assessment table
3	Document acceptance criteria	SW96 §6.4	Cybersecurity management plan
4	Transfer cyber risks with safety impact to ISO 14971	SW96 §7.5; FDA 2023 §V.A.4	Safety and security assessment of vulnerabilities
5	Use exploitability, not probability	FDA 2023 §V.A.3	Risk assessment methodology section
6	Treat known vulnerabilities as foreseeable	FDA 2023 §V.A.3; CISA KEV guidance	SBOM analysis + risk assessment
7	Consider TPLC when evaluating vulnerabilities	FDA 2023 §V.A.5	Risk assessment + cybersecurity management plan
8	Evaluate device risk in system context	FDA 2023 §V.A.2	Security architecture views + threat model
9	Design out CISA KEV vulnerabilities	FDA 2023 §V.B.1	SBOM analysis + design rationale
10	Assume worst-case or justify the exploitability rating	FDA 2023 §V.A.3	Risk assessment narrative
11	Build TPLC into acceptance criteria	SW96 §6.4; FDA 2023 §V.A.5	Acceptance criteria + post-market plan
12	Cover both intentional and unintentional failures	FDA 2023 §V.A.2	Threat model

If you read nothing else, that table is the deliverable.

The twelve rules

1. Capture risks and controls from the threat model

Every risk in your assessment must trace to a threat in your threat model, and every control must trace to a risk. If a reviewer can't follow the chain, they assume the assessment is decorative.

The threat model captures risks introduced through supply chain, manufacturing, deployment, interoperation, maintenance, updates, and decommission. Each threat gets a unique ID. The risk assessment references the threat ID. The control list references the risk ID and the threat ID. The test report references the control ID.

For the mechanics of building the model, see threat modeling for cloud-connected medical devices.

2. Score pre- and post-mitigation

The point of pre- and post-mitigation scoring is to demonstrate that your controls do something. A risk that scores 8 before mitigation and 7 after suggests the control is theater. A risk that scores 8 before and 3 after, with a test case verifying the control, is defensible.

Pre-mitigation assumes no controls. Post-mitigation reflects the residual risk after planned controls are implemented and verified. Both scores use the same methodology. Document the methodology once and apply it consistently.

CVSS works as a starting point for the exploitability factors. Adapt for medical-device context where needed — for example, "user interaction required" reads differently when the user is a trained clinician versus a patient at home.

3. Document acceptance criteria

ANSI/AAMI SW96 requires that management defines and documents criteria for security risk acceptability. This is not optional and it is not a sentence in the management plan. Reviewers want a defined framework:

The thresholds at which risk is acceptable, conditionally acceptable, or unacceptable.
The conditions under which a conditionally acceptable risk gets escalated.
The decision authority for accepting risk at each level.
The triggers that force reassessment.

A useful pattern: tiered thresholds (low/medium/high/critical) with explicit conditions for each. "Critical risks require additional controls before acceptance under any circumstance" is a defensible statement. "Critical risks are evaluated on a case-by-case basis" is not.

4. Transfer cyber risks with safety impact to ISO 14971

When a cybersecurity threat could plausibly cause patient harm — loss of therapy, incorrect dose, false alarm suppression, unauthorized data exposure with downstream clinical impact — that risk doesn't just live in the cybersecurity risk assessment. It moves into the safety risk management process under ISO 14971.

Define the transfer mechanism in writing:

The criteria that trigger transfer.
Who owns each side of the handoff.
The documentation that travels with the risk.
How the safety-side decision feeds back to the cybersecurity controls.

The Safety and Security Assessment of Vulnerabilities is the artifact where reviewers verify this is working.

5. Use exploitability, not probability

This is the one that breaks ISO 14971 muscle memory. Exploitability factors:

Access vector — remote, adjacent, local, physical.
Attack complexity — what the adversary needs to know, build, or chain together.
Privileges required — none, user, admin.
User interaction required.
Exploit maturity — proof-of-concept, functional, in the wild.

CVSS v3.1 captures these well. The key is to apply them consistently and to write the methodology section of the risk assessment so a reviewer can replicate your scoring without asking. If your scoring rubric requires implicit knowledge that's not on the page, expect questions.

For specific guidance on adapting CVSS to medical devices, see the CVSS for medical device risk assessment breakdown.

6. Treat known vulnerabilities as foreseeable

This is the rule that catches teams who try to score a known CVE as "unlikely." If the vulnerability exists in your device, it has occurred — exploitation just hasn't happened yet. Score it as a foreseeable risk. The relevant variables are exploitability and impact, not whether someone has gotten around to it.

This applies to every component in the SBOM that has open CVEs, every internal finding from your own security testing, and every issue in the CISA Known Exploited Vulnerabilities catalog that touches your stack.

7. Consider TPLC when evaluating vulnerabilities

A risk scored at device launch is not the same risk three years later. Exploitation tools mature. Defensive controls age. Components reach end-of-support.

The risk assessment should include forward-looking notes:

What is the expected risk evolution over the device's operational life?
What triggers would force a reassessment (a new CISA KEV entry affecting an SBOM component, a vendor end-of-support announcement, a major reported breach using a similar attack pattern)?
How does the post-market plan adapt the control set as risk evolves?

A reviewer who sees a one-shot risk assessment with no TPLC consideration will assume the team hasn't thought past day one.

8. Evaluate device risk in system context

A device doesn't operate alone. It plugs into an EHR. It sits on a hospital VLAN. It pairs with a phone that has cloud accounts. The risk of compromise has to be evaluated in context of what the compromised device can reach.

A low-risk vulnerability on a standalone device may be a high-risk vulnerability when the device connects to PACS, the patient's phone, or a clinician's workstation. Document the trust boundaries and the lateral movement paths in your security architecture views. The threat model should include scenarios that exploit those paths.

For diagram patterns, see how to create data flow diagrams for medical devices.

9. Design out CISA KEV vulnerabilities

FDA is explicit: vulnerabilities in CISA's Known Exploited Vulnerabilities catalog should be designed out, not accepted. These are CVEs with confirmed exploitation in the wild. A risk-accept rationale doesn't survive contact with a KEV-listed CVE.

Operationally: scan your SBOM against the KEV catalog on every release. Flag any KEV hits as design changes, not accepted risks. Build the scan into CI so a new KEV listing blocks the build.

10. Assume worst-case or justify the exploitability rating

When you don't have strong evidence about exploitability — and you usually don't, because attackers don't publish their capabilities — default to worst-case. If you want to assess as something less than worst-case, document the justification:

What technical barrier reduces exploitability?
What evidence supports the assessment?
How will the assessment be revisited over TPLC?

A line in the methodology section saying "we score conservatively unless explicit justification is provided" carries weight with reviewers. It signals the assessment was done deliberately.

11. Build TPLC into acceptance criteria

Rule 7 says model the risk over time. This rule says model the acceptance threshold over time. They're related but distinct.

A useful pattern is staged acceptance:

Years 0–2 from launch: standard criteria apply.
Years 3–5: reduced acceptance thresholds; certain conditional risks get reassessed.
Years 5+: enhanced controls required, or end-of-life trigger.

This signals to reviewers that the post-market plan is real, not a placeholder.

12. Cover both intentional and unintentional failures

Cybersecurity failures don't all come from attackers. A misconfigured authentication setting, a debug interface left enabled in production, a key rotation procedure that nobody ran — these are cybersecurity failures with no malicious actor. Reviewers want to see both intentional (malicious) and unintentional (configuration, human error, accidental exposure) scenarios in the threat model.

Practically: every authentication boundary should have a failure mode for "misconfigured" in addition to "attacked." Every cryptographic operation should have a failure mode for "key compromised by mistake" in addition to "key cracked." The control set should address both classes.

For the controls side, see how to implement cybersecurity controls.

A reviewer's anti-pattern checklist

After enough submissions, you start recognizing the patterns that get flagged. The ones I see most:

Probability scoring relabeled as exploitability scoring. Same numbers, same logic, different column header. Reviewers see through this.
Threat model and risk assessment that don't share IDs. Each document looks fine in isolation. Together, you can't trace anything.
Controls listed without a corresponding threat. Usually means the team copied a generic control list.
Acceptance criteria stated as "case by case." This is the same as not having criteria.
No transfer mechanism to safety risk. The Safety and Security Assessment of Vulnerabilities exists but is empty or generic.
CISA KEV ignored. Either the team didn't scan, or they scanned and accepted the risk.
No TPLC consideration. The assessment is a snapshot. The post-market plan doesn't reference how the assessment will be updated.

At CyberMed we've seen

The most expensive deficiency I've helped a client resolve was not a missing control. It was a complete, well-written risk assessment whose scoring methodology didn't match the controls section. The assessment used a 1–5 exploitability scale; the controls section justified mitigations against a 1–10 scale that appeared nowhere else. The reviewer asked for clarification, and what should have been a one-page response turned into a six-week rewrite of half the cybersecurity package.

The fix is boring: pick one scoring methodology, document it in the cybersecurity management plan, and reference it everywhere. Internal consistency is what reviewers grade on. They will not assume good faith on a contradiction.

[NEEDS: anonymized AI-request example from Jose, if available]

Where to go next

If you want to know where your current cybersecurity package stands against these twelve rules, the FDA 524B Cybersecurity Readiness Assessment is the fastest gauge. For the surrounding artifacts — threat model, controls, testing, SBOM — start with the FDA cybersecurity requirements overview.

If you're past the assessment phase and need the work done, the 30-day CyberSprint covers all 13 cybersecurity artifacts on a fixed timeline. The risk assessment piece is where most of our engineering goes.

External references

This post is technical guidance based on published FDA expectations and ANSI/AAMI SW96. It is not regulatory advice for any specific submission. Talk to a regulatory professional who knows your device.