Source code flowing into a stack of verified documents

Services · Retrospective IEC 62304 documentation

The missing documents for software that already works.

Software written before the current procedures, by a supplier who has left or under time pressure needs its IEC 62304 file before an audit or a submission. The engineers and regulatory specialists of Silurus Software start from a gap analysis (a review of what is missing against the standard), write the missing documents from the code and the existing material, and correct the documents that no longer match the software, for the EU MDR technical documentation and the FDA submission.

Book a 30 minute call Write to us

Start: IEC 62304 gap analysis
Software: Firmware · desktop · mobile · cloud
Process: IEC 62304 · ISO 13485 · ISO 14971
Route: EU MDR · FDA

What we cover

Every part of the software file

Requirements

We recover the requirements from the code, the behaviour and the user manual, complete them with your colleagues in short sessions, and check them against the intended use, the system requirements and the risk analysis.

Architecture and design

We read the software items, interfaces and units from the source tree and the build, to the depth the safety class (A, B or C, by the harm a software failure could cause) requires.

SOUP list and SBOM

Third party components are identified from the build and the dependency manifests, vendor binaries by review, with version, known anomalies and risk assessment, and the SBOM (software bill of materials, the list of every software component in the build) is generated.

Software risk analysis

We write the software contribution to the ISO 14971 risk file, with every risk control traced and verified.

Tests and traceability

Test protocols are written and run on the device or in simulation, and the traceability matrix (a table linking each requirement to its design, tests and risk controls) is completed.

Verification and validation →

Cybersecurity file

We write the threat model (a structured analysis of how the device could be attacked), the security requirements and their tests under IEC 81001-5-1.

Medical device cybersecurity →

Usability file

We write the use specification and the evaluation records IEC 62366-1 asks for, following Annex C of IEC 62366-1 for a user interface of unknown provenance where it applies, with your clinical staff and, for the summative evaluation, with representative users.

Submission documents

Our regulatory specialists and FDA consultants prepare the software sections for the EU MDR and the FDA.

Regulatory consulting →

In practice

Situations we are asked to solve

Situation

Notified body findings on a product sold for years

A Class IIb device has been on the market for years under the old directive. The notified body (the independent organisation that certifies a device under the EU MDR) found gaps in the software documentation, the software is a C++ desktop application, and the gaps have to close without rewriting the product.

How we approach it

We answer the findings one by one. The gap analysis maps each finding to the IEC 62304 activity behind it, and the missing requirements, architecture, Software Design Specification, SOUP list (software of unknown provenance, meaning third party code used in the device), verification and traceability are written from the existing code.

For software already on the market that was not developed to IEC 62304, clause 4.4 of Amendment 1 (legacy software) can apply. Post market feedback and risk are assessed, the gap analysis sets which activities are repeated, and the rationale for continued use goes into the record. The product is not rewritten. Code changes are made only where the analysis finds a defect or a missing risk control, under your change control.

Situation

An app, a cloud backend and a dashboard without a software file

A product made of an iOS app, a cloud backend on AWS and a web dashboard runs in a pilot, and before it is placed on the market as a medical device it needs its software documentation under the EU MDR before development continues.

How we approach it

The three parts are treated as software items of one system, each with its safety class. Libraries go into the SOUP list and the SBOM, managed cloud services are listed with their configuration and risk assessment, and the threat model covers the app, the API and the cloud boundary.

The work is staged: first the records for the product as it runs today, then development continues under the same lifecycle, so new features arrive with their documents.

Situation

Firmware that works, with documents missing for an FDA submission

Embedded firmware is finished, and the FDA submission needs architecture, detailed design, traceability, SOUP records, test specifications, the threat model and the SBOM.

How we approach it

Our embedded engineers read the code, and our FDA consultants shape the records for the premarket submission and its documentation level. The engagement can be documentation only, without development or test execution.

How it runs

From the gap analysis to a released file

Step 1

Gap analysis

Documents, code and process compared with IEC 62304 and the route, with prioritised findings.

Step 2

Plan

The documents to write or correct, in the order of the findings, with the scope agreed in writing.

Step 3

Writing

Requirements and design read from the code and completed with your colleagues in short sessions, tests written, and run by our team or yours.

Step 4

Release

Traceability complete for the agreed baseline, documents reviewed and approved in your QMS, ready for the technical documentation and the submission.

What you receive

The software file, written in your templates

D-01

Plan and classification

The development and maintenance plan for the work ahead and the safety classification of each software item, with the rationale.

D-02

Requirements and design

Software requirements, architecture and detailed design that match the code.

D-03

SOUP list and SBOM

Third party software with version, known anomalies and risk assessment, and the SBOM from the build.

Sample SOUP inventory →

D-04

Tests and traceability

Test protocols and reports, and the matrix from requirement to design, test and risk control.

Sample traceability matrix →

D-05

Cybersecurity records

For a connected device, the threat model and the SBOM, written from the architecture and the build.

Sample STRIDE threat table →

EU and US

One software file, prepared for both markets

European Union

EU MDR technical documentation

The software part of the technical documentation for CE marking, written with our regulatory specialists.

United States

FDA premarket submission

The software documentation for a 510(k) (the FDA premarket notification for a device similar to one already on the market) or De Novo, prepared with our FDA consultants.

Technologies and standards

What we work with

Technologies and tools

CC++C#QtPythonSyftGrypeDependency-TrackSonarQubeclang-tidyDHF remediationSoftware Requirements Specification (SRS)Software Design Specification (SDS)Test caseTest protocolTest reportDesign and development file

Standards, regulations and practices

MDCG 2019-16VEXFDA section 524BFDA QMSR (21 CFR 820)IEC 62304ISO 13485ISO 14971IEC 62366-1IEC 81001-5-1SOUP listSBOMCycloneDXSPDXTraceability matrixThreat modellingEU MDR technical documentationFDA guidance on premarket submissions for device software functionseSTARIEC 62304 Amendment 1 legacy softwareFDA 510(k)

Silurus Software

Silurus Software, founded in 2017, offices in Budapest, Hungary, and Singapore
More than 40 engineers, EU MDR regulatory specialists and FDA consultants
Work inside the client's ISO 13485 quality management system, with the split of tasks written down before the work starts. Where the client has no documented software process yet, we bring IEC 62304 templates for the client to adopt into its own system
Multi-year engineering partner of a European MedTech manufacturer
Founder and CTO Péter Török, in medical technology software since 1999, formerly software development director at Siemens Healthcare (syngo.via) and head of R&D at Mediso Medical Imaging Systems
ISO 9001:2015 (NQA, certificate 171041, valid until March 2027) and ISO/IEC 27001:2022 (NQA, certificate 728872, valid until August 2029)
Awarded AAA, Highest Creditworthiness, by Dun & Bradstreet in 2025
Research partner of ELTE Eötvös Loránd University, Budapest
Industrial partner of the University of Bologna, the University of Pisa, the University of Amsterdam and Masaryk University, Brno, in the EU Horizon Europe project LOGOS from 2027
Female Business Leader of the Year 2025 and The Pioneer Award 2026, awarded to CEO Dr. Linda Szántó

How we work →Quality and standards →Sample deliverables →Case studies →

Related work and pages.

Client names are withheld unless the client has agreed to be named.

Case study

IEC 62304 gap analysis of safety-critical surgical device firmware

Two people reviewed a safety-critical surgical device's firmware, documents and process against IEC 62304, FDA and MDR in three weeks. The remediation was then contracted to Silurus Software.

Case study

Lab device refactoring and IEC 62304 documentation

Desktop application and firmware of a Dutch university medical centre's lab device refactored to be testable, with IEC 62304 documentation, in three months.

IEC 62304 gap analysis Regulatory consulting, EU MDR and FDA Legacy modernisation and takeover Verification and validation AI coding tools in regulated development

FAQ

Frequently asked questions

Can you write the documentation from the existing code?

Yes. We read the code, the build and the existing material, and complete requirements and risk rationale with your colleagues in short sessions.

How long does it take?

The gap analysis takes three weeks for an agreed scope and sizes the rest. The writing is planned and quoted after it.

Does the same method work for apps and cloud software?

Yes. Firmware, desktop applications, mobile apps and cloud backends are documented the same way. Libraries go into the SOUP list and the SBOM, managed cloud services are listed with their configuration and risk assessment.

Do we have to change our QMS or templates?

No. We write in your templates and under your document control.

Do you also run the tests?

Yes, on the device or in a simulation mode, and we write the test reports.

What if the analysis finds defects in the code?

They are reported with a priority, and our engineers can fix them under your change control.

Can you work as a documentation only engagement?

Yes. We write the records from the existing code and material, your team keeps developing, and test execution can stay with you.

Do you rewrite the product to document it?

No. The documentation describes the product as it is. Changes to the code are made only where the analysis finds a defect or a missing risk control, under your change control.

Which FDA documents do you prepare for the software and cybersecurity part?

The software description, the software risk records, requirements, architecture and design, the SOUP and SBOM records, verification records, the version history and the unresolved anomalies list, and for a cyber device the threat model, the cybersecurity risk assessment and the plan for postmarket vulnerabilities, assembled for the eSTAR submission at the documentation level the device requires.

Talk to us

Tell us which documents are missing.

The software, the documents you have and the market. We reply with the first step.

Book a 30 minute technical call