Over the last two years a large part of the enquiries we received asked for the same thing. The software exists and it runs. Some of it is already on the market, under older rules or with documentation that no longer matches the code. Now somebody needs the IEC 62304 file: a notified body, the FDA, an investor doing due diligence, or a clinical study that cannot start without it.
The people who write to us are rarely regulatory specialists. One was an engineering company that had built a device for a client, and now the software documentation for an FDA submission had to be written, by people who had neither the time nor the routine for it. Another was an engineering partner building an investigational laboratory device for a hospital under an FDA IDE. It had a desktop application, controller firmware and not a single automated test. A third client had a full documentation set that had already gone to the FDA, and wanted to know whether the legacy embedded code still matched it before the next step.
How teams end up here
Small teams build first and document later, and I understand why. When the product changes every month, a full architecture document feels like a waste of a week. IEC 62304 assumes the opposite: the documents are produced along the way, as evidence that a process was followed. Writing them afterwards is possible, as long as the result describes the software as it really is and the gaps are handled openly. The FDA's software guidance notes that documentation created long after the development work can raise concerns about design control, so the file has to show how the gaps were found and closed.
The trouble starts when the documentation is written to look complete. A requirements document that describes features the code does not have, or a risk file that claims a control nobody implemented, will be found. An auditor or an FDA reviewer only has to pick one requirement and ask to see the test.
The documents, and what each one is for
This is the list we work through on every project, based on the current edition of IEC 62304 (2006, with Amendment 1 from 2015). A second edition is in preparation but not yet published. How much of each you need depends on the software safety class. The standard asks for activities and records, not fixed titles, and these are the document names most teams and auditors use for them.
| Document | What it is for | Where it goes wrong | What we do about it |
|---|---|---|---|
| Software Safety Classification rationale | Class A, B or C, which decides how much of everything else is required | Chosen to keep the workload down, without an argument from the hazard analysis | Derive it again from the risk file and write the reasoning down |
| Software Development Plan (SDP) | How you build, verify, integrate and release, with which standards, tools and records | A template that describes a process nobody followed | Describe the process you actually run, then add what is missing |
| Software Requirements Specification (SRS) | What the software must do, including safety, security and interface requirements | Requirements mixed with design, wording that cannot be tested, risk controls missing | One testable statement per requirement, each risk control linked |
| Software Architecture Document (SAD) | Software items, their interfaces, SOUP items and segregation between items (Class B and C) | The diagram from the first prototype | Redraw it from the current code structure and name every SOUP item |
| Software Detailed Design (SDD) | Units and their interfaces, in full for Class C | Missing, or a generated API dump nobody reads | Write it for the units that carry risk, at the depth the class needs |
| Unit Test Report and code review records | Evidence that each unit meets its acceptance criteria (Class B and C) | No unit tests, code reviews done but never recorded | Add tests where they catch real faults, record reviews from now on |
| Software Integration Test Plan and Report | Evidence that the software items work together as the architecture says (Class B and C) | Integration happens, but nobody planned or recorded it | Write the plan from the architecture, run it, keep the report |
| Software System Test Specification and Test Report | Test cases for every requirement, and the results of running them | Tests exist, but nothing links them to requirements and results are not kept | Write test cases from the requirements, run them, keep the report |
| Traceability Matrix | Links each requirement to its design, tests and risk controls | Assembled by hand at the end, with holes | Build it from requirement and test IDs so it stays current |
| SOUP List and SOUP Assessment | Every third party component with its exact version, and for Class B and C its requirements and known anomalies | Incomplete, wrong versions, no review of known issues | Extract the list from the build environment and review each vendor's issue list |
| Software Hazard Analysis (part of the ISO 14971 risk management file) | How the software can contribute to a hazard, and which risk control handles it | Lives in the system risk file with no software detail | Add the software causes and trace each control to a requirement and a test |
| Software Configuration Management Plan | How versions, branches, builds and configuration items are identified and controlled | Nobody can rebuild the released binary | Pin the toolchain, document the build, list every configuration item |
| Software Maintenance Plan | How changes and feedback after release are handled | Missing, or copied from the development plan | Describe how a field problem becomes a change, and who decides |
| Problem Reports and Problem Resolution procedure | How defects are recorded, analysed for risk and closed | Bugs live in a tracker with no link to risk or verification | Add risk assessment and verification to every problem report |
| Software Release Notes and release record | What exactly was released, how it was built, and the known residual anomalies | No list of known anomalies, release built on a developer machine | Release from the pipeline, list residual anomalies with their risk evaluation |
For the US the list shifts a little. The FDA's 2023 guidance on premarket submissions for device software functions replaced the old three levels of concern with two documentation levels, Basic and Enhanced, decided separately from the IEC 62304 class. Since section 524B of the FD&C Act and the FDA's premarket cybersecurity guidance (last updated in February 2026), a cyber device also needs an SBOM, a threat model, a cybersecurity risk assessment and a plan for handling vulnerabilities after release. The FDA reads "able to connect to the internet" broadly: Wi-Fi, cellular, Bluetooth and even a USB port count, so a device with software and any of these connections can fall under it.
We start with a fit-gap analysis
We have had enough of these requests that the work now follows the same path every time. It starts with a fit-gap analysis with an agreed scope. We read the code, the existing documents and the risk file, and compare them clause by clause with IEC 62304 for the software's safety class, and with the FDA guidance if the target market is the US. The report lists what exists, what is missing, and where the documents contradict the code. We go through every finding with the client's team, and then deliver a recommendation for each gap (fix the document, fix the code, or accept it with a written justification) and a development plan with effort, price and timeline. How long it takes depends on the size of the software and the documentation.
The report is useful even if the client never hires us for the rest. Some take it to their notified body to agree a plan. Some close the gaps with their own team. Some ask us to do it.
The third client above is a good example. The device is a therapeutic device with safety relevant embedded software, and its documentation had already been submitted to the FDA. We compared several hundred pages of that documentation with a 20,000 line legacy codebase. The gap list showed places where the code and the documents disagreed, requirements with no test behind them, and code defects the risk file did not account for. The report was ready three weeks after we got access, and it became the scope of the remediation project we are running now. How we did the comparison in one day instead of two weeks is the subject of my next post.
A regulatory consultancy can write the same report, and we do that work too: when a client needs it, we write the complete IEC 62304 documentation set, with an FDA specialist on the team. What a consultancy cannot do is change the code. Some gaps sit in the documents and some sit in the code, and a consultancy has to hand the code findings to a development team that reads them, asks the same questions again and plans the work from scratch. We cover both. On that project the engineers who did the review are now fixing the code and updating the documents from their own findings. The client talks to one team, the documents stay consistent with the code, and nobody has to coordinate a reviewer and a separate developer.
When there is nothing to start from
If no documentation exists, we write it from the code. Requirements are reconstructed from the behaviour of the software and confirmed with the people who know the intended use. The architecture is drawn from the real module structure. Test cases are written against the requirements, executed, and the results kept.
For the laboratory device this produced a user requirements specification, a software requirements specification with functional, safety and interface requirements, a validation plan, a verification plan, a test report, a traceability matrix and a suite of automated tests. Before any of the tests could run, the desktop application had to be refactored so that the hardware could be mocked. A documentation project can turn into an engineering project quickly, and the team writing the documents has to be able to change the code.
The one thing we will not do is describe better software than the one that exists. If the firmware has no handling for a sensor failure, the design document says so and the risk file gets an entry, or the code gets fixed. The manufacturer decides which, and the decision is documented.
Why we take this work
Silurus has built regulated medical software since it was founded in 2017. The people who lead it have worked inside IEC 62304 processes for more than twenty years, on medical imaging and radiotherapy software for large manufacturers. An FDA specialist works with us on every documentation project, which matters when the target is a 510(k) and the team only knows the MDR. We work inside the client's ISO 13485 quality system, with their templates and their procedures.
We write the documentation, and we are also engineers who can read your firmware, build it, run it on a bench, and fix the code when the documentation shows that it needs fixing.
If your software is in this state, a fit-gap analysis is the cheapest way to find out how far you are from a file you can submit. You can write to me directly at tamas.fodor@silurus-software.com.
Sources
- IEC, IEC 62304:2006+AMD1:2015 CSV, Medical device software, Software life cycle processes
- Johner Institute, IEC 62304 2nd edition: areas of application and changes
- FDA, Content of Premarket Submissions for Device Software Functions, June 2023
- FDA, Webinar transcript, Final Guidance: Content of Premarket Submissions for Device Software Functions, 2023
- FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, February 2026