p4mx health
← Alle Impulse
Prozess Applikationen28. September 2026· 3 Min. Lesezeit

GxP-taugliche Software ohne Overhead: risikobasierte Validierung

In regulierten Umgebungen muss Software validiert werden — und viele Teams erleben das als Papierberg, der jede kleine Änderung ausbremst. Das muss nicht sein. Der risikobasierte Ansatz ist seit Jahren Stand der Leitlinien: Aufwand dort, wo das Risiko sitzt, und Zurückhaltung, wo keines ist. Dieser Beitrag zeigt, was Validierung wirklich verlangt und wie GAMP 5 und der EU-GMP Annex 11 den schlanken Weg stützen.

In Pharma, MedTech und Versorgung muss Software, die GxP-relevante Abläufe stützt, validiert werden. Viele Teams erleben das als Selbstzweck: Testskripte, Unterschriften, Nachweise für jede Funktion, und bei jeder kleinen Änderung beginnt der Papierberg von vorn. Der Ausweg ist keine Ausnahme von der Regel, sondern die Regel selbst — der risikobasierte Ansatz, den die einschlägigen Leitlinien seit Jahren beschreiben.

Was Validierung eigentlich verlangt

GxP steht für die guten Praxen der regulierten Welt — etwa die gute Herstellungspraxis (GMP). Computer-System-Validierung (CSV) ist der dokumentierte Nachweis, dass ein System für seinen bestimmungsgemäßen Gebrauch geeignet ist und zuverlässig das tut, was es soll. Der Maßstab ist die Eignung für den Zweck, nicht Vollständigkeit um ihrer selbst willen. Wer jede denkbare Funktion gleich tief prüft, verwechselt Umfang mit Sicherheit — und bindet Zeit, die an den kritischen Stellen fehlt. Die Frage ist nie „Wie viel können wir dokumentieren?", sondern „Was muss belegt sein, damit wir uns auf das System verlassen können?".

Der risikobasierte Ansatz ist der Standard, nicht die Ausnahme

Der GAMP-5-Leitfaden des ISPE (Second Edition, 2022) baut vollständig auf diesem Gedanken auf. Er richtet den Prüfaufwand am Risiko aus, orientiert sich am Qualitäts-Risikomanagement nach ICH Q9 und rückt kritisches Denken, Patientensicherheit und Produktqualität in den Mittelpunkt — nicht das reine Abwehren von Audit-Feststellungen. Die GAMP-Softwarekategorien bilden das ab: Nicht konfigurierte Standardsoftware braucht weniger Eigennachweis als konfigurierte Systeme, und diese weniger als kundenspezifische Entwicklung.

Der EU-GMP Annex 11 „Computerised Systems", in Kraft seit 2011, verankert Risikomanagement ausdrücklich über den gesamten Lebenszyklus eines Systems. Der 2025 zur Konsultation veröffentlichte Entwurf einer Revision (Konsultation bis Oktober 2025, Endfassung noch ausstehend) schreibt das Risikomanagement und das Qualitätssystem noch deutlicher fest und richtet sich an GAMP 5 aus. Beide Fassungen tragen dieselbe Grundaussage: Der Aufwand darf und soll dem Risiko folgen.

Beispiel: zwei Systeme, zwei Tiefen

Ein Tabellenkalkulations-Makro, das eine Kennzahl für einen internen Bericht rechnet, und ein System, das Chargenfreigaben steuert, sind nicht gleich zu behandeln. Beim ersten genügt ein schlanker Nachweis, dass es korrekt rechnet und gegen versehentliche Änderung geschützt ist. Beim zweiten, wo ein Fehler die Produktqualität oder die Patientensicherheit berührt, ist tiefe Prüfung angemessen. Denselben Prüfumfang über beide zu legen, erzeugt Overhead beim einen und trügerische Sicherheit beim anderen. Die Trennlinie ergibt sich nicht aus der Technik, sondern aus der Frage, was ein Fehler im schlimmsten Fall auslöst.

Vorgehen: den Aufwand dem Risiko folgen lassen

  1. Bestimmungsgemäßen Gebrauch und GxP-Bezug festlegen: Was tut das System, welche Entscheidung oder welcher Datenpunkt hängt daran?
  2. Risiko bewerten — nach ICH Q9: Was passiert bei einer Fehlfunktion, wie wahrscheinlich ist sie, wie gut ließe sie sich erkennen?
  3. Softwarekategorie nach GAMP 5 bestimmen: Standard, konfiguriert oder kundenspezifisch — je größer der Eigenanteil, desto mehr Nachweis.
  4. Testtiefe und Nachweise daran ausrichten und die Leistung des Lieferanten nutzen, statt sie zu wiederholen.
  5. Nur dokumentieren, was den Nachweis trägt — nachvollziehbar, nicht möglichst umfangreich.

Auch die US-Behörde FDA geht diesen Weg. Ihre Leitlinie „Computer Software Assurance" (Endfassung 2025) stellt die risikobasierte Absicherung über die reine Dokumentation und lässt weniger aufwendige Testformen zu, wo das Risiko gering ist. International bewegt sich die Regulierung in dieselbe Richtung.

Einordnung

Risikobasiert heißt nicht „weniger Validierung", sondern „Aufwand dort, wo er trägt". Bei hohem Risiko — direkter Einfluss auf Produktqualität, Patientensicherheit oder Datenintegrität — bleibt die Prüftiefe hoch; hier zu sparen wäre fahrlässig. Der Ansatz ersetzt auch das Qualitätssystem nicht: Ohne saubere Anforderungen, Änderungssteuerung und Lieferantenbewertung fehlt ihm die Grundlage. Und er entbindet nicht von der Datenintegrität — ein schlanker Nachweis ist kein lückenhafter. Wo eine Aufsichtsbehörde im Einzelfall mehr erwartet, gilt deren Maßstab.

Fazit

GxP-Konformität und schlanke Abläufe schließen sich nicht aus. Wer das Risiko ehrlich bewertet und den Aufwand daran ausrichtet, erfüllt die Erwartungen der Leitlinien und behält eine handhabbare Dokumentation. Der Papierberg entsteht nicht durch die Regeln, sondern durch den Verzicht darauf, sie risikobasiert anzuwenden.

Quellen: ISPE: GAMP 5 — A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition, 2022. Europäische Kommission: EudraLex Volume 4, EU-GMP-Leitfaden Annex 11 „Computerised Systems" (in Kraft seit 2011); Entwurf der Revision, Juli 2025 (öffentliche Konsultation bis Oktober 2025, Endfassung ausstehend). ICH: Q9(R1) Quality Risk Management, 2023. U.S. Food and Drug Administration: Computer Software Assurance for Production and Quality System Software, Guidance for Industry, Endfassung 2025.

Passt das zu Ihrer Situation?

Wir beginnen mit einer Prozessanalyse und zeigen belegbar, was möglich ist.

Gespräch vereinbaren