FDA's software Documentation Level is either Basic or Enhanced, and it sets the minimum software documentation for your premarket submission. Choose Enhanced if a failure or flaw in any device software function could create a hazardous situation with a probable risk of death or serious injury, judged before risk controls; otherwise, choose Basic.
Key takeaways
- We measured how often 510(k) summaries for devices cleared in 2025 named a level. Of the 181 that did, 144 (80%) named Basic, and 46 more still used the retired Level of Concern terms.
- FDA's June 2023 guidance replaced the old Minor, Moderate and Major "Level of Concern" with two Documentation Levels: Basic and Enhanced.
- You judge the risk before any risk control measures, including foreseeable misuse and risks from weak cybersecurity.
- Enhanced adds three things to Basic: the software design specification, unit and integration test protocols and reports, and complete configuration management and maintenance plans.
- FDA generally recommends Enhanced for Class III devices and combination products, and recommends it for blood donor screening, blood compatibility and blood establishment software.
What is the FDA software documentation level?
It is how FDA matches the software documents you submit to the risk of your device. FDA's guidance "Content of Premarket Submissions for Device Software Functions", issued June 14, 2023, defines two levels: Basic and Enhanced [1]. FDA says the level helps identify the minimum information that would support a premarket submission [1].
The level applies to the device as a whole. FDA bases it on the risks of the device's software functions in the context of its intended use [1].
It replaced Level of Concern. The 2023 guidance replaced FDA's 2005 software guidance [1]. That older guidance sorted software into a Major, Moderate or Minor "Level of Concern" [2]. FDA's own training on the new guidance states that the Documentation Level replaces Level of Concern [3].
Where it applies. The guidance covers device software functions, including firmware, software that controls a device, software accessories and software-only devices [1]. It applies to 510(k)s, De Novo requests, PMAs, IDEs, HDEs and BLAs [1]. It does not apply to manufacturing or quality system software, or to software that is not a device [1].
How do you decide between Basic and Enhanced?
Ask one question. Could a failure or flaw in any of your device's software create a hazard with a probable risk of death or serious injury? The person at risk can be a patient, a user or someone nearby. If yes, use Enhanced. If no, use Basic [1].
Four details decide most cases:
- Judge the risk before risk controls. FDA says to assess the risks before you apply risk control measures [1]. A safety alarm or hardware interlock does not lower your Documentation Level.
- "Probable" excludes hypotheticals. FDA says the word is meant to exclude purely hypothetical risks [1].
- Serious injury has a set meaning. It is an injury or illness that is life-threatening, causes permanent impairment or damage, or needs medical or surgical intervention to prevent that [1].
- Count misuse and cybersecurity. Consider all known or foreseeable software hazards, including reasonably foreseeable misuse and the chance that weak cybersecurity compromises the device [1].
Some device categories start at Enhanced. FDA recommends Enhanced for devices that test blood donations for transfusion-transmitted infections, devices that check blood donor and recipient compatibility, automated blood cell separators, and blood establishment computer software [1]. It generally recommends Enhanced for Class III devices and for devices that are part of a combination product. For those two groups, you may argue for Basic with a detailed rationale [1].
Class alone does not decide it. In FDA's own examples, an implanted pulmonary artery pressure sensor is a Class III device but gets Basic, because the serious risks come from the implant, not the software [1]. An infusion pump, a Class II device type, gets Enhanced [1, 4].
Not sure? Ask FDA. You can request a Pre-Submission to get FDA's feedback on your Documentation Level before you submit [1]. FDA aims to send written feedback within 70 days [10]. Our Q-Submission hub explains how.
Which devices are Basic and which are Enhanced?
FDA's guidance gives 22 worked examples in Appendix A [1]. FDA stresses that they do not set the level for a device type, so assess your own device [1]. A selection:
| Device | FDA's outcome | Key point in FDA's example |
|---|---|---|
| Hip prosthesis with no software | No Documentation Level | No software |
| Non-contact infrared thermometer | Basic | No probable risk of death or serious injury from a software failure |
| Non-invasive blood pressure monitor with cuff | Basic | Same |
| Over-the-counter app that flags irregular heart rhythms | Basic | Notifies the user; not intended to replace diagnosis |
| Computerized behavioral therapy for psychiatric disorders | Basic | Adjunct to clinician-supervised treatment |
| Implanted pulmonary artery pressure sensor (Class III) | Basic | Serious risks come from the implant, not the software |
| Electric breast pump | Basic | Even a suction control failure would not create a probable risk of death or serious injury |
| Implantable pacemaker for bradycardia | Enhanced | Failure to pace could cause death or serious injury |
| Facility-use continuous ventilator | Enhanced | Wrongly timed ventilation |
| Multi-parameter patient monitor | Enhanced | Missed life-threatening arrhythmia alarms, including through a cybersecurity exploit |
| Hospital infusion pump | Enhanced | Wrong flow rate or failure to deliver |
| Sepsis alarm software in critical care | Enhanced | Failure to raise the alarm |
The pattern: software that drives therapy, keeps a patient alive, or raises an alarm someone depends on tends to be Enhanced. Software that measures, informs or supports a clinician's decision tends to be Basic.
What do you submit at each level?
Mostly the same documents. FDA's guidance lists ten software documentation elements, and only three differ between the levels [1]:
| Documentation element | Basic | Enhanced |
|---|---|---|
| Documentation Level Evaluation | Your level and the rationale | Same |
| Software Description | Overview of features, functions, inputs, outputs and hardware platforms | Same |
| Risk Management File | Risk management plan, risk assessment and risk management report | Same |
| Software Requirements Specification | Software requirements, traceable to the other documents | Same |
| System and Software Architecture Design | Diagrams of modules, layers, interfaces and data flow | Same |
| Software Design Specification | Not submitted. Keep it in your design history file; FDA may ask for it | Submit it |
| Development, configuration management and maintenance | Summaries of your life cycle plan and your configuration management and maintenance activities, or an IEC 62304 Declaration of Conformity | Basic, plus the complete configuration management and maintenance plans, or a broader IEC 62304 Declaration of Conformity |
| Software testing as part of verification and validation | Summary of unit, integration and system testing, plus the full system-level test protocol and report | Basic, plus all unit and integration test protocols and reports |
| Software Version History | Tested versions, dates and changes | Same |
| Unresolved Software Anomalies | Each remaining defect and its impact on safety and effectiveness | Same |
So Basic does not mean light. A Basic submission still includes the full risk management file, requirements, architecture diagrams and a complete system-level test protocol and report [1].
What goes in each software document?
FDA's guidance describes each element in detail [1]. The points reviewers look for:
- Documentation Level Evaluation. State your level and explain why, with reference to your risk management file and software description [1].
A simple structure for your rationale. FDA does not give a template, but a clear Documentation Level Evaluation answers four things in order:
- What the software does in the device, in one or two sentences.
- The worst hazardous situation a software failure or flaw could cause, before any risk controls.
- Whether that situation carries a probable risk of death or serious injury, using FDA's definition of serious injury.
- Your level, with references to the hazard entries in your risk management file that support it [1].
- Software Description. Explain the software's role in the device, its users, patient population, inputs and outputs, hardware and hosting platforms, and any off-the-shelf software. FDA notes that a software bill of materials (SBOM) is one way to list components [1]. For a modified device, cite the earlier submission number and highlight software changes [1].
- Risk Management File. FDA recommends following an FDA-recognized version of ISO 14971. Your plan should set risk acceptability criteria before the first risk evaluation [1].
- Development and maintenance practices. You can submit summaries of your plans, or a Declaration of Conformity to the FDA-recognized version of IEC 62304. For Basic, the declaration covers subclauses 5.1.1 to 5.1.3 and 5.1.6 to 5.1.9, clause 6 and clause 8, among others as applicable. For Enhanced, it covers subclause 5.1, clause 6 and clause 8 [1].
- Testing. Include any changes you made after failed tests, and a regression analysis with regression testing where needed. The system-level report should show that any unresolved anomalies were deferred based on a risk assessment [1].
- Unresolved anomalies. For each one, give a description, how it was found, its root cause where possible, its impact on safety and effectiveness, and your risk-based reason for not fixing it. FDA suggests a defect classification system such as ANSI/AAMI SW91 [1].
If you are building these from scratch, Complizen's Drafting Studio has templates for a risk management plan, a V&V protocol and design history file documents, each annotated with what FDA expects.
What do 2025 510(k) summaries show?
We searched the public 510(k) summaries for all devices FDA cleared in 2025 [5, 6]. In 2025, about 35% of them described software testing, and few said which Documentation Level they used:
| What the summary said | 510(k)s |
|---|---|
| Mentioned software testing, IEC 62304 or FDA's software guidance | about 1,090 of 3,070, roughly one in three |
| Named a Documentation Level | 181 |
| Named Basic | 144 (80% of those naming a level) |
| Named Enhanced | 37 (20%) |
| Used the retired Level of Concern instead, with a level | 46 (43 moderate, 3 major) |
What this tells you. First, most summaries do not state a Documentation Level, since the summary format does not require one [7]. So you often cannot read your predicate's level from its summary. Second, the old terms linger. Forty-six summaries of 2025 clearances still described software as "moderate" or "major" Level of Concern, even though the 2023 guidance replaced that system [1, 3].
Do not map old terms to new ones. A "moderate" predicate does not mean your device is Basic. Apply the 2023 test to your own device, before risk controls.
How we counted. We extracted the text of each public summary and searched for the exact phrases "Basic Documentation", "Enhanced Documentation" and "Level of Concern". We removed summaries that said the device has no software. No summary named both levels.
How does the documentation level relate to cybersecurity and AI?
Cybersecurity is assessed separately. FDA's February 2026 cybersecurity guidance says cybersecurity information should be based on cybersecurity risk, not on your Documentation Level [8]. A device with low software risk can still have significant cybersecurity risk, and the reverse [8].
Cyber devices must include an SBOM. If your device includes software, can connect to the internet, and could be vulnerable to cybersecurity threats, it is a "cyber device" under section 524B of the FD&C Act [8]. Section 524B(b)(3) requires manufacturers of cyber devices to provide an SBOM, including commercial, open-source and off-the-shelf components [8]. Our SBOM guide explains what to include.
AI-enabled devices build on the same guidance. FDA's January 2025 draft guidance on AI-enabled device software functions builds on the premarket software guidance. It notes that the software guidance itself includes significant additional considerations for AI-enabled devices [9]. The draft is not final. Our guide to SaMD clinical evidence covers the evidence side.
What mistakes cause problems with software documentation?
Most come from misreading FDA's test. These five are worth checking before you submit:
- Judging risk after mitigations. FDA says to assess before risk control measures [1]. Counting your alarms and interlocks first can make Enhanced look like Basic.
- Assuming device class decides it. FDA's examples include a Class III device at Basic and a Class II infusion pump at Enhanced [1, 4].
- Treating Basic as a short list. Basic still needs the full risk management file, requirements, architecture and a full system-level test protocol and report [1].
- Reusing the old terms. "Moderate Level of Concern" is not a Documentation Level. State Basic or Enhanced, with a rationale [1, 3].
- Scaling cybersecurity to the software level. FDA asks for cybersecurity information based on cybersecurity risk, whatever your Documentation Level [8].
Software gaps are easier to fix before FDA's review than after. Complizen's free Gap Assessment reviews your device documents against what a 510(k) needs, including software verification, and gives each gap a cost and lead time. For the wider picture, our guides to IEC 62304 and ISO 14971 for SaMD and to SaMD 510(k) rejection reasons go deeper.
Frequently asked questions
What is the FDA software documentation level?
The FDA software documentation level is either Basic or Enhanced. It sets the minimum software documentation for a premarket submission, based on the risk of the device's software functions in the context of its intended use. FDA defined it in its June 2023 guidance on premarket submissions for device software functions.
What is the difference between Basic and Enhanced documentation?
Only three elements differ. Enhanced adds the software design specification, all unit and integration test protocols and reports, and complete configuration management and maintenance plans. The other seven elements, including the risk management file and system-level testing, are the same at both levels.
When is Enhanced documentation required?
FDA recommends Enhanced when a failure or flaw in any device software function could create a hazardous situation with a probable risk of death or serious injury, judged before risk controls. FDA also generally recommends it for Class III devices and combination products, and for certain blood-related devices.
Did the Documentation Level replace the Level of Concern?
Yes. FDA's 2005 software guidance used a Major, Moderate or Minor Level of Concern. The June 14, 2023 guidance replaced it with two Documentation Levels, Basic and Enhanced. FDA's own training on the guidance states that the Documentation Level replaces Level of Concern.
Is a moderate Level of Concern the same as Basic?
No. The two systems use different tests, so there is no direct mapping. Apply FDA's 2023 test to your own device: could a software failure create a probable risk of death or serious injury, before risk controls? If yes, Enhanced. Otherwise, Basic.
Do I submit the software design specification for Basic documentation?
No. For Basic, FDA does not recommend submitting the software design specification. You should still document it in your design history file, and FDA may ask for it during review. For Enhanced, you submit it as part of your premarket submission.
Can I use IEC 62304 to meet FDA's software documentation recommendations?
Partly. For the development, configuration management and maintenance element, FDA accepts a Declaration of Conformity to the FDA-recognized version of IEC 62304, covering the clauses the guidance lists. You still submit the other elements, such as the risk management file and test reports.
Do Class II devices need Enhanced documentation?
Not by default. The level depends on the software's risk, not the device class. FDA's examples include Class II device types at both levels: a blood pressure monitor and a breast pump at Basic, and a hospital infusion pump at Enhanced.
Does the documentation level apply to software-only devices?
Yes. The guidance covers software-only devices, including software that runs on general-purpose computers or phones. It also covers firmware, software that controls hardware, and software accessories. It applies to 510(k)s, De Novo requests, PMAs, IDEs, HDEs and BLAs. It does not cover manufacturing or quality system software.
Does the documentation level affect cybersecurity documentation?
No. FDA's February 2026 cybersecurity guidance says cybersecurity information should be based on cybersecurity risk, not on your Documentation Level. A device with low software risk can still have high cybersecurity risk. Cyber devices under section 524B must also include a software bill of materials.
What should the unresolved software anomalies list include?
For each anomaly, give a description, how it was found, its root cause where possible, its impact on safety and effectiveness, and your risk-based reason for not fixing it. FDA suggests a defect classification system such as ANSI/AAMI SW91. Also reference any notice or labeling that tells users about the anomaly.
Can I ask FDA which documentation level applies to my device?
Yes. FDA's software guidance says you may submit a Pre-Submission to get feedback on your device's Documentation Level and recommended documentation before your premarket submission. FDA aims to send written Pre-Sub feedback within 70 days. Include your draft rationale so FDA can react to it.
References
- FDA. Content of Premarket Submissions for Device Software Functions. Final guidance, June 14, 2023.
- FDA. Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices. May 11, 2005, superseded.
- FDA. Content of Premarket Submissions for Device Software Functions: Final Guidance, webinar slides. July 20, 2023.
- openFDA. Device classification API, product codes FRN (infusion pump, 21 CFR 880.5725), DXN (non-invasive blood pressure system, 21 CFR 870.1130) and HGX (powered breast pump, 21 CFR 884.5160), all Class II. Accessed October 9, 2026.
- openFDA. 510(k) API, decisions dated January 1 to December 31, 2025. Accessed October 9, 2026.
- FDA. 510(k) Premarket Notification database, 510(k) summaries for 2025 clearances. Accessed October 9, 2026.
- eCFR. 21 CFR 807.92, Content and format of a 510(k) summary. Up to date as of October 7, 2026.
- FDA. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Final guidance, February 3, 2026.
- FDA. Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations. Draft guidance, January 2025.
- FDA. Requests for Feedback and Meetings for Medical Device Submissions: The Q-Submission Program. Final guidance, May 29, 2025.