Software Documentation Levels for FDA Submissions: Basic vs Enhanced Under the 2023 Guidance

Why Software Documentation Level Is One of the Most Misunderstood Decisions in a Device Submission

If you are developing a Software as a Medical Device (SaMD) or a device with embedded software, one of the earliest and most consequential decisions you will make is determining your software documentation level. Get it wrong, and you are either submitting a mountain of documentation that FDA did not ask for, or you are triggering an Additional Information (AI) request that stalls your clearance by months.

FDA's 2023 guidance, 'Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions' and the long-standing 'Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices' (2005, currently under revision), together form the foundation of what reviewers expect. Understanding how these two frameworks interact is not optional -- it is table stakes for any submission involving software.

The Two Documentation Levels: What They Actually Mean

FDA categorizes software documentation into two levels based on the risk the software presents if it were to fail.

Basic Documentation Level

Basic documentation applies when a software failure would result in minor injury or no injury. Think software that provides administrative functions, low-risk decision support, or controls a device where a failure would not cause serious harm. Under the 2005 guidance, this documentation set is streamlined and focused on demonstrating that a defined software development lifecycle (SDLC) exists and was followed.

A Basic documentation package typically includes:

• A Software Description including the intended use and device hazard analysis
• The Software Requirements Specification (SRS) at a summary level
• Architecture design chart
• Software development and maintenance practices, including configuration management and error correction
• Validation and testing documentation confirming the software performs as intended under expected conditions

The key word here is 'summary.' FDA is not expecting every unit test or every branch of your code to be documented in the submission itself -- but that documentation must exist in your Design History File (DHF) under 21 CFR Part 820.30.

Enhanced Documentation Level

Enhanced documentation applies when a software failure could cause or contribute to serious injury or death. This is the standard for most SaMD classified as Class II or III, diagnostic software that drives treatment decisions, drug delivery systems, and any software subject to the Software Bill of Materials (SBOM) requirements under the 2023 cybersecurity guidance.

An Enhanced documentation package includes everything in Basic, plus:

• Complete Software Requirements Specification
• Architecture design document with interface definitions
• Software Design Specification (SDS)
• Traceability analysis linking requirements through design, testing, and hazard mitigation
• Complete hazard analysis including software-specific hazard scenarios
• Verification and validation protocols and results, including anomaly resolution
• Revision level history
• Unresolved anomalies list with risk justification

The traceability matrix alone is where many startup teams stumble. FDA reviewers use it to verify that every identified risk has a mitigation that is tested and verified. If a hazard is identified but you cannot show a test that confirms the mitigation works, expect a deficiency letter.

How the 2023 Cybersecurity Guidance Changes the Equation

The 2023 cybersecurity guidance introduced requirements that cut across both documentation levels. Under Section 524B of the FD&C Act (added by the Consolidated Appropriations Act of 2023), manufacturers of 'cyber devices' must now submit a Software Bill of Materials (SBOM) and a cybersecurity plan covering monitoring, identifying, and addressing post-market vulnerabilities.

What this means practically: even a device that qualifies for Basic documentation under the software guidance may now require Enhanced-level rigor when it comes to cybersecurity artifacts. If your device connects to a network, uses off-the-shelf software components, or communicates with other devices or systems, you are almost certainly a 'cyber device' under the statute.

The SBOM requirement alone -- listing every software component including open-source libraries and their version numbers -- demands a level of software inventory management that many early-stage companies have not implemented. Starting this process at submission time is far too late.

Common Mistakes That Trigger AI Requests

• Misclassifying documentation level: Submitting Basic documentation for a device with software that controls therapy delivery or interprets diagnostic data.
• Incomplete traceability: Listing requirements and tests without demonstrating the linkage between hazards, design controls, and verification results.
• Missing anomaly resolution: Listing known software bugs without providing a risk-based justification for why they are acceptable in the cleared state.
• Ignoring SBOM obligations: Assuming cybersecurity artifacts only apply to Class III devices. The 2023 guidance applies broadly to any device that meets the definition of a cyber device under 21 CFR.
• Static documentation in an agile shop: Submitting documentation that reflects an early design iteration rather than the final locked version going to market.

Determining the Right Level for Your Device

The determination starts with your software risk assessment, which should be conducted under IEC 62304 and aligned with your overall risk management process under ISO 14971. The severity of harm resulting from a software failure -- not the probability -- is the primary driver of documentation level. A device that could cause serious harm even under a low-probability failure scenario typically requires Enhanced documentation.

If you are developing under a Quality Management System (QMS) aligned with 21 CFR Part 820 or ISO 13485, this determination should be documented, justified, and traceable back to your hazard analysis.

Work With a Firm That Has Done This Before

At ADB Consulting and CRO Inc., we have helped medical device startups and growth-stage companies navigate software documentation requirements from pre-submission through clearance. Whether you are preparing your first 510(k) or responding to an AI request on an Enhanced submission, we know what FDA reviewers look for -- and how to get your documentation right the first time.

Book a free discovery call with Andre Butler and our regulatory team at adbccro.com. We will assess your current software documentation posture and give you a clear, actionable path forward.