Jetzt umstellen lohnt sich
Die FDA-CSA-Guidance ist final (2025, aktualisiert 2026) und die QMSR verweist seit Februar 2026 auf die ISO 13485. Der einheitliche risikobasierte Validierungsansatz ist gesetzt.
Risikobasierter Ansatz GAMP 5 · ISO 13485 Part 11 · QMSR · EU & FDA
Risikobasierte Software-Validierung für Medizinprodukte
Wir validieren computergestützte Systeme sowie Prozess-, QM- und Werkzeug-Software risikobasiert: Aufwand entsteht dort, wo er für den Validierungsnachweis wirklich notwendig ist – nach ISO 13485, GAMP 5 und FDA Computer Software Assurance (CSA). Schlank, auditfest und im validierten Zustand gehalten.
25+
Jahre Regulatory-Erfahrung
50+
Compliance-Expert:innen
EU + FDA
aus einer Hand
CSA + GAMP 5
risikobasiert validiert
Worum es geht
Validierung mit Augenmaß – schlank statt Dokumentenberg
Metecon richtet die Validierung computergestützter Systeme risikobasiert aus: Statt Dokumentenberge zu erzeugen, bestimmen wir je System und Werkzeug den notwendigen Validierungsumfang nach Risiko und Nutzung, nach Computer Software Assurance (CSA), GAMP 5 (2nd Ed.) und ISO 13485. So bleiben Prozess-, QM- und Werkzeug-Software im validierten Zustand, auditfest gegenüber Benannten Stellen und FDA, und Aufwand entsteht nur dort, wo er für die Validierungsnachweise wirklich notwendig ist.
Für wen: QM-Leitung / QMB, Validierungs- und CSV-Verantwortliche sowie Head of Regulatory Affairs – ergänzend Qualitäts-IT, Produktions-/Prozessverantwortliche und Geschäftsführungen kleinerer Hersteller.
„Software-Validierung scheitert selten am Wollen, sondern am Maß: Wir validieren risikobasiert – Aufwand entsteht dort, wo er für die Validierungsnachweise wirklich notwendig ist. So bleiben Prozess-, QM- und Werkzeug-Software-Validierung schlank, auditfest und lebbar."
– Thorsten Stumpf · Principal Expert Software & AI · RAC Devices · Metecon GmbH
CSA & GAMP 5 • ISO 13485 · Part 11 • EU & FDA
Typische Herausforderungen
Drei Probleme, die klassische CSV erzeugt
Dokumentenberge ohne Mehrwert
CSV mit falschen Schwerpunkten bindet Ressourcen und verzögert Releases ohne erkennbaren Qualitätsgewinn.
Unklarer Validierungsumfang
Welche Systeme und Werkzeuge müssen wie tief validiert werden? Auditabweichung von ISO 13485 Abschnitt 4.1.6, 7.5.6 und 7.6 sind die Folge.
Cloud/SaaS nicht im Griff
Häufige Updates und SaaS-Releases lassen sich kaum im validierten Zustand halten.
Einordnung im Überblick
Was zu validieren ist – und wie tief
Geltungsbereich, risikobasierter Ansatz und Normenrahmen – sauber eingeordnet.
Geltungsbereich
Risikobasierter Ansatz
Normen & QMSR
Geltungsbereich: Was muss validiert werden?
Zu validieren ist Software, die Produktqualität- und sicherheit oder die Wirksamkeit des QMS beeinflusst, nicht die Medizinprodukt-Software selbst.
Prozess- & Produktionssoftware
Software in QM-relevanten Prozessen und in der Produktion (ISO 13485 Abschnitt 7.5.6).
QM-Software
Software, die im Qualitätsmanagementsystem genutzt wird (ISO 13485 Abschnitt 4.1.6).
Überwachungs- & Messmittel-Software
Software, die für Überwachung oder Messung eingesetzt wird (ISO 13485 Abschnitt 7.6).
Wichtig zur Abgrenzung
- Gemeint ist Nicht-Produkt-Software – nicht die Medizinprodukt-Software (IEC 62304/82304-1)
- Auslöser sind Auswirkungen auf Produktqualität, Datenintegrität oder QMS-Wirksamkeit
Software-Validierung: Ein risikobasierter Ansatz
Software-Validierung setzt Critical Thinking und die Einbeziehung des Softwarerisikos voraus, um eine schlanke Dokumentation zu erstellen:
Testen, was zählt – statt Tests für jedes, auch nicht relevante Feature der betreffenden Software.
Critical Thinking
Validierungsumfang aus Zweckbestimmung und Risiko ableiten, nicht aus dem kompletten Funktionsumfang der Software.
Risikobasiertes Testing
Hoher Testaufwand für hohes Risiko, niedriger Testaufwand für geringeres Risiko.
Supplier Leverage
Lieferanten-Dokumentation nutzen. Anbieter mit bedarfsgerechten Nachweisen reduzieren den Testaufwand.
Relevante Grundlagen
- FDA Computer Software Assurance (final 2025, aktualisiert 2026)
- 21 CFR Part 11
- GAMP 5 (2nd Ed.): risikobasierte Kategorien, Critical Thinking, Supplier Leverage
Normen & QMSR
ISO 13485 fordert die Validierung mehrfach; ISO/TR 80002-2 und GAMP 5 geben konkrete Vorgehensmodelle vor. Mit der QMSR rücken EU und FDA regulatorisch näher zusammen.
ISO 13485 & ISO/TR 80002-2
Die Abschnitte 4.1.6, 7.5.6 und 7.6 fordern die Validierung; ISO/TR 80002-2 und AAMI TIR36 liefern Best Practice.
QMSR & Part 11
Seit Februar 2026 verweist 21 CFR Part 820 (QMSR) auf die ISO 13485:2016 – konsistent mit Part 11.
Relevante Grundlagen
- ISO 13485:2016 Abschnitt 4.1.6 / 7.5.6 / 7.6 · ISO/TR 80002-2 · AAMI TIR36
- GAMP 5 (2nd Ed.) · FDA CSA · 21 CFR Part 11 · QMSR (Part 820 → ISO 13485) · Datenintegrität (ALCOA+)
Risikobasiert heißt nicht nachlässig
ISO/TR 80002-2 ist Best Practice (nicht harmonisiert); auditiert wird gegen ISO 13485 Abschnitt 4.1.6, 7.5.6, 7.6.
Software-Validierung über den Produkt-Lebenszyklus
Von der Inventarisierung bis zum validierten Zustand
1
System-Inventar
Software in Prozessen, im QM oder als Werkzeug (z. B. in der Produktentwicklung oder bei Produkt-V&V) muss erfasst werden.
2
Intended Use & Risiko
Das Risiko für jede identifizierte Software für den Anwendungsfall muss ermittelt werden – daraus folgt der Validierungsumfang für die entsprechende Software.
3
Herstellernachweis
Sichtung und Nutzen von vom Hersteller zur Verfügung gestellten Nachweisdokumentation.
4
Validierungsplan und Testen & Nachweis
Umfang, Testmethodik (scripted vs. unscripted), risikobasiert testen und Ergebnisse nachvollziehbar dokumentieren.
5
Bericht & Freigabe
Validierungsbericht und Freigabe auditfest dokumentieren (ISO 13485, QMSR). Auch Freigaben mit Einschränkungen sind möglich.
6
Änderungen & validierter Zustand
Updates und Patches bewerten und das System im validierten Zustand halten. Ggf. Durchführung von im Validierungsplan festgelegten Kontrollen.
Aufwand dort, wo er zählt
Wir konzentrieren Tiefe und Dokumentation risikobasiert auf die wesentlichen Systemmerkmale und nutzen Lieferantennachweise – so wird Validierung schlank, schnell und trotzdem auditfest.
Warum Metecon
Validierungskompetenz, die Wettbewerber-Benchmarks erfüllt
Risikobasierter Umfang
Validierungsumfang je System nach ISO/TR 80002-2, AAMI TIR36 und GAMP-5-Kategorien. Schlank, aber belastbar.
Pläne & Berichte auditfest
Validierungspläne und -berichte, die BS- und FDA-Audits sauber bestehen (ISO 13485, 21 CFR Part 11).
Supplier Leverage
Lieferanten-Dokumentation gezielt nutzen – weniger Doppelarbeit, weniger Aufwand.
Werkzeug- & Prozessvalidierung
Test-Werkzeuge, Messmittel und Prozesse validieren (ISO 13485, 7.5.6, 7.6) – mit klarer Begründung.
EU & FDA aus einer Hand
ISO 13485, 4.1.6, 7.5.6, 7.6 und QMSR+Part 11 zusammen denken – ein Ansatz für beide Märkte.
Risikobasiert nach CSA ISO/TR 80002-2 AAMI TIR36 & GAMP 5
Wir übersetzen komplexe Regulatorik in umsetzbare Strategien. Die Benchmarks orientieren sich an den Stärken führender Anbieter: schlanke, risikobasierte Validierung, auditfeste Nachweise und Software-/Prozessvalidierung.
Metecon erfüllt diese Kriterien und verbindet sie mit der Produktdokumentation und dem Qualitätsmanagement.
Überschneidungen mit der Software-Dokumentation & QMS
Software-Validierung überschneidet sich mit Qualitätsmanagement und Software-Lifecycle. Wir behandeln die angrenzenden Themen auf eigenen Seiten und verlinken sie als zusammenhängende Nachweisstruktur.
Was wir konkret anbieten
Leistungen zur Software-Validierung im Überblick
GAP-Analyse bestehender Validierung
Vorhandene Validierungen und entsprechende SOPs auf Lücken und auf Eignung prüfen. Mit pragmatischer Roadmap zur Umsetzung.
Validierungsprozess & SOP aufsetzen
Schlanken, risikobasierten Software-Validierungsprozess etablieren oder bestehenden optimieren.
System-Inventar & risikobasierter Validierungsansatz
Systeme erfassen, Zweckbestimmung und Risiko bestimmen, Validierungsumfang festlegen.
Anforderungen & Spezifikation
Je System die Anforderungen (User/Functional Requirements) sauber spezifizieren – Basis für gezieltes, risikobasiertes Testen.
Unterstützung bei der Durchführung der Software-Validierung
Test-Werkzeuge und Messmittel-Software validieren – auditfest begründet.
Unterstützung bei Software-Änderungsbewertung bei bestehender Validierung
Risikobewertung der Änderung, Freigabe der Änderung, Unterstützung bei der Ermittlung und Durchführung der notwenigen Validierung.
Workshops & Schulungen
Inhouse-Schulungen zu CSV, CSA, GAMP 5, ISO/TR 80002-2, AAMI TIR36 und Part 11 für QM, RA und IT.
Software-Validierung für Unterstützung von IVD-Produkten
Dieselbe risikobasierte Validierungsstrategie gilt auch für IVD-Hersteller unter der IVDR.
Klar getrennt von der Produkt-Validierung
Software-Validierung betrifft Software, die nicht Bestandteil des Medizinprodukts ist. Die Validierung der Medizinprodukt-Software selbst behandeln wir auf der V&V-Seite.
Abgrenzung
Software-Validierung vs. Validierung der Medizinprodukt-Software
Software-Validierung
Validierung von Nicht-Produkt-Software: Prozess-, QM-, Werkzeug- und Messmittel-Software.
Grundlage:
ISO 13485 Abschnitt 4.1.6/7.5.6/7.6, ISO/TR 80002-2, GAMP 5, FDA CSA, Part 11.
Validierung der Produkt-Software
Verifizierung & Validierung der Medizinprodukt-Software selbst (IEC 82304-1) und der technischen Produktkonformität.
Beide greifen ineinander
Werkzeuge aus der Produktentwicklung (z. B. Test-Tools) fallen unter die Software-Validierung; die Tests des Medizinprodukts selbst gehören zur V&V. Wir halten beide Nachweiswelten konsistent.
Schnittstellen
Womit Software-Validierung verzahnt ist
Qualitätsmanagement
Software-Validierung ist eine QM-Disziplin nach ISO 13485 und ist im QMS verankert. Qualitätsmanagement →
Verifizierung & Validierung
Abgrenzung und Schnittstelle zur Validierung der Produkt-Software.
Risikomanagement
Risikobasierter Validierungsumfang, verzahnt mit dem Produkt-Risikomanagement (ISO 14971).
Thorsten Stumpf
Principal Expert Software & AI · RAC Devices · Metecon GmbHThorsten Stumpf und das Metecon-Team setzen Software-Validierung risikobasiert auf. Von System-Inventar und Risikoeinschätzung über Validierungspläne und Testing bis zur Freigabe der Software und Aufrechterhaltung des validierten Zustands, für EU- und internationale Märkte.
Häufige Fragen zur Software-Validierung
Welche Software muss ich überhaupt validieren – und welche nicht?
Zu validieren ist Software in QM-relevanten Prozessen, in der Produktion oder als Werkzeug/Messmittel/Testwerkzeug, die die Produktqualität, Datenintegrität oder die Wirksamkeit des QMS beeinflusst (ISO 13485, 4.1.6 / 7.5.6 / 7.6). Medizinprodukt-Software selbst wird mit dem Medizinprodukt oder als eigenständiges Medizinprodukt validiert – mehr Details in der V&V-Sektion und der MDSW-Sektion .
Wie bestimme ich den risikobasierten Validierungsumfang (CSA statt CSV)?
Über Zweckbestimmung und Risiko des Systems im Verwendungskontext (meist Prozesskontext): Hohes Risiko erfordert meist eine umfangreichere Validierung, niedriges Risiko entsprechend weniger. Bestimmte regulatorische Dokumente (u. a. CSA und GAMP 5) liefern den Rahmen – Aufwand wird dort konzentriert, wo die Software das Medizinprodukt selbst oder die regulatorischen Begleitaktivitäten negativ beeinflussen können.
Was ändert die FDA-CSA-Guidance gegenüber der klassischen CSV?
Die FDA Computer Software Assurance (final 2025, aktualisiert 2026) zeigt einen risikobasierten Ansatz mit Critical Thinking, der nach FDA-Ansicht den wenigsten Aufwand bereitet. So wird die Validierung bedarfsgerecht für die FDA ausgestaltet. CSV ist ebenfalls ein risikobasierter Ansatz, der im Kontext der Anforderungen der ISO 13485 verwendet wird.
Wie halte ich bereits validierte Systeme nach Updates im validierten Zustand?
Über einen definierten Prozess für Freigabe der Software nach Änderung: Updates der Software werden vor der Freigabe risikobasiert bewertet, nur von der Änderung betroffene Funktionen werden erneut getestet und Nachweise entsprechend nachgezogen. So bleibt das System im validierten Zustand, ohne jedes Release vollständig neu validieren zu müssen.
Wie nutze ich Lieferanten-Dokumentation, um Aufwand zu sparen?
Indem die Entwicklungs- und Testnachweise des Software-Anbieters in die eigene Validierung einbezogen werden (Supplier Leverage). Bei qualifizierten Lieferanten reduziert das den eigenen Testaufwand erheblich – CSA und GAMP 5 (2nd Ed.) sehen das ausdrücklich vor.
Was bedeutet die QMSR (Part 820 → ISO 13485) für meine Software-Validierung?
Seit Februar 2026 verweist 21 CFR Part 820 (QMSR) auf die ISO 13485:2016. Für die Software-Validierung rücken EU- und FDA-Anforderungen damit näher zusammen – ein konsistenter, risikobasierter Ansatz deckt beide Welten ab.
Worin unterscheidet sich Software-Validierung von der V&V der Medizinprodukt-Software?
Software-Validierung (CSV/CSA) betrifft Software, die nicht das Produkt ist, aber Einfluss auf die regulatorischen Kontext hat – Software in relevanten Prozessen, in wesentlichen QM-Aufgaben oder als Werkzeuge, die in der Produktentwicklung, V&V oder der Produktion eingesetzt wird. Die Verifizierung und Validierung der Medizinprodukt-Software selbst (IEC 62304, IEC 82304-1) ist eine eigene Disziplin und wird separat behandelt.
Was kostet Software-Validierung bei Metecon?
Der Aufwand hängt vom Risiko der Systeme im Anwendungsgebiet ab sowie von bestehenden Nachweisen für die sichere und leistungsstarke Verwendung (EU/FDA) ab. In einer kostenlosen Erstberatung ordnen wir Ihren Fall ein, priorisieren risikobasiert und nennen anschließend einen belastbaren Rahmen.
Software-Validierung schlank aufsetzen
Starten Sie mit einer kostenlosen Erstberatung. Wir priorisieren anschließend risikobasiert, nutzen Lieferantennachweise und skizzieren Ihren auditfesten Validierungsansatz. Aus Komplexität wird Klarheit.
Ihr Ansprechpartner:
Milan Weiß
Sales Manager
T: +49 621 123469-040
milan.weiss@metecon.de
