Know where your software stands before an audit or a submission to the notified body or the FDA.

Notified bodies expect evidence of a software lifecycle process under MDR Annex I, and IEC 62304 is the standard most manufacturers use for it. In three weeks a senior engineer and a regulatory specialist of Silurus Software review your documents, code and process against IEC 62304, ISO 13485, ISO 14971 and your EU MDR or FDA route. You receive a report with prioritised findings and a remediation plan, and it states what was reviewed in depth, what was checked on a sample basis and what was not.

Book a 30 minute call Write to us

Duration: 3 weeks to the report
Start: Within 2 weeks of the order
Team: Senior engineer, regulatory specialist
Route: EU MDR · FDA

What we cover

Where the gap analysis helps

Before an audit or a submission

The report shows which records are complete, which are missing and what comes first, with a priority for each finding.

Software from another supplier

The report describes the code, the documents and the process as they are, so the next team knows what it takes over.

Legacy modernisation and takeover →

Products already on the market

For legacy software, meaning software legally placed on the market without sufficient records of development under IEC 62304, we first check that clause 4.4 applies. The report then gives the risk based gap analysis (a review of what is missing against the standard) of clause 4.4.3 and the input for the gap closure of 4.4.4 and the rationale for continued use under 4.4.5.

A new market

The review covers the EU MDR and the FDA route together, with our FDA consultants on the US side.

Regulatory consulting →

Acquisition or licensing

Code and documentation are assessed before the decision, with the effort needed to close the gaps.

Firmware

A senior embedded engineer compares the code with its documented design and checks the safety relevant logic.

Embedded and firmware development →

Desktop, mobile and cloud software

The review covers each software item, the SOUP list (software of unknown provenance, meaning third party code used in the device), the SBOM (software bill of materials, the list of every software component in the build) and the cloud boundary.

After the report

We work through the plan first of all: our engineers on the code and our regulatory specialists on the documents, and your own team joins where it wants to.

Retrospective IEC 62304 documentation →

In practice

Situations we are asked to solve

Situation

A first FDA 510(k) for software developed under the EU MDR

The device software was developed for CE marking, and a first 510(k) (the FDA premarket notification for a device similar to one already on the market) is planned in a few months. It is unclear what the FDA expects beyond the existing file.

How we approach it

The gap analysis compares the file with the FDA premarket software guidance and its documentation levels, and for a cyber device under section 524B with the threat model (a structured analysis of how the device could be attacked), the SBOM and the plan for postmarket vulnerabilities. The report lists what the FDA submission needs on top of the MDR file, with a priority for each item.

Situation

A supplier hands over a codebase in a few weeks

The software supplier ends the contract, and the next team has to know what it takes over before the handover window closes.

How we approach it

The review runs while the supplier is still available. Documents, code and build are assessed, and the report gives the next team a clear picture of the state of the software and the first steps.

Situation

A notified body audit is scheduled

The audit date is fixed, and nobody can say yet how complete the software records are.

How we approach it

Within three weeks the report shows the findings in order of priority, so the available time goes to the gaps that matter most.

How it runs

Three weeks from kickoff to the report

Before the start

NDA and offer

A mutual NDA, then a first look at the code and the documents and a written offer for one software system.

Weeks 1 to 3

Review

The documents checked for completeness, the code compared with its documented design, and the process assessed from planning to release.

End of week 3

Report and walkthrough

Findings with a priority from P1 to P4 and a recommendation each, presented to your engineering and regulatory leads. P1 is a gap that blocks an audit or a submission or affects the safety classification or the risk controls, P4 is an improvement without a compliance impact. Each finding names the clause and the evidence it rests on.

After the report

Remediation

We work through the plan first of all: our engineers on the code and our regulatory specialists on the documents, and your own team joins where it wants to.

What the review covers

Documents, code and process

01Documents

Software development plan
Requirements and system requirements
Architecture and detailed design
SOUP list
Software risk analysis
Test protocols and reports

02Code

Code against its documented design
Coding rules and unit verification
SOUP versions and known anomalies
Traceability from requirement to test

03Process

Software safety classification
Configuration management and change control
Problem resolution
Release and maintenance records

IEC 62304ISO 13485ISO 14971EU MDRFDA

What you receive

Four results of the review

D-01

Gap report

Every finding categorised, prioritised from P1 to P4 and given a remediation recommendation.

D-02

Remediation plan

The work to close the gaps, grouped for your own team, a work package or a dedicated team.

D-03

Legacy software record

For legacy software legally placed on the market, the risk based gap analysis of clause 4.4.3 and the input for the gap closure of 4.4.4 and the rationale for continued use under 4.4.5.

D-04

Walkthrough

The report presented to your engineering and regulatory leads, with time for their questions.

EU and US

One review, two sets of requirements

European Union

EU MDR and CE marking

The report shows what the technical documentation needs from the software. Our regulatory specialists can write the missing parts.

United States

FDA 510(k) and De Novo

The report shows what the submission needs from the software. Our FDA consultants can prepare it, with a Pre-Submission where the FDA's view is worth having, as work after the gap analysis.

Technologies and standards

What we work with

Technologies and tools

CC++C#QtPythonSonarQubeclang-tidyCoveritySyftDependency-TrackSoftware development planSRSSyRSSoftware Design Specification (SDS)Test protocol

Standards, regulations and practices

MDCG 2019-16VEXFDA section 524BFDA QMSR (21 CFR 820)IEC 62304IEC 62304 Amendment 1 legacy softwareISO 13485ISO 14971IEC 81001-5-1SOUP listSBOMTraceability matrixEU MDRFDA 510(k)FDA De NovoFDA guidance on premarket submissions for device software functions

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.

Regulatory consulting, EU MDR and FDA Retrospective IEC 62304 documentation Legacy modernisation and takeover Project delivery How we work

FAQ

Frequently asked questions

What does an IEC 62304 gap analysis cost?

The price is quoted after a first look at the code and the documents and agreed in writing before the work starts. The offer names the software system, its version and the documents in scope.

How long does it take, and when can it start?

Three weeks from kickoff to the report. The work starts within two weeks of the signed order. The review is risk based: the safety relevant software items get the deepest review, the rest is checked on a sample basis, and static analysis runs over the whole code base where the tools can run. If the system is too large for three weeks, the offer says so and agrees the scope with you.

What do you need from us?

The software documentation as it exists, read access to the source code, your process documents and one contact who can answer questions. A mutual NDA is signed first.

Can you also fix what the report finds?

Yes. The remediation is a separate order, as a work package or a dedicated team, with our engineers on the code and our regulatory specialists on the documents.

Does it cover software that is already on the market?

Yes. For legacy software, meaning software legally placed on the market without sufficient records of development under IEC 62304, we first check that clause 4.4 applies. The report then gives the risk based gap analysis of clause 4.4.3 and the input for the gap closure of 4.4.4 and the rationale for continued use under 4.4.5.

Does it work for desktop, mobile and cloud software, or only firmware?

It covers one software system of any kind: firmware, a desktop application, a mobile app or a cloud backend. The senior engineer is chosen for that technology.

Does the report cover the FDA as well as the EU MDR?

Yes. Findings are mapped to the EU MDR technical documentation and to the FDA premarket software guidance. The FDA documentation level, Basic or Enhanced, follows the risk of the software function and is not the same as the IEC 62304 safety class (A, B or C, by the harm a software failure could cause), and the report treats them separately. For a cyber device under section 524B it covers the threat model, the SBOM and the plan for postmarket vulnerabilities.

Who does the review?

A senior engineer who knows the technology of the device and a regulatory specialist, so the code and the documents are read by people who write them.

Does the review reflect the FDA QMSR?

Yes. The FDA Quality Management System Regulation (QMSR, 21 CFR 820), in force since 2 February 2026, incorporates ISO 13485 by reference, and the report shows where the software process meets it. For a cyber device, section 524B requires the SBOM and the plan for postmarket vulnerabilities, and the FDA cybersecurity guidance expects the threat model. The review covers them as well.

Talk to us

Tell us about the software.

The device, the software system and the market. We send the written offer for the gap analysis with its start date.

Book a 30 minute technical call