Erfahren Sie, wo Ihre Software steht, bevor ein Audit ansteht oder Sie bei der Benannten Stelle oder der FDA einreichen.

Nach einer ersten Sichtung von Code und Dokumentation kalkulieren wir den Preis und vereinbaren ihn vor Arbeitsbeginn schriftlich. Im Angebot benennen wir das Softwaresystem, seine Version und die Dokumente, die wir prüfen.

Drei Wochen vom Kickoff bis zum Bericht. Die Arbeit beginnt innerhalb von zwei Wochen nach dem unterzeichneten Auftrag. Die Prüfung ist risikobasiert: Die sicherheitsrelevanten Software-Elemente werden am tiefsten geprüft, der Rest stichprobenartig, und die statische Analyse läuft über die gesamte Codebasis, wo die Werkzeuge laufen können. Ist das System für drei Wochen zu groß, sagt das Angebot es und stimmt den Umfang mit Ihnen ab.

Die Softwaredokumentation, wie sie existiert, Lesezugriff auf den Quellcode, Ihre Prozessdokumente und eine Ansprechperson, die Fragen beantworten kann. Zuerst wird eine gegenseitige NDA unterzeichnet.

Ja. Dafür erteilen Sie uns einen gesonderten Auftrag, entweder für ein Arbeitspaket oder für ein dediziertes Team. Unsere Entwickler bearbeiten den Code, unsere Regulatory-Spezialisten die Dokumentation.

Ja. Legacy-Software wurde rechtmäßig in Verkehr gebracht, verfügt aber nicht über ausreichende Aufzeichnungen zur Entwicklung nach IEC 62304. Wir prüfen zunächst, ob Abschnitt 4.4 auf diese Software anwendbar ist. Falls ja, erstellen wir die risikobasierte Gap-Analyse nach Abschnitt 4.4.3. Der Bericht schafft die Grundlage, um die Lücken nach Abschnitt 4.4.4 zu schließen. Er enthält außerdem die Begründung für die weitere Verwendung nach Abschnitt 4.4.5.

Wir prüfen ein Softwaresystem beliebiger Art, etwa Firmware, eine Desktopanwendung, eine mobile App oder ein Cloud-Backend. Dafür setzen wir jeweils einen Senior-Entwickler ein, der mit der betreffenden Technologie vertraut ist.

Ja. Wir ordnen die Befunde der technischen Dokumentation nach EU-MDR und der FDA-Leitlinie zu Premarket-Software zu. Das FDA Documentation Level, Basic oder Enhanced, richtet sich nach dem Risiko der Softwarefunktion und entspricht nicht der IEC-62304-Sicherheitsklasse (A, B oder C, nach dem Schaden, den ein Softwarefehler verursachen könnte). Der Bericht behandelt beide getrennt. Für ein Cyber Device nach Abschnitt 524B enthält er das Threat Model, die SBOM und den Plan für Schwachstellen nach dem Inverkehrbringen.

Ein Senior-Entwickler mit Erfahrung in der betreffenden Technologie und ein Regulatory-Spezialist führen die Prüfung gemeinsam durch. Beide kennen Code und Dokumentation aus eigener Entwicklungspraxis.

Ja. Die Quality Management System Regulation der FDA (QMSR, 21 CFR 820), seit dem 2. Februar 2026 in Kraft, bezieht ISO 13485 per Verweis ein, und der Bericht zeigt, wo der Softwareprozess sie erfüllt. Für ein Cyber Device verlangt Abschnitt 524B die SBOM und den Plan für Schwachstellen nach dem Inverkehrbringen, und die FDA-Leitlinie zur Cybersicherheit erwartet das Threat Model. Die Prüfung deckt auch diese ab.