FDA's new approach to software documentation-A shift to risk-based levels

FDA Software Documentation: Risk-Based Requirements

Software drives a growing share of medical devices, from firmware in an infusion pump to standalone diagnostic apps. If your device includes software and goes to the FDA through a 510(k), De Novo request, or premarket approval (PMA) application, the FDA expects specific software documentation. This guide explains the Basic and Enhanced documentation levels, what each requires, and how to prepare your submission.

U.S. Food and Drug Administration – FDA Software Documentation: A Risk-Based Shift

On June 14, 2023, the FDA published its final guidance, "Content of Premarket Submissions for Device Software Functions," which replaced the May 2005 guidance on software contained in medical devices. The old three-tier Level of Concern system is now a two-tier Documentation Level: Basic or Enhanced. The change is part of the FDA's effort to modernize its approach and keep pace with fast-moving software technology. 

The guidance aligns its terminology with recognized standards such as ISO 14971 (risk management) and IEC 62304 (software life cycle processes). It is non-binding, but it reflects what reviewers expect to see.

Key points about scope:

• What it covers: Device software functions, including firmware, software in a medical device (SiMD), and software as a medical device (SaMD). It applies to premarket submissions such as 510(k), De Novo, PMA, IDE, HDE, and BLA.
• What it excludes: Software that is not a device, and software used only in automated manufacturing or quality systems.
• What it is not: Documentation level is separate from medical device classification (Class I, II, or III). A device's class sets its regulatory pathway, while the Documentation Level sets how much software documentation the FDA expects.

From Levels of Concern to Risk-Based Documentation Level

Under the 2005 guidance, software documentation fell into three levels, Minor, Moderate, and Major, depending on the potential impact of a software failure. The 2023 framework uses two levels based on the risk of the device's software functions in the context of its intended use.

The former Major level, where a failure could lead to death or serious injury, became Enhanced Documentation, and the Minor and Moderate levels merged into Basic. Two rules shape the assessment:

• Assess risk before controls. Evaluate hazards before risk control measures are applied.
• Look at the whole picture. Consider foreseeable misuse, whether intentional or not, and the chance that the device is compromised through inadequate cybersecurity.

The level reflects the device as a whole, not each function separately.

Basic Documentation Level

Applicability: Basic Documentation is the baseline for any premarket submission that includes device software functions where Enhanced Documentation does not apply. This covers most software.

Key documentation:

• Documentation Level rationale
• Software description and architecture diagram
• Software Requirements Specification (SRS)
• Risk management file: plan, assessment, and report
• Summary of testing activities and system-level test protocol and report
• Software version history
• List of unresolved anomalies

Simplifications:

• The FDA does not recommend including a Software Design Specification (SDS). Keep it in your design and development records.
• A Declaration of Conformity to specific clauses of the FDA-recognized version of IEC 62304 can replace the summary of development, configuration management, and maintenance practices.

Enhanced Documentation Level

Applicability: Enhanced Documentation applies when a failure or flaw of any device software function could create a hazardous situation with a probable risk of death or serious injury to a patient, user, or others in the environment of use.

The FDA also recommends Enhanced Documentation for:

• Blood establishment computer software (BECS) and certain blood-screening or compatibility devices
• The device constituent part of a combination product
• Class III devices

A sponsor may use Basic instead for a combination product or Class III device, but only with a well-argued rationale. For example, the FDA's own examples treat an implantable pulmonary artery pressure sensor and an HPV test, both Class III, as Basic because a software failure would not itself cause probable death or serious injury.

Key documentation: Everything in Basic, plus:

• The Software Design Specification (SDS)
• Unit and integration test protocols and reports
• Complete configuration management and maintenance plans

A Comparison Of The Minimum Documentation Required By The New Guidance

The table compares what the 2005 guidance asked for at the Minor Level of Concern with what the 2023 guidance recommends at the Basic level.

The net effect is that software that used to sit at Minor now needs more documentation, including a full risk management file, an architecture diagram, and an anomaly list.

FDA Software Documentation Requirements

Basic Documentation Requirements

• Documentation Level evaluation: the level you chose and why.
• Software description: features, functions, inputs, outputs, and hardware platforms.
• Risk management file: risk management plan, risk assessment, and risk management report.
• SRS: organized, traceable software requirements.
• Architecture diagram: modules, layers, interfaces, and data flow.
• Development and maintenance practices: a summary, or a Declaration of Conformity to specified IEC 62304 clauses.
• Testing: a summary of unit, integration, and system testing, plus a system-level test protocol and report.
• Version history and unresolved anomalies.

Enhanced Documentation Requirements

Everything above, plus:

• SDS showing how the software design implements the SRS.
• Unit and integration test protocols and reports, including expected results, observed results, and pass/fail determinations.
• Configuration management and maintenance plans in full, or an IEC 62304 Declaration of Conformity covering subclause 5.1 and clauses 6 and 8.

Key Software Documentation for Premarket Submissions

Software Description and Architecture

The software description gives reviewers an overview of what the software does. Cover the role of the software in the intended use, its users and patient population, and its platforms and hosting environments. Include whether it uses off-the-shelf software, the final release version, and the inputs and outputs. For AI/ML-enabled functions, describe the model, the training data, and how bias was addressed.

The architecture diagram is a roadmap of the design. It should show:

• Modules and layers
• Their relationships and data flow
• How users and outside products interact with the system, including IT infrastructure and interoperable devices

Keep diagrams legible, consistent in symbols, and tailored to the level of detail reviewers need. Multiple diagrams are fine, including cybersecurity architecture diagrams, as long as one high-level diagram ties them together.

Risk Management Documentation

The risk management file should follow an FDA-recognized version of ISO 14971 and contain three parts:

• Plan: risk acceptability criteria and how overall residual risk will be judged.
• Assessment: hazard identification, hazardous situations, risk estimation and evaluation, risk controls, verification of those controls, residual risk, and benefit-risk analysis where needed. Controls should be ranked from design changes to protective measures to information for safety.
• Report: confirmation that the plan was carried out and that overall residual risk is acceptable.

Trace each hazard to the requirement, design element, and test that address it. Usability engineering feeds this file too. Use errors found in formative and summative evaluation, done under IEC 62366-1, should become hazards, requirements, and risk controls. Human factors documentation itself is submitted separately.

Under 21 CFR Part 820, now the QMSR, risk management and software validation link to ISO 13485 subclauses 7.1 and 7.3.7, so the same evidence supports both your quality system and your submission.

Software Requirements and Design Specifications

The SRS says what the software will do. It typically covers inputs and outputs, functions, performance, interfaces, user interaction, error handling, the operating environment, safety requirements derived from risk assessment, and value ranges and limits. Make every requirement traceable, identify the ones most critical to safety and effectiveness, and highlight changes when the submission covers a modified device.

The SDS says how the software implements the SRS. It is part of the Enhanced submission. At the Basic level you keep it in your design and development records, and the FDA may ask for it during review. Under the QMSR, the terms "design controls" and "design validation" no longer appear, and the equivalent activities sit in ISO 13485 Clause 7.3. The old design history file is now the design and development file.

Software Testing and Verification

Testing evidence should show the software was verified and validated at the right levels:

• Basic: a summary of unit, integration, and system testing that names the software version tested and the overall pass/fail results, plus a system-level test protocol and report. Include any intentional changes made after failed tests, and regression analysis and testing for unintended effects of software changes.
• Enhanced: the same, plus unit and integration protocols and reports.

Reports should show that protocols were executed with passing results and that any unresolved anomalies were deferred based on a risk assessment. Testing of the user interface, such as summative usability testing, and cybersecurity testing are documented separately under their own FDA guidance.

Revision History and Unresolved Anomalies

Software version history. List each tested version with its date, version number, and a brief description of changes from the previous tested version. The last entry should be the released version, along with any differences from the tested one. Keep version naming consistent with the version or model number on your label and in your GUDID record, because each device version or model needs its own device identifier.

Unresolved anomalies. An unresolved anomaly is a known defect you chose not to fix, based on risk. For each one, document:

• What the anomaly is
• How it was found and, where possible, its root cause
• Its impact on safety and effectiveness
• The outcome of the evaluation
• The risk-based rationale for leaving it

Consider using a defect taxonomy such as ANSI/AAMI SW91, and communicate workarounds to users where appropriate.

Document Section

The "document section" column in the comparison table lists the deliverables the guidance recommends: Documentation Level evaluation, software description, risk management file, SRS, architecture diagram, SDS, development and maintenance practices, testing, version history, and unresolved anomalies. Together they show that planning, requirements, risk assessment, design review, traceability, change management, and testing were done properly, supporting the conclusion that the software was designed, verified, and validated.

2005 Guidance (Minor LOC)

At Minor Level of Concern, the 2005 guidance asked for a level of concern statement, a summary software description, a device hazard analysis, a summary of functional requirements, traceability analysis, a functional test plan with pass/fail results, and revision level history. It did not ask for an architecture chart, a design specification, a development environment description, or a list of unresolved anomalies.

2023 Guidance (Basic Documentation)

Basic Documentation adds substance to those same areas. It asks for a detailed software description, a full risk management file, detailed and traceable requirements, an architecture diagram, a summary of development and maintenance practices (or an IEC 62304 Declaration of Conformity), unit-to-system test summaries with a system-level protocol, and an unresolved anomaly list. It still leaves out the SDS.

Why The FDA's New Guidance Is Important

• Clearer risk definitions. The assessment now starts with hazards before risk controls, and explicitly covers foreseeable misuse and cybersecurity compromise. That makes it easier to compare devices and explain your choice of level.
• Easier submissions for low-risk devices. Basic Documentation drops the SDS from the submission and lets an IEC 62304 Declaration of Conformity replace some process summaries. Some details, such as a more complete SRS, are now expected.
• Stricter rules for high-risk devices. Enhanced Documentation asks for full design detail, unit and integration testing, and complete configuration management and maintenance plans.
• Alignment with international standards. Because the guidance rests on ISO 14971, IEC 62304, and ISO 13485 concepts, the same evidence supports multiple markets.

Together these changes balance simplicity for low-risk devices with robust checks for high-risk ones.

Implications For Manufacturers

The guidance brings benefits and challenges.

• Re-evaluate your processes. Review your software development and documentation practices against the two levels. Make sure they fit your quality system under 21 CFR Part 820, which has been the QMSR since February 2, 2026, and ISO 13485, and that your design and development file stays in step with development work. Records created long after the work was done can raise concerns about control of your design process.
• Expect more documentation for low-risk devices. Software once treated as Minor now needs a full risk management file, an architecture diagram, and an unresolved anomaly list, plus more detailed requirements and test evidence.
• Make cybersecurity a priority. Cybersecurity affects your risk assessment and Documentation Level, and the FDA's separate premarket cybersecurity guidance sets out the specific documents expected.
• Coordinate with usability engineering. Formative and summative evaluation results should feed your risk management file and requirements.
• Plan for other markets. In the EU, the same software evidence supports your technical documentation and the clinical evaluation report (CER) under the MDR.
• Use the Pre-Submission process. The FDA welcomes Pre-Submissions to get feedback on your Documentation Level and recommended documentation before you file.

The FDA's revised guidance replaces a rigid, concern-based framework with a flexible, risk-driven model. Manufacturers who adapt early can streamline regulatory reviews and bring safe, innovative devices to market efficiently.

Frequently Asked Questions

1. What is the difference between Basic and Enhanced software documentation?
Basic Documentation is the baseline for software where a failure would not create a hazardous situation with probable death or serious injury. Enhanced applies when it could. Enhanced includes everything in Basic, plus the SDS, unit and integration test protocols and reports, and complete configuration management and maintenance plans.

2. Does FDA require software requirements and design specifications in a premarket submission?
The guidance recommends an SRS at both levels. It recommends the SDS only at the Enhanced level. At the Basic level you should keep the SDS in your design and development records, and the FDA may request it during review. The guidance is non-binding, but reviewers rely on it.

3. Does every medical device software function require the same level of FDA documentation?
No. The level depends on risk in the context of the device's intended use, and it applies to the device as a whole. If any software function could present a hazardous situation with a probable risk of death or serious injury, the device generally calls for Enhanced Documentation. A hardware-only device with no software has no Documentation Level at all.

4. How should manufacturers determine the appropriate FDA software documentation level?

1. Identify all device software functions.
2. Assess hazards before applying risk controls, following ISO 14971.
3. Include foreseeable misuse and the likelihood of compromise through weak cybersecurity.
4. Ask whether a failure could present a probable risk of death or serious injury.
5. Check the categories where Enhanced is generally recommended: blood establishment software, combination product device parts, and Class III devices. Justify any exception.
6. Record your rationale in the Documentation Level evaluation, and consider a Pre-Submission for feedback.

5. What are the common mistakes manufacturers make when preparing FDA software documentation?

• Confusing medical device classification with Documentation Level. A Class III device can be Basic, and a Class II device can be Enhanced.
• Assessing risk after controls instead of before.
• Building documents retrospectively instead of alongside development.
• Weak traceability between hazards, requirements, design, and tests.
• Submitting only a hazard analysis instead of a full risk management file.
• Skipping or under-documenting the unresolved anomaly list.
• Treating an IEC 62304 Declaration of Conformity as broader than it is. It must cover the specific clauses the FDA lists.
• Version numbers that don't match across the submission, the label, and GUDID.
• Illegible or overly high-level architecture diagrams.
• Leaving out cybersecurity and usability evidence, including formative and summative evaluation results.