Every FDA cybersecurity review eventually lands on the same request: show me the procedure. Not the risk assessment itself, the procedure that produced it. The 2023 premarket guidance treats risk assessment as a quality system activity, so reviewers and auditors expect a documented method covering where threats come from, how exploitability gets scored, how severity of harm is determined, and where the line between acceptable and unacceptable sits.
This is the example SOP I point people to when they ask what that looks like. It scores exploitability with the CVSS v3 exploitability subscore, guided by the MITRE rubric FDA qualified as an MDDT, and it pulls severity of harm from the ISO 14971 safety risk assessment instead of inventing a parallel scale. Worst case severity, always. You cannot assign probabilities to an adversary who picks the failure mode.
Adapt it, fill the bracketed fields, and notice how much of the work is mechanical: scoring, lookups, tracing, rescoring. That is the part we built ELTON to automate. The judgment about what your device can tolerate stays with you, which is exactly where regulators want it.
This document describes the risk assessment process used to assess cybersecurity related risk in products and systems designed by [Organization].
Cybersecurity related risk assessment activities for products and systems designed by [Organization].
The process uses the Cybersecurity Risk Assessment template to document risks to patient safety and information security posed by threats in [Organization] products. A threat, for purposes of this SOP, is anything requiring assessment: threats from threat modeling, vulnerabilities in SBOM components, secure code analysis findings, third party researcher reports, intelligence from sources such as CISA and Health-ISAC, cybersecurity testing findings, and issues with cybersecurity impact found during design, verification, or validation.
Each threat is assessed on two dimensions. Exploitability uses the exploitability subscore (ESS) from the FIRST CVSS v3.x standard, guided by the MITRE rubric. Severity of harm comes from the system's ISO 14971 hazard analysis, using the element of the system the threat touches to find the applicable hazardous situations and harms. Where multiple harms could apply, worst case wins: you cannot assign probabilities to an adversary who chooses how to tamper. Threats with no patient safety impact (a confidentiality only exposure, say) use the CVSS impact metrics instead, judged on a separate scale.
Exploitability is scored twice. The initial score establishes inherent risk with no mitigations considered; for findings in fielded product, it answers the controlled or uncontrolled question fast. The residual score reassesses the threat against the mitigations designed to reduce it.
Five categories of risk each get their own tab in the Cybersecurity Risk Assessment: threat model findings, secure code analysis findings, software (SBOM) vulnerabilities, cybersecurity testing findings, and unresolved anomalies. The steps below apply to every row, with minor differences by category.
Record the component, subcomponent, and affected assets exactly as decomposed in the threat model and asset mapping tabs. A finding that touches multiple components becomes multiple rows.
Threat model rows carry STRIDE per element analysis. Vulnerability rows carry the CVE ID and description. Testing, secure code, and unresolved anomaly rows carry the finding ID (a report observation or a [defect system] ticket) and its description.
Pull the hazardous situation and severity of harm from the systems hazards analysis, selecting worst case where several rows could apply. FDA does not require assessment of impacts that cannot harm patients (data privacy alone, for example); if the organization tracks these business risks, use the CVSS impact metrics to complete the base score.
The ESS ranges from 0.1 to 3.9, computed from Attack Vector, Attack Complexity, Privileges Required, User Interaction, and Scope. Five bands simplify acceptance decisions: Critical (5) at 2.9 and above, High (4) from 1.9 to 2.8, Medium (3) from 1.0 to 1.8, Low (2) from 0.6 to 0.9, Negligible (1) below 0.6. The rationale sits in the appendices; the short version is that scores below 1.0 generally require physical or adjacent access, while scores at 2.9 and up are repeatable network or wireless attacks.
For patient safety risks, cross the severity of harm (1 to 5) with the exploitability band (1 to 5); the product ranges from 1 to 25. Below 10 is acceptable. At 15 and above, the risk is unacceptable and mitigations must reduce exploitability. Between 10 and 14, identify mitigations or justify acceptability through a benefit risk assessment.
For risks with no patient safety impact, use the CVSS base score: 0.0 to 3.9 acceptable, 4.0 to 6.9 benefit risk assessment required, 7.0 and above unacceptable.
Mitigations are controls that reduce a threat's exploitability, selected in priority order: inherent security by design, inherent security by manufacturing process, protective measures added to the device, protective measures added to manufacturing, risk disclosure or transfer to users, and user training. The mechanics are concrete. Multifactor authentication can move Privileges Required from Low to High. TLS can move Attack Complexity from Low to High. Removing an SSH server and adding firewall rules can move Attack Vector from Network to Local or Physical.
Document each mitigation in the Mitigations tab, categorized against Appendix 1 of the 2023 premarket guidance: authentication, authorization, cryptography, code and data integrity, confidentiality, event logging and detection, resiliency and recovery, and secure firmware and software updates. Trace each mitigation to its requirements, and trace those requirements to verification evidence. Every control claimed in a risk assessment must have testing behind it, including cybersecurity specific testing that exercises effectiveness, not just presence.
Rescore the ESS with mitigations considered. Severity of harm carries over unchanged: controls reduce the chance of exploitation, they do not make a compromised device less dangerous. For non safety threats, mitigations may legitimately reduce impact metrics (stripping PHI from log files drops the confidentiality impact).
Any threat still above threshold needs further risk controls, and if none exist, a benefit risk analysis documenting the type, magnitude, probability, and duration of clinical benefit. Then two closing checks: a completeness review confirming every identified threat was assessed and every control activity finished, and an overall residual risk evaluation against the criteria in the Cybersecurity Management Plan.
Before commercial release, a Cybersecurity Risk Management Report asserts, with justification, that the management plan was implemented, that overall residual risk is acceptable, and that methods exist to collect production and post production security information. The report is updated after periodic reviews and lives in document control with the risk management file.
Postmarket information reopens this process: CAPA results, complaints and adverse events, periodic security testing, purchasing and production data, new and revised standards, and independent researcher reports all feed revisions to the risk file.
The appendices walk one threat end to end. A networked, life sustaining device runs SSH with root login and a guessable password; an attacker on the network could shut it down mid treatment. The inherent vector AV:N/AC:L/PR:L/UI:N/S:U scores an ESS of 2.8, High (4), against Critical (4) harm: unacceptable. Mitigations: multifactor authentication on SSH, access restricted to a service account, sudo disabled. The residual vector AV:N/AC:H/PR:H/UI:N/S:U scores 0.7, Low (2): acceptable, and defensible in one row.
That row is the standard I hold risk files to. If your assessment cannot show the inherent score, the named controls, the residual score, and an acceptance decision for every threat, it is a spreadsheet, not an argument.
Start with one device. We build the twin from documentation your quality system already produces, run AI discovery remotely, and show you the graph: the handful to fix, and the evidence for everything else.