Documentation Overload: The Documents FDA Requires for Software and Cybersecurity

You may be surprised that FDA evaluates software functionality and cybersecurity separately, even though the documentation can overlap. This accounts for what some refer to as "document overload."

The June 2023 software guidance lists ten documentation elements in its Table 1. The February 3, 2026 cybersecurity guidance lists six documentation types in Appendix 4 Table 1 cybersecurity, broken into fourteen elements. If that wasn't enough with the two lists, you have the eSTAR, which gives each list its own section.

The good news for medical device manufacturers is that some of the same engineering work can support both lists.

This post walks through the lists, says which items are statutory and which are recommendations, and shows where one piece of work feeds both.

Why there are two lists

Content of Premarket Submissions for Device Software Functions (June 14, 2023) is the source of the software list.

FDA has turned to the software guidance to better understand four things:

• What your software is supposed to do.

• How it's designed and organized.

• How you developed and tested it.

• What could happen if the software fails.

The cybersecurity list, on the other hand, comes from Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 3, 2026).

The cybersecurity guidance takes a hard look at what happens when someone exploits a vulnerability or attacks the device. FDA wants you to explain how you've ID'd cybersecurity risks, the protections you've implemented, how you've tested those protections, and how you'll address vulnerabilities.

Yet, there's still more to consider. The software guidance goes a step further in that there are two documentation levels, Basic and Enhanced. You will likely need Enhanced if your medical device could cause serious harm from software failure. (Although even a Basic level device can still require extensive cybersecurity documentation if it's networked with other devices.)

Section IV.D of the cybersecurity guidance says its documentation scales with cybersecurity risk, not with the software Documentation Level.

The software documentation and cybersecurity documentation aren't completely independent, though. They describe the same medical device from different perspectives. The lists have to agree with each other.

For example, your software architecture diagram and your security architecture views describe the same system. Your Risk Management File and your Cybersecurity Risk Assessment handle different risks but need a documented handoff (a record connecting the risks).

Our book explains how these documents work together to tell your cybersecurity story for FDA.

The software package: ten elements

FDA has two levels of software documentation: Basic and Enhanced. Manufacturers generally provide the Basic-level information, while those whose devices meet the Enhanced criteria provide additional documentation.

Table 1 of the software guidance lists these elements. The Basic column applies to every submission. The Enhanced column adds to it.

• Software Documentation Level Basic Enhanced Evaluation (VI.A): Explain why your device qualifies for Basic or Enhanced documentation. Enhanced applies when a software failure could present a probable risk of death or serious injury, and FDA also recommends it for combination products, Class III devices, and certain blood-related devices.
• Software Description (VI.B): Describe what the software does and the equipment it runs on.
• Risk Management File (VI.C): Risk management plan, risk assessment showing risks are mitigated, and risk management report. This is the ISO 14971 safety file. It isn't the cybersecurity risk assessment.
• Software Requirements Specification (VI.D): List what the software must do and how it must perform.
• System and Software Architecture Design (VI.E): Detailed diagrams of modules, layers, interfaces, data flow, and interactions with users and external products.
• Software Design Specification (VI.F): Enhanced only. At Basic, FDA says to keep it in the design history file and may request it during review.
• Software Development, Configuration Management, and Maintenance Practices (VI.G): A summary of the lifecycle, configuration management, and maintenance processes, or a Declaration of Conformity to the FDA-recognized IEC 62304 for the specified clauses. Enhanced adds the complete configuration management and maintenance plan documents.
• Software Testing as part of Verification and Validation (VI.H): Show how you tested the software and whether it passed.
• Software Version History (VI.I): Record the software versions and what changed between them.
• Unresolved Software Anomalies (VI.J): Identify known software problems that haven't been fixed and assess their impact.

Two common misunderstandings tend to trip up first-time submitters. An IEC 62304 Declaration of Conformity helps show FDA that you followed an established software development process. It doesn't replace the SRS, the architecture, or the test evidence. The other documents show FDA what you built and how you verified that it works.

The second misunderstanding involves Basic-level testing. Basic doesn't mean system testing alone. FDA asks for a summary of all three testing levels, along with the system testing protocol and report. Our IEC 62304 to eSTAR mapping shows which lifecycle output belongs in each documentation element.

The cybersecurity package: six types, fourteen elements

The February 2026 FDA cybersecurity documentation requirements guidance identifies six categories of cybersecurity documentation containing fourteen individual elements.

It's important to understand the difference between elements and types.

Think of the six types as folders. The fourteen elements are the specific pieces of information that go into those folders.

Appendix 4 Table 1 cybersecurity guidance organizes the recommended documentation as six types. The table below lists each one, the guidance section that defines it, and what it has to contain.

Documentation type	Guidance sections	What it contains
Cybersecurity Risk Management Report	V, VI.B	Threat Model; Cybersecurity Risk Assessment; SBOM; Vulnerability Assessment and Software Support; Unresolved Anomalies Assessment; Traceability
Measures and Metrics	V.A.6	Percentage of vulnerabilities patched; time from identification to patch; time from patch availability to field deployment
Architecture Views	V.B	Security requirements and acceptance criteria per control category (V.B.1, Appendix 1); Global System, Multi-Patient Harm, Updatability and Patchability, and Security Use Case views (V.B.2, Appendix 2)
Testing	V.C	Security requirements evidence; threat mitigation testing; vulnerability testing; penetration test report
Labeling	VI.A	Security information for users, from recommended controls and port lists to SBOM access, update procedures, and end of support
Cybersecurity Management Plans	VI.B	Postmarket monitoring, KEV handling, patch timelines, update process, CVD, customer communication

Keep this in mind: FDA wants the cybersecurity information, but it doesn't necessarily care whether manufacturers organize it into fourteen separate documents.

The guidance says this table "is not intended to serve as merely a deliverable checklist." It's one way to organize the information, and FDA accepts the elements in whatever form matches your existing documentation.

The next sections explain what each element needs.

The Cybersecurity Risk Management Report

The essential message is that FDA wants manufacturers to explain how they identified cybersecurity risks, what they did about them, what risks remain, and where the supporting evidence can be found.

Section V.A says the report should summarize the risk evaluation methods, state the residual risk conclusion, detail the mitigation activities, and "provide traceability between the threat model, cybersecurity risk assessment, SBOM, and testing documentation." FDA points to AAMI TIR57 and ASNSI/AAMI SW96 as the model for the plan and report. Inside it:

• Threat Model (V.A.1): A threat model is essentially a systematic examination of what could go wrong with a device's cybersecurity. It identifies risks and mitigations, states assumptions about the environment of use, and captures risks from the supply chain, manufacturing, deployment, interoperation, maintenance, updates, and decommissioning. FDA expects manufacturers to include the rationale for the methodology.
• Cybersecurity Risk Assessment (V.A.2): While the threat model identifies what could go wrong, the cybersecurity risk assessment evaluates those threats and determines what needs to be done. Scores risks on exploitability, not probability. Shows pre- and post-mitigation scores, acceptance criteria, and the method for transferring security risks into the safety risk assessment. Known vulnerabilities count as foreseeable risks, and anything in CISA's Known Exploited Vulnerabilities catalog should be designed out. Interoperability risks from every interface belong here too (V.A.3).
• SBOM (V.A.4): SBOM stands for Software Bill of Materials. Think of it as an ingredient list for software. A medical device might contain software written by the manufacturer, software purchased from another company, and open-source components. The SBOM identifies those components. For each component, add the level of support from its maintainer and the end-of-support date, in the SBOM or in an addendum. The guidance names no format and says industry-accepted formats are encouraged.
• Vulnerability Assessment and Software Support (V.A.4(b)): The SBOM tells FDA what software components are in the device. The vulnerability assessment tells FDA which of those components have known security weaknesses and what the manufacturer has done about them. For each known vulnerability, the manufacturer needs to explain how it was identified, what risks it presents, and what security controls address it. This includes considering whether a vulnerability could affect patient safety.
• Unresolved Anomalies Assessment (V.A.5): An anomaly is a problem or unexpected behavior in the software. An unresolved anomaly is one that hasn't been fixed. Not every software anomaly creates a cybersecurity risk. Each open anomaly from the software package is assessed for security impact, including relevant CWE categories.
• Traceability: Traceability means being able to follow a cybersecurity issue through the manufacturer's documentation. Think of traceability as the identifiers that connect the threat model, the risk assessment, the SBOM, the controls, and the tests. Our post on cybersecurity traceability matrices shows the formats.

Measures and Metrics

FDA wants medical device manufacturers to demonstrate how effectively they manage cybersecurity vulnerabilities. Section V.A.6 identifies three measures:

1. Percentage of vulnerabilities patched
2. Time from identification to patch
3. Time from patch availability to deployment

Note: FDA understands new devices won't have this data yet. Just explain how you'll track it.

Architecture Views

As you might expect, FDA wants to know what cybersecurity protections a device has, how those protections work, and where they fit into the device's design.

Section V.B.1 lists eight control categories that describe the protections:

• Authentication
• Authorization
• Cryptography
• Code, Data, and Execution Integrity
• Confidentiality
• Event Detection and Logging
• Resiliency and Recovery
• Updatability and Patchability.

FDA asks for the requirements and acceptance criteria for each category, and evidence that the controls were implemented and tested.

Section V.B.2 asks for the four views, each with diagrams and explanatory text at the detail level in Appendix 2. If a view doesn't apply, you must explain why. The number of Security Use Case Views scales with connectivity. A USB-only device may need one. A networked device with cloud services needs several.

Our post on the architecture security view covers each view.

Testing

The important point here is that manufacturers are expected to test more than whether their software works correctly. They also need to test whether its cybersecurity protections work.

Section V.C states that "cybersecurity controls require testing beyond standard software verification and validation activities." The submission should show:

• Evidence that each security design input was implemented, with boundary analysis.
• Threat mitigation testing against the risks in each architecture view.
• Vulnerability testing: abuse and misuse cases, fuzzing, attack surface analysis, vulnerability chaining, known-vulnerability scanning, software composition analysis of binaries, and static and dynamic analysis including checks for hardcoded or default credentials.
• A penetration test report stating tester independence and expertise, scope, duration, methods, and findings, with the original third-party report if one was used.

Labeling and Cybersecurity Management Plans

Labeling doesn't refer to the physical label attached to a medical device. In FDA terminology, labeling can include instructions for use, manuals, and other information supplied with the device.

Section VI.A lists the security information users should receive: recommended controls for the use environment, network ports and interfaces, infrastructure requirements, the SBOM, how to get authorized updates, how the device responds to security events, backup and restore, secure configuration, forensic log access, end of support, and secure decommissioning.

Also, remember cybersecurity doesn't end when the device reaches the market. New vulnerabilities can emerge years later. Software components may become outdated and attackers may discover new ways to exploit weaknesses. Another possible scenario: Hospitals may change their networks or supporting systems.

FDA therefore wants manufacturers to explain how they'll manage cybersecurity throughout the device's supported life.

Section VI.B lists the management plan contents: personnel responsible, vulnerability monitoring sources and frequency, KEV handling, periodic testing, patch timelines, update processes and patching capability, the coordinated vulnerability disclosure process, and customer communication.

What's statutory and what's recommended

Let's take the law first.

Federal law, specifically Section 524B, makes certain cybersecurity measures mandatory for qualifying devices.

The law requires three things:

1. A plan for monitoring and addressing vulnerabilities.
2. Processes for maintaining cybersecurity, including regular and emergency patches.
3. A Software Bill of Materials (SBOM).

On the other end, FDA's guidance recommends how manufacturers can document compliance with cybersecurity requirements. These recommendations aren't legally binding, but if you take a different approach, you should be prepared to explain how it meets FDA's expectations.

Our Section 524B guide covers the statute in depth.

Where one activity feeds both packages

Practical point: Manufacturers don't need to do the same work twice just because there are separate documents FDA requires for software and cybersecurity.

Much of the same work supports both FDA documentation packages. The trick is presenting the information each eSTAR cybersecurity documentation section requires without duplicating the effort.

• Architecture. The software architecture diagram (VI.E) and the security architecture views (V.B.2) describe the same components. Draw the system once, then produce the security views as overlays that add trust boundaries, control placement, and update paths.
• Risk. The Risk Management File (VI.C) handles safety hazards under ISO 14971. The Cybersecurity Risk Assessment (V.A.2) handles exploitability. They connect through a documented transfer: security risks with safety impact move into the safety file. The guidance calls the two "distinct but connected."
• Requirements and tests. Security requirements belong in the SRS (VI.D) and in the control requirements (V.B.1). Verification of those requirements counts in software testing (VI.H) and in cybersecurity testing (V.C), but the cybersecurity side also needs the threat mitigation, vulnerability, and penetration testing that software V&V doesn't produce.
• Anomalies. The open anomaly list (VI.J) is the input to the security assessment of unresolved anomalies (V.A.5). Same list, second review.

Our SPDF vs IEC 62304 post goes deeper on running security activities inside the software lifecycle.

Where submissions go wrong

Yes, FDA reviewers may request additional information when documentation is incomplete, inconsistent, or difficult to follow, regardless of the type of medical device.

• Broken traceability. The reviewer can't connect a security threat to the protection designed to address it and the test showing that protection works.
• Probability scoring in the cybersecurity risk assessment. Manufacturers mistakenly evaluate how likely a cyberattack is instead of how easily a vulnerability could be exploited.
• A build-tool SBOM attached as is. An automatically generated software component list may be missing information FDA expects, including support dates and vulnerability assessments.
• Architecture views that don't match the software architecture. The security diagrams must agree with the software architecture and provide the necessary security details.
• Inconsistent terminology. The same component under three names, or risk IDs that reset between files.

How to keep it manageable

Manufacturers can reduce duplicate work by following established development and cybersecurity processes and keeping their documentation connected. These three moves keep the two lists from doubling your work:

1. Use IEC 62304 to guide software development and build the documentation FDA expects along the way. Planning, requirements, architecture, verification, and maintenance outputs map onto the ten elements. Use the Declaration of Conformity for VI.G and write the rest from the lifecycle records.
2. Follow SW96 and TIR57 when developing your cybersecurity risk management process. The guidance names both as the model for the security risk management plan and report. A process that follows them produces the threat model, risk assessment, and traceability the report needs. Neither standard ships templates, so the document design is still yours.
3. Keep requirements, threats, controls, and test results connected in one tracking system. Software requirements, security requirements, threats, controls, and tests in one database. Export one filtered view for the software section and one for the cybersecurity section.

Important: Start during design, not after verification. Threat models and architecture views should help shape the design, not simply document decisions you've already made.

Need help building the software or cybersecurity package? See our FDA cybersecurity documentation requirements service, our software DHF service, or email us at info@cybermed.ai.

Sources

• FDA. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Final guidance, February 3, 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions
• FDA. Content of Premarket Submissions for Device Software Functions. Final guidance, June 14, 2023. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/content-premarket-submissions-device-software-functions
• Federal Food, Drug, and Cosmetic Act, Section 524B, Ensuring Cybersecurity of Devices, 21 U.S.C. 360n-2. https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title21-section360n-2&num=0&edition=prelim
• NTIA. The Minimum Elements for a Software Bill of Materials (SBOM). July 12, 2021. https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom
• ANSI/AAMI SW96:2023. Standard for medical device security, Security risk management for device manufacturers. AAMI, 2023.
• AAMI TIR57:2016 (R2023). Principles for medical device security, Risk management. AAMI.
• IEC 62304:2006 + A1:2015. Medical device software, Software life cycle processes. IEC.
• ISO 14971:2019. Medical devices, Application of risk management to medical devices. ISO.