What software documentation does FDA expect?

In short: FDA expects software documentation scaled to risk (basic or enhanced level), covering architecture, requirements, V&V, and lifecycle processes — plus, since Section 524B, cybersecurity documentation including an SBOM for connected devices. AI/ML functions add data, performance, and change-management expectations on top.

The baseline: documentation level scales with risk

FDA's software documentation guidance sorts submissions into "basic documentation level" or "enhanced documentation level," depending on the severity of harm that could result if the software fails or malfunctions. Enhanced level applies where failure could result in death or serious injury, and requires substantially more detail: full requirements traceability, detailed architecture design charts, complete verification and validation testing results, and a comprehensive hazard analysis. Basic level, for lower-risk software, still requires the same categories of documentation but at less exhaustive depth. These expectations map closely to IEC 62304, the international software-lifecycle standard used for CE marking — so if you're sequencing EU and US, much of the work serves both. Getting the level determination right early shapes how much documentation work you're actually signing up for.

Cybersecurity is no longer optional

Since Section 524B of the FD&C Act, cybersecurity documentation is a mandatory component for cyber devices — meaning any device with software that can connect to the internet or another device. FDA's final guidance, "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" (27 June 2025; reissued in February 2026 under the retitled "Quality Management System Considerations" heading to align with the QMSR), sets out what this looks like in practice: a Software Bill of Materials (SBOM) listing components and known vulnerabilities, a plan for identifying and addressing post-market cybersecurity vulnerabilities, and evidence of a secure product development framework. Submissions lacking this documentation are increasingly likely to receive a refuse-to-accept determination before substantive review even begins, rather than a milder Additional Information request further into the process.

What AI/ML functionality adds

Beyond the standard software documentation, AI/ML-enabled devices bring additional expectations: documentation of training, validation, and test data characteristics and provenance, performance metrics and how they were established, and — increasingly — a change-management approach for how the model will be updated after clearance, which is where a Predetermined Change Control Plan becomes relevant. Treating these as a late addition to an otherwise-finished submission tends to generate exactly the kind of Additional Information request that adds months to review.

Where next: Does My Health AI Need FDA Clearance? · What is an FDA PCCP for AI Devices?

Talk to us about your software documentation package. Book an expert conversation →