If your device includes software that meets the definition of a device software function, you need to understand exactly what FDA expects in your premarket submission. You also need a defensible, documented decision about which documentation level applies. FDA's 2023 final guidance on the content of premarket submissions for device software functions replaced the 2005 framework that most teams grew up with. It introduces a two-tier documentation structure that changes how you plan, resource, and assemble your software file. This article is a working reference for regulatory operations leads, software quality leads, and SaMD/SiMD product owners who are translating that guidance into a concrete document set.
---
Overview
On June 14, 2023, FDA finalized its guidance titled "Content of Premarket Submissions for Device Software Functions." The guidance was published in the Federal Register the same day. It provides recommended documentation that sponsors should include so FDA can evaluate safety and effectiveness of device software functions in premarket submissions.
The 2023 guidance supersedes the 2005 guidance. The older guidance organized documentation around three Levels of Concern. The 2023 guidance replaces those tiers with two: Basic and Enhanced.
Operationally, the change raises the documentation floor. Every submission with a device software function requires at minimum Basic documentation. Enhanced documentation is explicitly required when a pre-mitigation hazardous situation could probably lead to death or serious injury. That reframing affects planning, artifact creation, traceability, and V&V scope. The sections that follow address those practical topics.
The full guidance PDF is the authoritative reference. This article interprets the guidance to help you assemble submission-ready artifacts and document defensible decisions.
---
What counts as a device software function
FDA uses "device software function" specifically for software functions that meet the statutory device definition. That definition covers functions that diagnose, cure, mitigate, treat, or prevent disease or conditions, or that affect body structure or function. The guidance excludes categories such as administrative support, general wellness, certain EHR features, and some clinical decision support that meet Cures Act criteria.
The operative test is what the function does, not how it is delivered. For example, a mobile app that calculates clinician insulin dosing recommendations can be a device software function. A scheduling module in the same app typically is not.
When scoping a submission, identify which functions are device software functions and which are not. Bound your architecture, risk analysis, and V&V evidence to the device functions. Non-device functions should still be described if they interact with or could affect device functions. But they are not the primary subject of the software documentation. For Multiple Function Device (MFD) products, the guidance explicitly expects clear identification and partitioning so the reviewer can focus on the functions that pose device-related risk.
---
Basic vs. Enhanced documentation: making a defensible determination
The central decision under the 2023 guidance is whether a device software function requires only Basic documentation or Basic plus Enhanced documentation. Enhanced documentation is required when the function is — or contributes to — a hazardous situation where a probable risk of death or serious injury exists if the software fails or behaves unexpectedly.
Crucially, that assessment is made on a pre-mitigation basis. Determine whether the hazardous situation could lead to serious harm before applying software-level risk controls. This pre-mitigation framing is consequential for teams. Thinking in terms of residual risk after controls can lead to under-classifying functions.
If a software failure in a ventilator's pressure regulation function could, absent controls, plausibly produce a life-threatening respiratory event, that function requires Enhanced documentation. This applies regardless of later safeguards. Basic documentation is the universal floor. Enhanced is additive where the pre-mitigation threshold is met. Hogan Lovells' analysis of the finalized guidance underscores this point: Basic applies unless Enhanced is specifically warranted by the pre-mitigation risk assessment.
A short decision matrix with example borderline scenarios
A structured decision process helps teams make and document the Basic vs. Enhanced call early:
Step 1: Identify all device software functions in scope and list them discretely.
Step 2: For each function, identify hazardous situations — ways in which erroneous, missing, or delayed software output could place patients, users, or third parties at risk, using ISO 14971 concepts to structure the analysis.
Step 3: Assess probable harm severity on a pre-mitigation basis: would the hazardous situation, absent additional controls, realistically lead to death or serious injury? "Probable" means a realistic path to serious harm, not merely theoretical.
Step 4: Apply the documentation level: if any hazardous situation for the function could probably lead to death or serious injury → Enhanced applies; otherwise → Basic applies.
Step 5: Document the rationale in your DHF, recording hazard identification, severity assessment, and the conclusion with supporting reasoning.
Worked example — borderline configuration UI scenario:
Product: an infusion pump with a touchscreen configuration interface used to set drug concentration and infusion limits.
Pre-mitigation hazard analysis: if the configuration function stores a ten-times-higher concentration due to a unit-conversion bug, a clinician could program the pump correctly based on the screen while the internal value causes over-infusion. This hazardous situation could plausibly produce serious injury or death before any hardware alarm responds.
Conclusion: Enhanced documentation applies. Indirect contributions (misconfiguration enabling downstream harm) qualify a function for Enhanced documentation. Do not assume UIs, displays, or calculators are Basic without tracing outputs to patient harm.
---
What to include: document checklist by level
The guidance provides recommended documentation content for both levels. The lists below reflect those expectations and illustrate the difference in depth between Basic and Enhanced submissions.
Basic documentation (required for all device software functions):
- Software description, including intended use and device function
- Software requirements specification (SRS) or equivalent requirements documentation
- Software architecture description (high-level design) covering major components, interfaces, and data flows
- Overview of the software design sufficient for FDA to understand how requirements are implemented
- Software version history and configuration management overview
- Description of the development environment and software lifecycle model
- Unresolved software anomaly list with impact and acceptability justification
- Summary of verification and validation activities (V&V summary)
- Risk management file summary, including the risk management plan, hazard analysis, and risk management report
Enhanced documentation (in addition to Basic, when the risk threshold is met):
- Complete software requirements specification with traceability
- Detailed software design specification (SDS/architectural design document)
- Software development environment description in full
- Detailed risk analysis documentation (FMEAs, fault trees, or equivalent) with traceability to requirements and tests
- Comprehensive V&V plans and results, including unit, integration, and system-level testing with coverage rationale
- Detailed traceability matrix linking requirements to risk controls and verification/validation evidence
- Full unresolved anomaly log with explicit severity classification, impact analysis, and written acceptability rationale
A common misconception is that Basic documentation is cursory. In practice, a well-scoped Basic submission can require substantial effort. The difference between Basic and Enhanced is principally depth, completeness of traceability, and granularity of risk analysis — not the presence or absence of entire document categories.
Traceability expectations and a mini example matrix
Traceability connects requirements to risks, design, and tests and is essential for efficient review. For Basic submissions, a traceability overview is generally sufficient. Enhanced submissions expect a complete traceability matrix.
Example mapping:
Requirement REQ-007: The system shall alert the operator if measured oxygen saturation falls below the configured low threshold within 5 seconds.
- Linked hazard: H-003 — failure to alert on desaturation leading to delayed clinical response
- Risk control: RC-003 — software alarm generation tied to real-time signal processing with maximum 5-second latency
- Verification: TC-024 (alarm latency test), TC-025 (threshold accuracy test), SYS-TEST-007 (end-to-end alert pathway validation)
In a submission, present the matrix as a dedicated section or appendix and cross-reference it from the SRS and V&V summary. For eSTAR, use consistent document titles and explicit cross-references rather than embedding isolated artifacts without pointers.
---
Risk Management File: what reviewers expect to see
The RMF is one of the most scrutinized components. Reviewers expect evidence of a systematic risk management process consistent with recognized standards. ISO 14971 is the most commonly referenced framework, but use of ISO 14971 is not the sole path to compliance. What matters is a demonstrable process for hazard identification, risk estimation and evaluation, risk control implementation, and residual risk assessment.
Typical RMF evidence includes a risk management plan defining scope and acceptability criteria. It also includes a hazard analysis with severity and probability estimates, and a risk management report summarizing conclusions and justifying residual risk. The depth of these components scales with documentation level. Enhanced submissions should link hazard analysis explicitly to software design and V&V activities.
A frequent shortfall is weak linkage between risk analysis and V&V. Reviewers expect higher-risk functions to receive more rigorous testing and to see that testing rationale derived from the risk analysis. V&V summaries that do not reference risk prioritization often prompt additional information requests.
---
System and software architecture description: depth without exposing secrets
The architecture description gives reviewers the structural context needed to evaluate whether the design supports safety-critical functions. It also helps reviewers understand interactions with hardware, users, and external systems. FDA does not require disclosure of proprietary implementation details or source code.
For Basic documentation, include a system context diagram, a high-level component diagram of major software modules and interfaces, descriptions of external interfaces (data inputs/outputs, protocols, UIs), and a summary of data flow for safety-critical functions. Enhanced submissions should add more detail on internal design of safety-critical components, architecture patterns (e.g., separation of safety vs. non-safety functions), and failure-mode handling.
To protect proprietary details, describe components at the functional level — what a component does, not how it does it. For third-party components provide name and functional role without reproducing vendor proprietary design documents. Reviewers need sufficient visibility to evaluate architectural risk and interface controls, not full source-level disclosure.
---
Verification and validation evidence
V&V shows the software was built correctly (verification) and meets intended use (validation). Basic submissions require a V&V summary describing test types, rationale, summary results, and open issues. Enhanced submissions require detailed V&V plans and results — unit, integration, system, and usability testing where applicable — plus explicit coverage rationale linked to risk.
Common reviewer concerns include V&V summaries that list tests without explaining why the strategy was sufficient for identified failure modes. Effective V&V summaries state how the test strategy derived from risk. They also explain what coverage criteria were used (e.g., functional coverage, boundary conditions), how anomalies were dispositioned, and whether passing criteria were met. The guidance emphasizes prospective documentation: plans and protocols should exist before execution.
For Agile teams, ensure sprint-level or iteration-level test planning artifacts are created prior to testing and linked to formal requirements.
---
Unresolved software anomalies: documenting and justifying acceptability
An unresolved software anomaly is any known defect that exists in the released software and has not been corrected. The guidance expects a list of all unresolved anomalies at submission. Each anomaly must include a justification for why it is acceptable in the released device.
Vague anomaly descriptions are a common source of AI requests. A reviewer needs enough information to independently assess acceptability. The following fields represent a practical minimum for each anomaly log entry:
- Anomaly ID (unique identifier)
- Title / description (clear statement of unexpected behavior)
- Affected software item(s)
- Discovery context (how and when found)
- Severity classification (impact on safety, performance, or effectiveness)
- Patient/user impact analysis (explicit analysis of potential effects)
- Risk acceptability rationale (written argument referencing RMF where applicable)
- Workaround or mitigation (labeling, training, procedural control)
- Planned resolution (target version/timeline or statement that no fix is planned)
Example entry:
Anomaly ID: ANO-0042
Title: Waveform display does not refresh under low-battery condition when display brightness is set to maximum
Affected software item: Display rendering module (DSP-MOD-04)
Discovery context: Found during system-level battery drain test (TC-041)
Severity classification: Low — does not affect measurement or alarm functions
Patient/user impact analysis: The anomaly affects only waveform visualization; alarm, measurement, and data logging operate normally during low-battery conditions. Reviewed against hazard H-009 (loss of visual feedback) and determined risk is mitigated by simultaneous audible alarm.
Risk acceptability rationale: Residual risk acceptable per RMF section 4.3; low probability of patient harm.
Workaround: Labeling update recommending reduced display brightness during extended battery operation.
Planned resolution: Targeted for next scheduled maintenance release.
---
Handling OTS/SOUP components and supplier controls
Off-the-shelf (OTS) software and Software of Unknown Provenance (SOUP) require explicit documentation. Sponsors cannot fully verify internal design properties of third-party software. Identify all OTS/SOUP components, describe their intended use, and provide evidence of the evaluation and control process.
For Basic submissions, document component name, version, vendor, functional role, verification performed in the sponsor's system, and maintenance/update monitoring process. For Enhanced submissions, add supplier evaluation records, vulnerability-tracking processes, and more detailed verification demonstrating performance under safety-critical conditions. Reviewers expect a defined process for monitoring vendor updates and security patches and for assessing their impact through change control. Omission of OTS update planning often triggers questions.
---
Multiple Function Device products: documenting interactions
For MFD products combining device and non-device functions, focus documentation on device software functions while addressing interactions that could affect safety or effectiveness. Provide a partitioned architecture description that clearly delineates device and non-device components. Describe interfaces (shared memory, APIs, event buses, data stores, UI layers).
Identify hazardous situations that could originate from non-device functions and explain design or architectural controls that prevent propagation into device functions. Treat non-device portions as in-scope to the extent they interact with device functions. A companion app’s analytics module that shares a network stack with device telemetry, for example, must be described because its behavior could affect device function safety.
---
Cybersecurity: what to include here vs what to reference
Cybersecurity is addressed in the 2023 software functions guidance, but detailed expectations live in FDA's dedicated premarket cybersecurity guidance. The software functions guidance expects cybersecurity to be integrated into risk management (cyber threats as hazardous situations) and to reference cybersecurity artifacts such as the Software Bill of Materials (SBOM).
In your software documentation, identify cybersecurity-related hazardous situations and include them in the hazard analysis. Document controls and include or reference an SBOM. Cross-reference detailed threat modeling, penetration testing, and security control rationale in the cybersecurity section rather than duplicating extensive security evidence in the software section.
The software section should show a coherent software–cybersecurity interface: RMF acknowledges cyber threats, the architecture description maps threat surfaces, and the V&V section references security testing. For further cybersecurity expectations, see FDA's premarket cybersecurity guidance.
---
Interoperability evidence and labeling
Interoperability means exchanging and using information with other devices, systems, or software. FDA has separate guidance on interoperable devices that aligns with the software functions guidance. For connected device software functions, include descriptions of data interfaces, communication protocols, external systems, and how interface specifications were verified. Labeling should accurately describe connectivity requirements, interoperability claims, and limitations.
If the device relies on another device’s output as a critical input (for instance, a CDS module receiving monitor data), address the accuracy and reliability of the external data in the risk analysis. Broad interoperability claims without documented verification invite reviewer questions about untested failure modes.
---
Where software artifacts go in eSTAR
eSTAR organizes submission content into standardized sections; software documentation is concentrated in a dedicated software section and artifact placement matters for review efficiency. The FDA eSTAR resources page provides authoritative structure and attachment protocols.
Attach the SRS, software architecture/SDS, V&V summary (and plans/results for Enhanced submissions), the unresolved anomaly log, and the RMF (or cross-reference) in the software section. Place cybersecurity documentation in its designated cybersecurity section and cross-reference it from software. Use consistent document naming across the submission and exact titles when cross-referencing. Inconsistent titles are a preventable source of reviewer confusion and AI requests.
A submission workspace that enforces shared document naming and version control can prevent version drift and naming inconsistencies across contributors. For PMA submissions, software documentation follows the PMA organization structure rather than eSTAR. The principles of clear placement, cross-reference, and consistent naming still apply.
For practical, submission-preparation tools, see Assyro's eCTD platform and regulatory workspace tools.
---
Submission types: what stays the same vs what typically deepens
The 2023 guidance applies to 510(k), De Novo, and PMA submissions that include device software functions. Basic documentation is required for all. Enhanced applies when high-risk pre-mitigation situations exist. What varies by pathway is the expected depth of evidence and, for some cases, clinical expectations.
510(k): documentation should support FDA's evaluation of substantial equivalence in the software dimension. If software introduces features not present in the predicate, those features need proportionally more evidence.
De Novo: with no predicate, FDA establishes risk classification from first principles. Software documentation often approaches the depth expected in PMA reviews, especially for novel functions.
PMA: expect clinical validation data in addition to analytical and bench-level V&V for software that directly influences clinical decisions or therapy delivery. The software documentation should connect clinical study design to software specifications.
---
Mapping to IEC 62304 and ISO 14971 without false equivalence
IEC 62304 (software lifecycle) and ISO 14971 (risk management) are recognized standards that substantially support submissions. But conformance to them does not automatically satisfy the 2023 guidance's content expectations. IEC 62304 software safety classes conceptually overlap with Basic/Enhanced escalation but do not map 1:1. A Class B component under 62304 may or may not require Enhanced documentation under FDA’s pre-mitigation threshold.
Likewise, a 14971-compliant RMF is valuable but may need reorganization or summary to be submission-ready for FDA reviewers. Use IEC 62304 and ISO 14971 as your development framework, but audit your artifacts against the FDA guidance's recommended content list. Present submission-facing RMF, traceability, and summaries in a reviewer-friendly structure.
---
From 2005 Level of Concern to 2023 documentation levels: what changed
The 2005 guidance used three Levels of Concern (Minor, Moderate, Major); the 2023 guidance replaces that with a Basic/Enhanced binary and a clearer pre-mitigation risk threshold. Practical implications:
- The Moderate tier is eliminated, requiring explicit assessment of whether Enhanced applies.
- The 2023 guidance explicitly addresses architecture documentation, prospective documentation, unresolved anomaly handling, and cybersecurity in greater detail.
- The guidance aligns more explicitly with recognized standards while retaining flexibility; sponsors bear the responsibility of demonstrating equivalence.
Programs developed under the 2005 framework — especially programs defaulting to Moderate — should perform a gap assessment against the 2023 recommended content list before their next submission.
---
Agile, prospective documentation, and continuous delivery
FDA does not prescribe a lifecycle model; Agile, waterfall, spiral, and hybrid approaches are acceptable. The consistent expectation is prospective documentation: requirements, risk analysis, and test plans must exist before or concurrent with the work they describe.
To reconcile Agile practices with prospective documentation, adopt a layered model. Establish high-level SRS and architecture up front and maintain them under change control. Link sprint-level artifacts (user stories, acceptance criteria, sprint test plans) to formal requirements. Update the SRS, SDS, and traceability matrix sprint-by-sprint. Make requirements updates, risk reviews, and traceability maintenance sprint exit criteria rather than end-of-project activities. Maintaining submission-ready documentation throughout development reduces late-stage rework.
---
Common pitfalls and how to preempt them
Addressing recurring documentation deficiencies proactively reduces AI requests and review delays:
- Incomplete or circular traceability: build three-way traceability (requirement ↔ risk control ↔ test) and audit it before submission.
- Vague anomaly impact assessments: include a written impact analysis and cross-reference relevant hazards.
- V&V summaries without coverage rationale: tie test strategy explicitly to the risk analysis and state coverage criteria.
- Architecture descriptions that omit software: provide software component-level diagrams and interface descriptions, not only hardware block diagrams.
- Treating Basic documentation as minimal: if you omit recommended artifacts, acknowledge and justify omissions rather than leaving gaps.
- Over-reliance on standards conformance: prepare submission-ready summaries and cross-reference structures in addition to development artifacts.
Teams that keep submission documentation current during development are far less likely to face expensive retroactive reconstruction.
About the author
Assyro Team
Expert regulatory operations consultants helping pharmaceutical companies navigate complex compliance challenges.