Ensuring Compliance with New FDA Guidance on Software Documentation & Cybersecurity

by | Jul 1, 2024 | Blog

New guidance from the FDA replaces similar, but now obsolete, guidance. Some of the guidance was issued in response to the PATCH Act, which is a 2022 amendment to the Food, Drug and Cosmetics Act of 1938 that also pertains to medical device cybersecurity. It includes a requirement that sponsors need to make a plan to monitor post-market cybersecurity, a broad definition of “cyber device,” a requirement to create a Software Bill of Materials (SBOM), and a requirement of making sure the device is cybersecure during development. Below is a list of major changes that the FDA implemented.

Major Change #1: Software Categorization

The documentation level determines what documentation the FDA requires in a product submission and what activities need to occur during the development process.

Before Change: Software was categorized by “Level of Concern,” which included the categories of “Major,” “Moderate,” and “Minor”

After Change: Software is now categorized by “Documentation Level,” which includes categories of “Basic,” or “Enhanced”

Major Change #3: Risk Management File

ISO 14971 defines risk analysis as, “the systematic use of available information to identify hazards and to estimate risk” and spans the full total product lifecycle of medical devices.

Before Change: Only a device hazard analysis was required

After Change: A full ISO 14971-compliant risk management file is required including a risk management plan, risk benefit analysis, and a risk management report.

Major Change #4: List of Unresolved Anomalies

An unresolved software anomaly is a defect that still resides in the software because a sponsor deemed it appropriate not to correct or fix, according to a risk-based rationale about its impact on the device’s safety and effectiveness.

Before Change: A list of unresolved software anomalies was required only for software with Level of Concern designation of “Moderate,” or “Major”

After Change: A list of unresolved anomalies is always required

Major Change #6: Security Risk Management Plan/Report

The security risk management plan/report includes two parts. Part one is the plan, which is written early in a development project. It describes how security threats will be identified, analyzed, and mitigated during development. The second part is the report, which is written at the end of a development project. It describes how security threats were actually identified, analyzed, and mitigated during development.

Before Change: The security risk management plan and report were not required

After Change: The security risk management plan and report are required unless the security risk management activities are planned/reported in the general risk management plan/report

Major Change #2: Software Architecture Design

The purpose of the system and software architecture diagram is to show a roadmap of the device design to facilitate a clear understanding of the modules and layers that make up the system and software, the relationships among the modules and layers, the data inputs/outputs and flow of data among the modules and layers, and how users or external products interact with the system and software.

Before Change: The software architecture document was not required

After Change: The software architecture document is required

Major Change #5: SBOM

The SBOM lists all the software components of the device software.  The SBOM is machine-readable so it can be quickly scanned for cybersecurity vulnerabilities.

Before Change: A SBOM was not required

After Change: A SBOM is required

Major Change #7: Security Architecture

The security architecture document is similar to the software architecture document, but it highlights security concerns.

Before Change: A security architecture document was not required

After Change: A security architecture document is required

Wondering whether you’re compliant with the new FDA regulations?