Engineer reviewing a build pipeline and test results

Verification that keeps pace with ongoing development.

When development moves faster than the testing around it, releases wait or the evidence gets thinner. The test engineers and regulatory specialists of Silurus Software write and run the test protocols, keep the traceability and the software contributions to your ISO 14971 risk file current in every sprint, and prepare the evidence for the EU MDR technical documentation and the FDA submission, inside your ISO 13485 quality management system.

Book a 30 minute call Write to us

Standards: IEC 62304 · ISO 13485 · ISO 14971
Tests: Unit · integration · system · UI
Team: Inside your QMS
Route: EU MDR · FDA

What we cover

Software verification, validation and risk management

Verification planning

We write the verification plan with test levels, environments, tools and the regression strategy.

Unit and integration testing

Unit verification, code review and integration tests, with statement and branch coverage measured continuously, targets set by software safety class (A, B or C, by the harm a software failure could cause) and risk, and justified exclusions recorded.

System testing

System test protocols traced to the requirements they verify, run in documented environments. Requirements verified by review, analysis or inspection are traced in the same matrix.

Test automation and regression

Unit, integration and simulation suites run on every build, hardware in the loop and long regression suites nightly, so the fast suites report a failing change within minutes and the nightly suites by the next morning.

Dedicated engineering teams →

Traceability

Links between needs, requirements, risk controls and tests are kept in your tools and updated in every sprint. Third party and legacy components (SOUP, software of unknown provenance) are listed with their requirements and verified for their use in your software.

Risk management file

The software part of your ISO 14971 risk management file is kept in step with the design, and every change is assessed before release. The overall residual risk evaluation stays with the client, as the manufacturer of the device, and we prepare the evidence for it.

Validation and usability

Software validation planned together with verification, with acceptance criteria from the intended use and user needs, executed in a representative or simulated use environment, and support for the usability evaluation under IEC 62366-1. Design validation of the finished device stays with the client, as the manufacturer of the device, and we support it with the validation records.

Security testing

Security tests derived from the threat model (a structured analysis of how the device could be attacked) and traced in the same matrix as the functional tests. SBOM (software bill of materials, the list of every software component in the build), vulnerability management and update planning for section 524B devices are on the cybersecurity page.

Medical device cybersecurity →

In practice

Situations we are asked to solve

Situation

Independent verification of software written by someone else

The software was developed by the manufacturer or another supplier, and the verification should be done by a team that did not write it.

How we approach it

Silurus Software engineers who were not involved in the development write the test cases from the requirements and risk controls, execute them and report the results, so the verification is independent of the code authors.

Situation

Software that is nearly finished, with V&V that will not pass

The software is largely complete, the requirements exist, and the verification and validation documentation will not pass the submission planned in a few months.

How we approach it

We derive the test cases from the existing requirements and risk controls, write the protocols, execute them and record every result with build and environment. Anomalies are logged, assessed for risk and dispositioned, and the V&V report closes the record.

Where requirements are missing or untestable, they are corrected first, so the record holds together at the audit.

Situation

An embedded device that was never prepared for automated testing

A device under FDA review needs new features, and its embedded software has no automated tests.

How we approach it

We add a test framework with unit tests and hardware in the loop rigs, put automated regression in CI, fast suites on every build and hardware in the loop rigs nightly, and verify the new features under change control. The impact analysis gives your regulatory lead and our FDA consultants the basis to decide how the change is handled, for example whether to raise it with the FDA while the submission is under review. The decision and any contact with the FDA stay with the client.

Situation

Long running software with regular maintenance releases

A product on the market gets fixes, security patches and platform updates every year.

How we approach it

Every maintenance release gets its impact analysis, regression run and updated traceability, and problem reports are investigated, and those that meet your CAPA (corrective and preventive action) criteria go to your CAPA process with their root cause.

How it runs

Verification in every sprint

Plan

Verification plan

Test levels and depth set from the IEC 62304 software safety class, the architecture and the risk controls, with environments, tools and the regression strategy.

Each sprint

Protocols and runs

Test cases written with the features, executed and recorded with build and environment.

Each change

Impact and regression

The requirements, risk controls and tests a change touches, and a regression run.

Each release

Release evidence

Test report, open anomalies with their risk assessment and the traceability matrix (a table linking each requirement to its design, tests and risk controls).

What you receive

Records under your document control

D-01

Verification plan

Test levels, entry and exit criteria, environments, tools with their validation for the intended use, and the regression strategy.

D-02

Test protocols and reports

Protocols traced to requirements and risk controls, executed records and a report per release.

Sample test case →

D-03

Traceability matrix

User needs, requirements, risk controls, tests and results in one matrix.

Sample traceability matrix →

D-04

Risk management file

Hazards, software contributions, risk controls and their verification, kept current.

EU and US

One set of executed tests, documented for each market

European Union

EU MDR technical documentation

The software verification and validation evidence for the EU MDR technical documentation (Annex II), one part of the CE marking file, prepared with our regulatory specialists.

United States

FDA 510(k) and De Novo

The software testing evidence for the submission, prepared with our FDA consultants at the documentation level, Basic or Enhanced, that the FDA software guidance sets for your device.

Technologies and standards

What we work with

Technologies and tools

GoogleTestCppUTestUnitypytestNUnitxUnitSquishPlaywrightSeleniumHardware in the loopSonarQubeCoverityclang-tidyCodeQLJenkinsGitHub ActionsGitLab CIAzure DevOps

Standards, regulations and practices

FDA section 524BSecurity testingThreat modellingFDA guidance on premarket submissions for device software functionsIEC 62304ISO 13485ISO 14971IEC 62366-1IEC 81001-5-1Traceability matrixStatic analysisRisk management fileEU MDRFDA 510(k)FDA De NovoFDA QMSR (21 CFR 820)

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

QA and DevOps for a regulated software portfolio

Ten specialists running nightly regression and signed builds inside a European manufacturer's release process, over several years.

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.

Dedicated engineering teams Retrospective IEC 62304 documentation Medical device cybersecurity Regulatory consulting, EU MDR and FDA

FAQ

Frequently asked questions

Can you take over verification while our developers keep working?

Yes. Our engineers join your teams, work in your tools under your procedures and write the protocols and records as the features arrive. A team can start within two to three weeks of signature.

Our documentation is behind the code. Can you write it after the fact?

Yes. We write the requirements from the intended use and the existing specifications, use the code only to see what the software does today and record every difference as an anomaly. The requirements are marked as retrospective, your team reviews and approves them as design inputs, and we build the traceability matrix and the risk file and run and record the tests. From the next sprint on the file stays current.

Do you also run security tests?

Yes. Security tests are derived from the threat model and traced in the same matrix as the functional tests. SBOM, vulnerability management and update planning for section 524B devices are covered by the medical device cybersecurity service.

Can one test record serve the EU MDR and the FDA?

Yes, the executed tests and their results can serve both. The documentation depth differs: for the FDA, the Basic level asks for summaries of unit and integration testing and the Enhanced level for the full protocols and reports, and the EU MDR file also needs the validation of the finished device, which stays with the manufacturer. Our regulatory specialists and FDA consultants prepare each.

Do you work in our requirements and test management tools?

Yes, or in ours if you do not have them yet.

Can you derive and execute V&V from requirements we already have?

Yes. We write the test cases and protocols from your requirements and risk controls, execute them, handle the anomalies and write the V&V report.

How do you handle anomalies found in testing?

Each anomaly is recorded, assessed for its effect on safety and effectiveness, dispositioned and, if fixed, verified again. Open anomalies go into the release record with their risk assessment.

Do you test embedded software with hardware in the loop?

Yes. Hardware in the loop rigs with simulated sensors and actuators, next to simulation tests in CI.

Talk to us

Tell us where verification stands.

The device, its software safety class and the state of the test record. We reply with the first step.

Book a 30 minute technical call