GAMP 5 Second Edition - QFINITY
QFINITY · ISPE GAMP

Validierung nach GAMP 5.

GAMP 5 ist der maßgebliche ISPE-Leitfaden für die risikobasierte Validierung computergestützter Systeme im GxP-Umfeld. Seine Second Edition (2nd Edition) erschien im Juli 2022. Die Validierung nach GAMP 5 folgt dem Lebenszyklusmodell: Der Nachweis beginnt in der Konzeptphase und endet erst mit der Stilllegung, nicht mit dem Validierungsbericht. Weltweit ziehen Life-Science-Unternehmen den Leitfaden als Referenz heran, ebenso Behörden wie die FDA. QFINITY war Teil des Kernteams der Revision zur Second Edition und bringt diese Expertise direkt in jedes Mandat ein.

Der Leitfaden

Die Referenz für computergestützte Systeme.

Der GAMP 5 Guide bietet einen praxisnahen Rahmen, in dem konforme, für ihren Verwendungszweck geeignete computergestützte Systeme effizient entstehen. Sein risikobasierter Ansatz auf Basis skalierbarer Spezifikation und Verifizierung hat sich für Systeme jeder Größe bewährt.

GAMP 5 Second Edition betont kritisches Denken durch sachkundige, erfahrene Experten als Grundlage geeigneter Validierungsansätze. Was die FDA 2025 als Computer Software Assurance formalisierte, war hier bereits methodisch angelegt.
Second Edition 2022

Was ist neu in der GAMP 5 Second Edition?

Die GAMP 5 Second Edition (2nd Edition, Juli 2022) behält Rahmen, Schlüsselkonzepte und das an ICH Q9 ausgerichtete Qualitätsrisikomanagement bei. Aktualisiert ist die Anwendung in der Praxis. Verschoben hat sich die Gewichtung. Patientensicherheit und Produktqualität stehen vor Compliance, und kritisches Denken wird ausdrücklich hervorgehoben. Dass der Lebenszyklus nicht linear sein muss, unterstreicht die Second Edition stärker als die Erstausgabe; iterativer und agiler Entwicklung widmet sie einen eigenen Anhang. Neue Anhänge behandeln kritisches Denken, IT-Infrastruktur im eigenen Haus und bei externen Anbietern, Software-Werkzeuge im Lebenszyklus, Blockchain sowie KI und Machine Learning. Überarbeitet sind Planung und Berichte für SaaS-Lösungen, die Bewertung von Cloud-Anbietern, Anforderungen und Tests mit Werkzeugunterstützung sowie die Übergabe in den Betrieb. Der Guide lässt zu, dass Aufzeichnungen aus automatisierten Werkzeugen die formale Spezifikations- und Testdokumentation ersetzen, und wendet dabei die Konzepte der Computer Software Assurance aus dem Case-for-Quality-Programm der FDA an.

  • Kritisches Denken

    Stärkere Betonung kritischen Denkens in der Validierung computergestützter Systeme. Im Validierungskontext verankert haben den Begriff die GAMP-Leitfäden der ISPE. Die FDA-CSA-Guidance, die GPSV und ICH Q9(R1) nennen ihn nicht, setzen die Denkweise jedoch voraus und unterstellen sie als Grundlage für die Anwendung.

  • Künstliche Intelligenz & Machine Learning

    Behandlung von Systemen mit künstlicher Intelligenz und maschinellem Lernen.

  • Agile Software-Entwicklung

    Anerkennung agiler Methoden und iterativer Entwicklung im regulierten Umfeld.

  • IT Service Management & Cloud

    Erweitertes IT Service Management einschließlich Cloud-Lösungen bis hin zu SaaS.

  • Open-Source-Software

    Neue Leitlinien für den Einsatz von Open-Source-Komponenten im regulierten Umfeld.

  • Blockchain

    Neue Leitlinien für Blockchain-Systeme.

Der Weg

Wie läuft eine GAMP-5-Validierung?

Eine GAMP-5-Validierung folgt dem Lebenszyklusmodell des Leitfadens mit vier Phasen: Konzept, Projekt bis zum Go-live, Betrieb und Stilllegung. In der Konzeptphase laufen die vorbereitenden Maßnahmen, damit sich im Projekt der Kontext nicht mehr verschiebt und keine Aufgaben aus früheren Phasen parallel nachgeholt werden müssen. Im Projekt folgen Planung, Spezifikation, Konfiguration oder Entwicklung, Verifizierung und Freigabe, wobei Umfang und Tiefe nach Risiko, Komplexität und Neuheit skalieren. Im Betrieb halten Change-, Incident- und Problem-Management, Konfigurationsmanagement und periodische Bewertung den validierten Zustand aufrecht. Die GAMP 5 Second Edition fordert dabei kritisches Denken ein. Belegt werden muss am Ende, dass das System für seinen Intended Use geeignet ist und valide betrieben werden kann.

PhaseWas geschieht
KonzeptBedarf und Intended Use entstehen im Fachbereichs-Prozess; erste Risikobetrachtung und Grundsatzentscheidung über Lösungsweg und Lieferant.
ProjektPlanung, Spezifikation, Konfiguration bzw. Entwicklung, Verifizierung und Freigabe werden risikobasiert skaliert; Lieferantenleistungen werden bewertet und genutzt statt wiederholt.
BetriebDie längste Phase: Änderungs- und Konfigurationsmanagement, periodische Bewertung sowie Vorfall- und CAPA-Prozesse halten den validierten Zustand aufrecht.
StilllegungGeordneter Rückzug: Datenmigration oder -archivierung nach Aufbewahrungspflichten. Die Aufzeichnungen bleiben über die Systemlebensdauer hinaus lesbar und verfügbar.

Und das V-Modell? Es ist ein Spezifikations-Verifikations-Modell: Es zeigt, welche Prüfung welcher Spezifikationsebene antwortet. Mehr nicht. Es deckt genau eine Phase ab, das Projekt; Konzept, Betrieb und Stilllegung kommen darin nicht vor. Das V-Modell sitzt innerhalb des Lebenszyklus, ist aber nicht der Lebenszyklus. Der Leitfaden selbst hat das früh nachvollzogen: Schon die First Edition (2008) nahm das klassische V-Diagramm zurück, weil das V zu oft als lineares Wasserfall-Vorgehen fehlgelesen wurde. Die Second Edition führt die generische Spezifikations-Verifikations-Darstellung konsequent fort, und dieselbe Logik trägt auch iterative, agile Ansätze. Dort wird sie lediglich inkrementell durchlaufen.

Was das System erzeugt, folgt dem ältesten Muster der IT: Eingabe, Verarbeitung, Ausgabe. Eine Funktion macht aus Eingangsdaten Ausgangsdaten; die Summe der Funktionen ist das System. Seine Ausgaben sind elektronische Aufzeichnungen und Signaturen. Sie unterliegen 21 CFR Part 11 und Annex 11, und ihr regelkonformes Entstehen wird im validierten System mit nachgewiesen. Annex 11 gehört dem GMP-Regelwerk an. Das Prinzip gilt im gesamten GxP-Spektrum, in der klinischen Forschung etwa über ICH E6(R3) und die EMA-Guideline computerised systems.

Das V-Modell beantwortet die Frage "Wogegen prüfe ich?" - nicht die Frage, wie ein System dokumentiert und nachweisbar lebt.
Der Umfang

Was gehört zu einer GAMP-5-Validierung?

Eine GAMP-5-Validierung besteht aus einer Kette von Nachweisen. Sie beginnt in der Konzeptphase und schließt das Projekt mit dem Validierungsbericht ab. Jedes Glied beantwortet eine Frage, die ein Inspektor später stellen wird, etwa wofür das System gedacht ist, welche Risiken gesehen wurden, wie geprüft wurde und wer freigegeben hat. Acht Schritte liefern den Kern dieser Nachweise. Wie tief jeder Schritt geht, bestimmt das Risiko. Die Kette endet nicht mit der Freigabe. Jede spätere Änderung am System durchläuft sie erneut, im Umfang der Änderung, und die periodische Bewertung stellt fest, ob die Nachweise noch zum betriebenen System passen. Wer die Nachweise im Betrieb fortschreibt, hält den validierten Zustand, den GAMP 5 als Ziel der Betriebsphase beschreibt.

Den Validierungsplan mit Umfang, Rollen und Vorgehen zu Projektbeginn festlegen
Erheben, welche Leistung das System im Prozess erbringen muss, und sie als Anforderungen des Fachbereichs festhalten
Die Funktionen nach GxP-Impact bewerten und die Prüftiefe aus der Risikobewertung ableiten
Die Vorleistung des Lieferanten bewerten und nur bewertete Anteile in den Nachweis übernehmen
Konfiguration oder Entwicklung so weit spezifizieren, wie Risiko und Individualisierungsgrad es verlangen
Gegen die Spezifikation verifizieren, skriptbasiert, explorativ oder automatisiert
Jede risikorelevante Anforderung rückverfolgbar mit ihrer Prüfung verknüpfen
Im Validierungsbericht die Ergebnisse zusammenfassen, die Eignung bestätigen und die Freigabe vorbereiten
Risiko bestimmt die Tiefe

Der Risikoprozess hinter dem Nachweis.

Innerhalb der Phasen steuert das Qualitätsrisikomanagement, wofür Nachweise entstehen und wie tief sie gehen. Den systematischen Prozess dafür definiert ICH Q9. GAMP 5 übersetzt ihn für computergestützte Systeme in fünf Stufen:

  1. 1

    Initiale Risikobewertung

    Erste Einschätzung des Systems im Prozesskontext: Welchen Einfluss hat es auf GxP-relevante Abläufe? Welchen Impact-Level hat das System insgesamt?

  2. 2

    Relevante Funktionen identifizieren

    Welche Funktionen berühren Patientensicherheit, Produktqualität oder Datenintegrität? Nur sie tragen das Risiko und verdienen die Prüftiefe.

  3. 3

    Funktionale Risikobewertung & Kontrollen

    Je identifizierter Funktion: Fehlerszenarien identifizieren, bewerten und technische, prozessuale oder organisatorische Kontrollmaßnahmen festlegen.

  4. 4

    Kontrollen umsetzen & verifizieren

    Die Maßnahmen werden implementiert und nachvollziehbar verifiziert, rückverfolgbar bis zur Anforderung, die sie absichern.

  5. 5

    Periodisch überprüfen

    Risiken und Kontrollen werden im Betrieb regelmäßig bewertet. Der validierte Zustand ist ein gepflegter Zustand, kein Archivdokument.

Die Kategorien

Software-Kategorien: Kontinuum, keine Checkliste.

Die GAMP-Kategorien ordnen Software nach Art und Individualisierungsgrad; dahinter stehen zwei kausale Größen: Neuheit und Komplexität. Je mehr Individualität das regulierte Unternehmen verlangt und je weiter es damit vom Standard der Software abweicht, desto weniger trägt die bewertbare Vorleistung des Lieferanten, und desto größer wird der eigene Nachweisanteil.

KategorieWas daraus folgt
1 · Infrastruktur-SoftwareBetriebssysteme, Datenbanken, MiddlewareEtabliert und breit im Einsatz, also geringe Neuheit. Wird kontrolliert betrieben und qualifiziert, nicht einzeln validiert.
3 · Standardproduktenicht konfiguriert, "wie gekauft"Der Nachweis stützt sich auf bewertete Vorleistung: Lieferantenbewertung und Verifizierung gegen die eigenen Anforderungen tragen ihn.
4 · Konfigurierte ProdukteLIMS, MES, eQMS, ERPDie Konfiguration ist der neue, unerprobte Teil. Der Nachweis konzentriert sich auf sie und auf die Prozesse, die die Konfiguration abbildet.
5 · IndividualentwicklungEigenentwicklung, Custom-CodeMaximale Neuheit, keine Vorleistung, auf die sich der Nachweis stützen könnte: Der volle Lebenszyklus-Nachweis von der Spezifikation bis zum Test liegt beim Betreiber, unterstützt durch seinen Lieferanten.

Die Second Edition stellt klar, was die Praxis oft verkürzt: Die Kategorien sind ein Kontinuum, kein Raster. Reale Systeme mischen Komponenten mehrerer Kategorien. Ein MES etwa trägt Anteile von 3, 4 und 5 zugleich. Und die Kategorie ist nur ein Skalierungsfaktor neben GxP-Impact, Komplexität und Neuheit. Wer sie als Validierungs-Checkliste liest, validiert am Risiko vorbei. Die Verbreitung eines Produkts spielt dabei eine eigene Rolle: Je mehr Anwender eine Standardfunktion nutzen, desto mehr liegt dem Lieferanten selbst daran, diesen Standard zu härten. Ein Fehler darin ist unmittelbar ein Reputationsschaden. In den Nachweis eingehen kann davon aber nur, was als bewertbare Vorleistung vorliegt. Richtig angewendet macht GAMP 5 die Validierung damit effizient: prüfbare Anforderungen, risikobasierte Entscheidungen, genutzte Lieferanten-Vorleistung, gezieltes Testen, Werkzeuge und Automatisierung. Der Aufwand landet dort, wo das Risiko ist.

FAQ

Häufige Fragen zur GAMP-5-Validierung.

Nein. Die Validierung selbst verlangen die Regularien, EU GMP Annex 11 und 21 CFR Part 11. GAMP 5 ist kein Regelwerk, sondern die etablierte Methodik der Industrie, diesen Nachweis risikobasiert zu führen. Die CSA-Guidance der FDA nennt in der geltenden Fassung (02/2026) die Second Edition als eine Orientierungsquelle für Testmethoden.

Risikobasiert: Die Second Edition ermutigt neben skriptbasierten Tests ausdrücklich zu explorativem und nicht skriptbasiertem Testen sowie zu Testautomatisierung und lässt elektronische Aufzeichnungen aus Werkzeugen an die Stelle formaler Testdokumente treten. Maßstab ist die nachweisbare Abdeckung der risikorelevanten Anforderungen, nicht das Formular.

Ja, ausdrücklich seit der Second Edition: Sie bezieht die Regulierung der Medizinprodukte-Industrie ein und adressiert Produktions- und QMS-Systeme der Hersteller. Die erste Edition hatte eingebettete Medizinprodukte-Software noch ausgeschlossen.

Nein. Computer Software Assurance konkretisiert auf FDA-Seite das risikobasierte Testen von Produktions- und QMS-Software der Medizinproduktehersteller. GAMP 5 hatte dieses risikobasierte Testen methodisch bereits angelegt. Beachtung findet der Ansatz weit über diesen formalen Geltungsbereich hinaus. Beide Werke verweisen beiläufig aufeinander, ohne sich gegeneinander zu positionieren. Die Guidance nennt GAMP 5 einmal in einer Fußnote zu den Testmethoden, und GAMP 5 führt umgekehrt die CSA-Vorarbeiten der FDA im Kapitel zum Testen und im Glossar. GAMP 5 liefert den Lebenszyklus, CSA schärft die Teststrategie: kein Ersatz, sondern zwei Perspektiven auf denselben Nachweis. Wie eng beide Stränge verzahnt sind, zeigen die Beteiligten: Am GAMP Good Practice Guide "Testing GxP Systems" (3rd Edition), erschienen im Juli 2026, wirkten Mitglieder des FDA-Industrie-CSA-Teams (FICSA) mit; Frank Henrichmann (QFINITY) hat ihn als Reviewer des ISPE Editorial Review Board begutachtet. Ein eigenes Kapitel behandelt computergestützte Testwerkzeuge und bewertet sie nach ISPE GAMP 5 (Second Edition).

Das regulierte Unternehmen. Es kann Lieferanten und Dienstleister einbinden und deren Nachweise nutzen, soweit es sie bewertet hat. Die Verantwortung für den validierten Zustand bleibt beim Betreiber, auch wenn Dritte Leistungen erbringen. GAMP 5 beschreibt dafür die Rollen von Prozesseigner und Systemeigner. Der Fachbereich verantwortet Intended Use und Anforderungen, die IT den Betrieb, die Qualitätseinheit die unabhängige Prüfung.

Mitgewirkt

QFINITY im GAMP 5 Second Edition Kernteam.

Als langjährig aktives Mitglied der ISPE GAMP Community hat QFINITY im Kernteam an Erstellung und Review des Leitfadens mitgearbeitet. Diese Erfahrung zählt in der Praxis überall dort, wo der Text Ermessensspielraum lässt: Wir kennen die Absicht hinter den Formulierungen. Am Kernteam waren auch Mitglieder des FDA-Industrie-CSA-Teams (FICSA) beteiligt; die CSA-Perspektive ist damit direkt in die Second Edition eingeflossen. Unsere Einordnung der Second Edition ist als Fachbeitrag in der Pharm. Ind. erschienen. Wie die Methodik im Mandat trägt, zeigt die Fallstudie zur S/4HANA-Conversion: validiert und ohne lokale Ausfälle live gegangen.

  • Beitrag zu Erstellung und Review von GAMP 5 Second Edition
  • Frank Henrichmann: Chair des GAMP Global Steering Committee
  • Oliver Herrmann: GAMP Track Lead der ISPE Europe Annual Conference 2026
  • Qualifizierte ISPE-GAMP-Trainer
  • Mitwirkung am GPG "Enabling Innovation", auf dem die Second Edition aufbaut
Frank Henrichmann und Oliver Herrmann zeigen auf ihre Namen auf der GAMP-5-Second-Edition-Mitwirkenden-Tafel der ISPE
Aus erster Hand

Der Leitfaden, auf den die FDA selbst verweist.

QFINITY präsentierte die Second Edition wenige Monate nach ihrem Erscheinen auf der 15. Offiziellen GAMP 5 Konferenz in Mannheim (2022) und kennt die Prinzipien des Guides aus erster Hand. Auch die FDA zieht den Guide seit Langem als Referenz heran: 2003 nannte ihre Part-11-Guidance den GAMP 4 Guide als Industrie-Referenz für die Validierung; seit der Fassung 02/2026 nennt die CSA-Guidance die Second Edition bei den Testmethoden. Weder der Entwurf noch die Erstfassung enthielten diese Referenz.

Critical Thinking CSA KI / ML Agile Cloud / SaaS

Stand:

Mehr aus den Dienstleistungsbereichen

Vom Leitfaden zur gelebten Praxis.

Sprechen wir über Ihre Validierung.

Wir übersetzen GAMP 5 Second Edition in Ihre konkrete Validierungsstrategie, von risikobasierter CSV über Computer Software Assurance und KI/ML bis hin zu Agile und Cloud/SaaS. Erstgespräch kostenfrei, etwa 30 Minuten, direkt mit einem Mitwirkenden des Kernteams. Sie nennen uns System und Kategorie, wir sagen Ihnen, welche Nachweise wir dafür als angemessen ansehen und welche Sie sich sparen können.

Erstgespräch vereinbaren