Ensuring Compliance with New FDA Guidance on Software Documentation & Cybersecurity

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 #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 #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 #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 #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 #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.

Are you working on a new medical device that includes a software or connectivity component? Regulatory bodies are moving quickly to ensure safety and security with regulations and guidance scrambling to keep up with the speed of innovation. Our regulatory and product development teams keep their fingers on the pulse of the industry including regulatory developments in the U.S., EU and beyond.

If you want to know with more confidence that your software-inclusive medical device is compliant with the latest regulations, get in touch. We have the knowledge and expertise to streamline or accelerate your pathway and milestone achievement.