How do you prepare software for an FDA submission?

Which of your two software files does the submission read?

The submission reads the file about the software you sell. A device company runs two software files that are easy to confuse and impossible to substitute for one another, and the week a submission date lands is the week that confusion turns expensive.

FDA's computer software assurance guidance, issued 3 February 2026 under docket FDA-2022-D-0795 and carried as CDRH document GUI00017045, covers computers and automated data processing systems used as part of production or the quality management system for medical devices. Its scope section then draws the other boundary: the guidance gives no recommendations for the design and development verification or validation requirements for device software functions. Every page of it is headed "Contains Nonbinding Recommendations", and the text states that it does not establish any rights for any person and is not binding on FDA or the public. What it does cover, and how it scales the assurance effort to process risk, is set out at FDA computer software assurance.

A team that spent a year building a validation programme around that guidance holds a real file answering a real requirement, and none of it transfers to the product. Where the boundary between the two has never been written down, writing it down is the first task of the week, one software item at a time, with the reasoning attached to each. If the question underneath is still open, whether the software is a device at all, that argument comes first and everything on this page waits for it. Is your app a medical device works through how the determination is made and who has to make it.

Which edition of each standard do your records answer to?

Your records answer to whichever edition was open on somebody's desk when they were written, and nobody chose it. This decision closes more quietly than any other, because a standard has no effective date of its own to remind anyone.

IEC standards carry no compliance deadline and no entry into force. The foreword of IEC 62304 recommends only that national committees adopt the content for mandatory implementation not earlier than three years from the date of publication. A voluntary consensus standard starts to bind when a regulator recognises a specific text or a contract names one, which turns the operative question from whether you follow IEC 62304 into which printing of it your reader holds.

FDA answers that in public and in detail. Its recognition record names IEC 62304 Edition 1.1 2015-06, the consolidated version, under FR recognition number 13-79 on recognition list 051, with a date of entry of 14 January 2019 and the extent of recognition given as the complete standard. The identical adoption named beside it is ANSI/AAMI/IEC 62304:2006/A1:2016. The record shows no transition begin or end date, and a search of the database on that designation returns exactly one record, so the 2006 first edition is not separately recognised. ISO 14971 is handled the same way, as the third edition of 2019-12 under number 5-125 on list 053.

The distance between the two IEC texts is not cosmetic, and three parts of it turn up directly in a submission file.

Three changes IEC 62304 Amendment 1 made in 2015, and what each means for an FDA submission file written against the 2006 edition.

What Amendment 1 did in 2015	What that means for a file written against the older text
Added clause 4.4 on legacy software, absent from the 2006 contents	A route the earlier edition does not contain, so a file built on it never considered the route
Added clause 5.1.12 on defects introduced by the selected programming technology	A requirement at software safety class B and C with no counterpart in the earlier edition
Deleted definition 3.26, software product, and replaced the entry with "Not used"	A term the standard withdrew, still sitting in procedures that quote it

Clause 5.1.12 repays a close read, because it is the requirement most obviously fixed by an engineering decision taken years before anyone thought about a submission. It asks for a documented procedure that identifies categories of defects which may be introduced by the selected programming technology, and for documented evidence that those defects do not contribute to unacceptable risk, with a note pointing at Annex B of IEC TR 80002-1:2009 for examples. The programming technology was chosen at the start of the project. The procedure that answers for that choice was either running while the code was being written or it was not, and no budget applied in the submission month produces one that was.

The withdrawn vocabulary is the cheapest item on this page to fix and the most embarrassing to leave. Amendment 1 replaced the entry for definition 3.26 with the words "Not used" and swept the term out of 3.2, 3.4, 3.13, 3.24, 5.1.1, 5.8.4 and 5.8.7 in favour of medical device software. It also struck the words "and verification" from the title of clause 5.5, which now reads "software unit implementation". The old title survives in the amendment redline and in Figure 1, which is why it is still quoted everywhere. A reviewer who opens your procedure and finds a clause title the standard stopped using in 2015 has learned something about the file before reading a single test result. Which clause binds at which software safety class is set out at IEC 62304 software testing requirements.

One further edition question sits underneath the others. Clause 2 of IEC 62304 carries exactly one normative reference, to ISO 14971, and it is undated, so the current edition applies. The six definitions Amendment 1 added, numbered 3.35 to 3.40, are sourced to ISO 14971:2007, and the amendment re-pointed the existing risk vocabulary at that 2007 edition clause by clause. A file quoting IEC 62304 on residual risk, risk estimation or risk evaluation is therefore quoting 2007 wording while working under an undated reference that resolves to the 2019 edition. Saying which edition each defined term came from costs one sentence and closes the question before a reviewer opens it.

What is still open this week?

Three things are still open, and they are the cheapest work anywhere on this page.

The first is the electronic signature certification. section 11.100(c) requires persons using electronic signatures to certify to the agency, prior to or at the time of such use, that the electronic signatures in their system are intended to be the legally binding equivalent of traditional handwritten signatures. That certification is signed with a traditional handwritten signature, and the 2023 amendment to the part replaced the printed mailing address in 11.100(c)(1) with a pointer to FDA's web page on Letters of Non-Repudiation Agreement. The timing in that sentence passed the first time somebody in your company approved a record electronically, and the letter can still go out this week. Which of the part's ten sections reach a given system is worked through at 21 CFR Part 11 validation testing.

The second is how far the part reaches. section 11.1(b) applies Part 11 to records in electronic form created, modified, maintained, archived, retrieved or transmitted under any records requirements set out in agency regulations, and separately to electronic records submitted to FDA under the Federal Food, Drug, and Cosmetic Act and the Public Health Service Act, even where those records are not specifically identified in agency regulations. Teams read Part 11 as a rule about the internal quality system. The second half of that sentence is about the package being assembled now.

The third is an ordering problem in the risk file, and it decides whether a document has to be rewritten or merely finished. The third edition of ISO 14971 made the pre-distribution review a review of the execution of the risk management plan, with its results documented as the risk management report, and ISO/TR 24971:2020 subclause 4.4.4 states that the results of the review of the planned risk management activities are consolidated in that report under clause 9. Compare two dates today: the approval date of the risk management plan, and the date of the earliest risk analysis record in the file. Where the plan is the later of the two, clause 9 has no execution to review, because the activities it was meant to plan had already happened. What the plan has to contain, and what the file has to trace, is set out at ISO 14971 risk management and software testing.

What happens if the file goes in as it stands?

The reader finds the gap, and the gap then closes on the schedule of the work it stands for.

Conformity with IEC 62304 is settled by reading. Clause 1.4 defines compliance as implementing the processes, activities and tasks the standard identifies in accordance with the assigned software safety class, and it decides the question by inspecting the documents required of you and by assessing those processes, activities and tasks against that class. There are two consequences when you cost the work. The class assignment gets read before the evidence does, because the class decides which deliverables the file is expected to contain at all. And a package short of a deliverable is short of the thing conformity is determined from, with no demonstration available that stands in for it.

Costs then split by what kind of thing is missing. A requirement that was never tested costs a test cycle. A risk control verified for implementation and never for effect can cost a usability study or a data collection, which is somebody else's calendar and not yours. A deliverable that a different edition asked for costs the work that edition described, from the beginning. Sort the gaps into those three before costing any of them.

The record-by-record read that produces that sort is the same exercise a company runs before an audit, and its sequence is set out at healthcare software audit preparation. Run it after the three questions above have answers, because those answers decide which records the read is looking for.

What do you do first, and in what order?

Step 7 comes last on purpose. An evidence read performed before steps 1 and 2 is a read against an unstated standard, and it produces a gap list somebody has to produce again once the standard is stated.

What sets the schedule?

The item with the longest lead time sets it, and that is rarely the testing. Four counts decide it, and each comes off documents you already hold: how many software items carry a safety class of B or C, how many risk controls in the file have an implementation record and no effectiveness record, how many deliverables belong to an edition your records did not answer to, and whether requirement text is versioned so that a trace can point at a fixed revision.

The first three are countable this week. The fourth is a property of your tooling and is usually the cheapest of the four to change. Where the counts do not exist yet, the validation scope estimate walks the same decision points and runs entirely in your browser.

One rule holds across the whole plan. Work that produces evidence about the current build can be compressed by adding people. Work that has to produce a deliverable somebody should have written two years ago cannot, because the writing is the smaller half of it and the deciding is the larger. Start the second kind on day one.

Where was the submission file settled before it was written?

• The validation programme was built around the computer software assurance guidance and is offered as the device software file, under a document whose scope section excludes device software functions.
• The file names IEC 62304 with no edition, so a reader cannot tell whether the evidence answers the recognised consolidated text or the superseded 2006 one.
• The procedure quotes clause 5.5 under its old title and uses "software product" as a defined term, both of them withdrawn by Amendment 1 in 2015.
• Clause 5.1.12 is absent from the file because it was absent from the edition the team read, and the programming technology it asks about was selected years ago.
• The risk management plan carries an approval date later than the first risk analysis record it was supposed to plan.
• The submission's own records are held and signed electronically, and nobody sent the 11.100(c) certification.
• IEC 62304's risk vocabulary is quoted in the file with no note that Amendment 1 sourced those definitions to ISO 14971:2007, while the standard's only normative reference to ISO 14971 is undated.
• The software safety class was assigned once and the architecture that assignment described has been replaced since, so the clause set the file answers to was chosen for a different product.

What do we do on a submission file?

We read the frame before the evidence, because the frame decides what counts as evidence. That means the boundary between the device software file and the quality management system file, the edition each part of your document set answers to, and the dates on the planning documents. The output is a short list of what has to be restated, what has to be produced and what is already sound, with the reasoning written where a reviewer can read it.

Then we run the testing that list calls for. Each run is recorded while it is happening, and each record names the edition of the requirement it answers, so the finished file states its own frame instead of leaving a reader to infer one.

A submission file often needs a test configuration that no longer exists, so somebody has to decide what goes into the rebuilt one and what data it holds. The rebuilt environment does not need production PHI in it, and what it does hold is agreed in writing before it is built. We sign a Business Associate Agreement before any engagement that touches PHI. The answers we give before any of that is settled are published at how we work with protected health information.

Recognition numbers, clause numbers, definition numbers and dates on this page were checked against the primary texts of IEC 62304, ISO 14971, 21 CFR Part 11 and the FDA computer software assurance guidance, on 2 September 2026. Where a statement comes from a guidance document or a technical report instead of from the standard itself, the sentence says which document it came from.