Of the Many Documents FDA Requires for Software and Cybersecurity, 24 Must be Attached in Your eSTAR Form

Summary

• FDA’s eSTAR form requires 24 distinct attachments, but each can contain multiple documents
• Software testing attachment alone can include unit, integration, and system test reports
• Cybersecurity testing attachment encompasses vulnerability scanning, penetration testing, fuzz testing, and more
• SBOM requires both machine-readable and human-readable formats
• Understanding these requirements helps manufacturers prepare comprehensive submissions
• Strategic frameworks like ANSI/AAMI SW96 can streamline documentation

Introduction

If you’re developing a connected medical device today, you’re facing a hidden challenge. Beyond the engineering complexities, there’s a documentation mountain to climb. FDA’s eSTAR form requires 24 distinct attachments to demonstrate your device’s software and cybersecurity safety.

But here’s the catch: those 24 attachments often contain multiple documents each. A single “testing” attachment might include dozens of individual test reports.

This isn’t just paperwork. It’s comprehensive proof that your device won’t harm patients through software failures or cyber attacks.

Let’s break down exactly what FDA requires in these attachments. You’ll learn what documents you need, why they matter, and how to tackle this challenge systematically.

The Two-Pronged Documentation Challenge

Medical device manufacturers face documentation requirements from two major FDA guidances:

Software Documentation comes from FDA’s “Content of Premarket Submissions for Device Software Functions” guidance. This covers how your software works, how you built it, and how you tested it.

Cybersecurity Documentation stems from “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions.” This proves your device can resist cyber threats and protect patient data.

These requirements don’t just add up; they compound. Your software architecture document must align with your security architecture views. Your risk management must address software failures, while cybersecurity requires separate risk analysis with different criteria.

The result? A complex web of interrelated attachments that must tell a consistent story about your device’s safety.

Software Documentation Requirements (10 Core Attachments)

Let’s start with the software side. FDA requires these core attachments:

1. Documentation Level Evaluation

This attachment explains whether your device needs “Basic” or “Enhanced” documentation. The level depends on your device’s risk to patients. You must justify your choice with clear rationale.

2. Software Description

A comprehensive overview of your software’s features, functions, and hardware platforms. Include flow charts and diagrams that explain how the software works. If you’re updating an existing device, highlight what changed.

3. Risk Management File

Following ISO 14971, this shows how you identified and mitigated software-related risks. It includes your risk management plan, risk assessment, and final risk management report. Note that this addresses safety risks from software failures, not cybersecurity vulnerabilities.

4. Software Requirements Specification (SRS)

The SRS lists everything your software must do. Each requirement needs to be testable and traceable. Modern teams might use user stories or use cases, but FDA still expects clear, numbered requirements.

5. System and Software Architecture Design

Detailed diagrams showing modules, interfaces, and data flows. FDA wants to see how users interact with your system and how data moves through it.

6. Software Design Specification (SDS)

Required only for Enhanced Documentation Level. This explains the technical details of how your software implements the requirements from your SRS.

7. Software Development, Configuration Management, and Maintenance Practices

A summary of your development lifecycle and how you control changes. Many companies use a Declaration of Conformity to IEC 62304 to satisfy this requirement.

8. Software Testing Documentation

Here’s where it gets complex. This single attachment can include multiple test reports:

• Basic Level: System test protocol and report only
• Enhanced Level: Unit test protocols and reports, integration test protocols and reports, AND system test protocols and reports

Each test level requires protocols showing expected results, actual results, and pass/fail determinations. For a complex device, this attachment might contain dozens of individual test documents.

9. Software Version History

A complete history of tested versions, including dates and descriptions of changes. This helps FDA understand your device’s evolution.

10. Unresolved Software Anomalies

A list of known bugs you haven’t fixed, with explanations of why they don’t impact safety or effectiveness.

Cybersecurity Documentation Requirements (14 Core Attachments)

Now for the cybersecurity side. These attachments ensure your device can resist attacks:

1. Security Risk Management Report

The master document that summarizes all your cybersecurity efforts. It ties together your threat modeling, risk assessments, and mitigation strategies.

2. Threat Model

A systematic analysis of how attackers might compromise your device. This identifies vulnerabilities and guides your security design.

3. Cybersecurity Risk Assessment

This evaluates each threat’s likelihood and impact, separate from your safety risk assessment. It uses different criteria focused on exploitability and patient harm if exploited.

4. Software Bill of Materials (SBOM)

A complete inventory requiring multiple formats:

• Machine-readable SBOM (SPDX or CycloneDX format)
• Human-readable documentation
• Version numbers for all components
• License information
• Known vulnerabilities

For a typical connected device, the SBOM attachment might include several files to meet all requirements.

5. Software Level of Support

Documentation showing whether each software component is actively maintained, abandoned, or nearing end-of-life.

6. Safety and Security Assessment of Cybersecurity Vulnerabilities

Analysis of how cybersecurity vulnerabilities could impact patient safety. This bridges the gap between cyber risks and clinical hazards.

7. Assessment of Unresolved Anomalies for Cybersecurity Impact

Evaluates whether your unresolved software bugs create security vulnerabilities.

8. Cybersecurity Metrics

Quantitative measures like:

• Percentage of vulnerabilities patched
• Time from vulnerability discovery to patch deployment
• Update installation success rates

9. Cybersecurity Controls

Documentation of security measures across eight categories:

• Authentication
• Authorization
• Cryptography
• Code integrity
• Confidentiality
• Event detection
• Resilience
• Updateability

10. Security Architecture Views

Visual diagrams showing (at minimum):

• Global system view (all connections)
• Multi-patient harm view (systemic risks)
• Updateability view (how to deploy patches)
• Security use case views (specific threat scenarios)

More complex devices require additional views beyond these minimums.

11. Cybersecurity Testing

This attachment encompasses multiple testing types and reports:

• Vulnerability scanning results
• Penetration testing reports (with tester qualifications)
• Robustness testing outcomes
• Fuzz testing results
• Static code analysis reports
• Dynamic code analysis results
• Software composition analysis
• Attack surface analysis

Each testing type produces its own detailed report. A comprehensive cybersecurity testing attachment might include 10 or more individual test reports.

12. Cybersecurity Management Plan

Your process for maintaining security throughout the device lifecycle, including vulnerability monitoring and patch management.

13. Cybersecurity Labeling

User-facing documentation explaining security features, update procedures, and end-of-support dates.

14. Interoperability Risk Assessment

Analysis of risks when your device connects to hospital networks or other medical devices.

The eSTAR Submission Challenge

Organizing 24 attachments (containing potentially 50+ individual documents) in FDA’s eSTAR system presents unique challenges. The electronic submission format requires:

• Proper document naming conventions
• Correct placement in folder structures
• Appropriate cross-references between sections
• Consistent terminology across all attachments

FDA reviewers expect to navigate your submission easily. Poor organization leads to additional information requests and delays.

Common pitfalls include:

• Duplicating information instead of cross-referencing
• Inconsistent terminology between software and cybersecurity documents
• Missing traceability between related documents
• Incomplete architecture diagrams

Strategies for Streamlining Software Documentation

Leverage IEC 62304 Framework

IEC 62304 provides a complete software lifecycle framework. By following this standard, you automatically generate much of the required documentation. FDA accepts Declarations of Conformity to IEC 62304 for several documentation requirements.

The standard defines processes for:

• Software development planning
• Requirements analysis
• Architectural design
• Detailed design
• Implementation and verification
• Integration testing
• System testing
• Software release

Each process produces specific outputs that align with FDA’s expectations.

Strategies for Streamlining Cybersecurity Documentation

Implement ANSI/AAMI SW96

This new standard specifically addresses FDA cybersecurity requirements. SW96 provides:

• Templates for all required cybersecurity documents
• Clear mapping to FDA guidance requirements
• Integration with IEC 62304 processes
• Practical examples and implementation guidance

SW96 builds on the foundation of TIR57 while adding more specific requirements for modern connected devices.

Utilize Secure Product Development Framework (SPDF)

FDA recommends using an SPDF to integrate security throughout development. This framework:

• Embeds security activities in your existing development process
• Generates documentation as a natural output
• Ensures consistency between design and security documents
• Supports continuous risk management

An SPDF isn’t a specific standard; it’s an approach that weaves security into every development phase.

Common Documentation Deficiencies

FDA frequently cites these documentation problems:

Missing Traceability – Requirements that can’t be traced to tests. Security controls without clear implementation evidence. Risk mitigations without verification.

Insufficient Architecture Views – Diagrams that don’t show all external connections. Missing trust boundaries. Unclear data flows.

Incomplete SBOM Information – Missing version numbers. Unknown support status. Unidentified dependencies.

Inadequate Threat Modeling – Generic threats not specific to your device. Missing attack vectors. Unrealistic threat actors.

Disconnected Documentation – Software documents that don’t align with cybersecurity documents. Different risk numbering systems. Conflicting architectural descriptions.

Best Practices for Documentation Management

1. Start Early

Begin documentation during design phase. Don’t wait until development is complete. Early documentation helps identify gaps and inconsistencies.

2. Maintain Version Control

Track all document revisions. Know what changed and why. FDA may ask about evolution of your approach.

3. Ensure Consistency

Use the same terminology across all documents. If you call it a “user interface” in one document, don’t call it a “operator console” in another.

4. Review Thoroughly

Conduct internal reviews before submission. Have someone unfamiliar with the project try to understand your documents. Fix confusion before FDA sees it.

5. Use Cross-References

Link related information across documents. Don’t copy and paste. Use clear references like “See Risk ID SW-42 in the Risk Management File.”

Conclusion

Yes, 24 attachments containing 50+ documents seems overwhelming. But each serves a purpose in demonstrating your device’s safety. These FDA requirements reflect the complexity of modern medical devices.

The key is developing a systematic approach. Use established frameworks like IEC 62304 and ANSI/AAMI SW96. Build documentation into your development process rather than treating it as an afterthought.

Remember: this documentation isn’t just for FDA. It’s your blueprint for maintaining device safety throughout its lifecycle. When a new vulnerability emerges, your documentation shows exactly how to assess and address the risk.

Start building your documentation system now. Your future self, and your patients, will thank you.

Resources and Tools

FDA Guidance Documents:

• Content of Premarket Submissions for Device Software Functions
• Cybersecurity in Medical Devices: Quality System Considerations

Key Standards:

• ANSI/AAMI SW96:2023 – Medical device security—Security risk management for device manufacturers
• IEC 62304:2006+A1:2015 – Medical device software—Software life cycle processes
• ISO 14971:2019 – Medical devices—Application of risk management to medical devices

Documentation Management Tools:

• Requirements management systems (IBM DOORS, Jama Connect)
• Risk management platforms (Greenlight Guru, Arena PLM)
• Architecture modeling tools (Enterprise Architect, Visio)

Templates and Checklists:

• AAMI SW96 documentation templates
• FDA eSTAR submission checklist
• IEC 62304 compliance checklist