Inhaltsverzeichnis
Das Wichtigste vorab
Was ist GAMP 5?
GAMP 5 ist ein Leitfaden der ISPE für den risikobasierten Umgang mit computergestützten Systemen im GxP-Umfeld. Er unterstützt die Eignung für den vorgesehenen Einsatz über den Lebenszyklus. Der Umfang der Aktivitäten richtet sich nach den relevanten Risiken, der Komplexität und verfügbaren Nachweisen. GAMP 5 ist keine Rechtsvorschrift; die jeweils anwendbaren regulatorischen Anforderungen bleiben maßgeblich.
- Der vorgesehene Einsatz und die Prozessrisiken bestimmen den Nachweisbedarf.
- Eine Softwarekategorie allein legt weder Testumfang noch Dokumentenpaket fest.
- Lieferantennachweise lassen sich nach einer Bewertung gezielt einbeziehen.
- Änderungen, Betrieb und Stilllegung gehören zur Lebenszyklusbetrachtung.
GAMP 5, CSV und regulatorische Anforderungen einordnen
GAMP steht für Good Automated Manufacturing Practice. Die ISPE beschreibt den Ansatz als praktische Hilfestellung für Patientensicherheit, Produktqualität und Datenintegrität. Er liefert eine gemeinsame Sprache für Fachbereich, Qualitätssicherung, IT und Lieferanten. Die zweite Ausgabe des GAMP-5-Leitfadens erschien im Juli 2022. Die hier erläuterten Grundlagen beziehen sich auf die Anwendung des Ansatzes; einen Vergleich der Ausgaben behandelt der verlinkte Vertiefungsartikel.
Computer System Validation, kurz CSV, bezeichnet die Validierungsarbeit am vorgesehenen Einsatz eines computergestützten Systems. GAMP 5 unterstützt deren Planung und Durchführung. Welche Pflichten tatsächlich gelten, ist dagegen anhand von Tätigkeit, Produkt und regulatorischem Umfeld zu bestimmen. Beispielsweise adressiert EU-GMP Annex 11 computergestützte Systeme innerhalb GMP-regulierter Tätigkeiten. Part 11 bewertet elektronische Aufzeichnungen und Signaturen in seinem FDA-bezogenen Geltungsbereich.
Empfehlung für den Projektstart: Halten Sie diese drei Ebenen getrennt fest: anwendbare Anforderungen, internes Qualitätsverfahren und gewählte Projektmethodik. So bleibt erkennbar, ob eine Maßnahme regulatorisch begründet ist, aus Ihrer SOP folgt oder eine zweckmäßige Projektentscheidung darstellt. Ein Verweis auf GAMP 5 ersetzt diese Zuordnung nicht.
Vom vorgesehenen Einsatz zu prüfbaren Risiken
Eine Produktbezeichnung wie ERP, Laborsoftware oder Dokumentenmanagement beschreibt den Validierungsumfang nur unzureichend. Als praktische Ausgangsbasis empfiehlt sich eine Beschreibung der konkreten Nutzung: Welche Aufgabe erledigt das System, welche Entscheidung stützt sich auf seine Daten, wer arbeitet damit und welche Nachweise müssen später verfügbar sein? Grenzen Sie auch Funktionen ab, die außerhalb des betrachteten Einsatzes liegen.
Aus diesen Angaben lassen sich Fehlerszenarien formulieren. Statt „Datenintegrität ist kritisch“ wäre ein prüfbarer Ausgangspunkt: Ein importierter Freigabestatus könnte falsch zugeordnet werden und eine unzulässige Weiterverarbeitung ermöglichen. Anschließend werden mögliche Folgen, vorhandene Kontrollen und deren Wirksamkeit betrachtet. Eine Zahlenbewertung ohne nachvollziehbares Szenario erklärt kaum, warum ein bestimmter Test erforderlich ist.
Empfehlung: Verknüpfen Sie jedes wesentliche Risiko mit einer Anforderung und einem vorgesehenen Nachweis. Manche Kontrollen werden durch einen Funktionstest belegt, andere durch eine Konfigurationsprüfung, ein Lieferantendokument oder einen überprüften Betriebsablauf. Die Begründung sollte zeigen, warum diese Kombination für den vorgesehenen Einsatz ausreicht und welche Restunsicherheit bleibt. Die Wahl eines schlanken Nachweises braucht dieselbe fachliche Sorgfalt wie die Wahl eines umfangreichen Tests.
GAMP-5-Softwarekategorien 1, 3, 4 und 5 einordnen
Die Kategorisierung hilft, die Beschaffenheit von Softwarekomponenten zu verstehen. Ein System kann Standardfunktionen, konfigurierbare Bestandteile und individuelle Erweiterungen verbinden. Ein ISPE-Fachbeitrag von 2026 betont deshalb die Betrachtung der Komponenten und warnt vor einer Validierungscheckliste, die nur aus einer Kategorie abgeleitet wird. GxP-Auswirkung, Komplexität und Neuartigkeit bleiben weitere Entscheidungsgrößen.
Für die Praxis bedeutet das: Eine verbreitete Standardkomponente kann einen hochkritischen Prozess unterstützen. Umgekehrt rechtfertigt eine kleine Eigenentwicklung nicht automatisch dasselbe Vorgehen wie ein komplexes Gesamtsystem. Die folgende Kurzübersicht erläutert die Kategorien mit eigenen Planungsfragen; sie legt kein festes Test- oder Dokumentenpaket fest.
| Kategorie | Kurze Einordnung | Frage für die Planung |
|---|---|---|
| 1 · Infrastruktursoftware | Software als technische Grundlage, beispielsweise Betriebssysteme oder Datenbankmanagementsysteme. | Welche Version, Konfiguration und Betriebsnachweise benötigt die unterstützte Anwendung? |
| 3 · Standardkomponenten | Standardsoftware ohne kundenspezifische Konfiguration des Geschäftsprozesses. | Passt das vorhandene Verhalten zum vorgesehenen Einsatz, und welche Lieferantennachweise tragen die Bewertung? |
| 4 · Konfigurierte Komponenten | Vorhandene Funktionen werden durch Einstellungen an den Geschäftsprozess angepasst. | Welche Konfiguration steuert kritische Entscheidungen, und wie wird ihre Wirkung geprüft? |
| 5 · Individuelle Anwendungen oder Komponenten | Programmlogik wird für den konkreten Bedarf entwickelt oder angepasst. | Wie werden Anforderungen, Entwicklung, Fehlerbehandlung und Änderungen nachvollziehbar geprüft? |
Quellen: [3]
Ein nachvollziehbares Vorgehen für die Validierung
Die folgende Abfolge ist eine Umsetzungsempfehlung. Sie kann in ein sequenzielles Projekt oder in mehrere Iterationen eingebunden werden. ISPE beschreibt ausdrücklich, dass Spezifikation und Verifikation auch iterative und inkrementelle Entwicklung unterstützen. Entscheidend ist die nachvollziehbare Verbindung von Entscheidungen und Nachweisen für den jeweils betrachteten Stand.
Beginnen Sie mit Scope, Verantwortlichkeiten und vorhandenen Unterlagen. Formulieren Sie anschließend die Anforderungen in einer prüfbaren Form. „Das System muss sicher sein“ lässt viele Auslegungen zu. „Nur die benannte Rolle darf den geprüften Status ändern“ liefert eine deutlichere Grundlage für Konfiguration, Berechtigung und Test. Akzeptanzkriterien werden vor der Ausführung festgelegt, damit der Befund später nicht das erwartete Ergebnis bestimmt.
Planen Sie danach die Nachweise, führen Sie die Prüfungen durch und behandeln Sie Abweichungen nachvollziehbar. Halten Sie betroffene Anforderungen, fachliche Auswirkungen, Korrekturen und notwendige Wiederholungen fest. Vor der Nutzung wird der erreichte Stand gegen den vorgesehenen Einsatz bewertet. Offene Punkte brauchen eine begründete Behandlung und klare Zuständigkeit. Für den Betrieb werden außerdem Änderungen, Störungen und die Pflege der Nachweise vorbereitet.
Welche Dokumente und Nachweise sind sinnvoll?
Ein universelles Dokumentenpaket lässt sich aus dem Namen GAMP 5 nicht ableiten. Zweckmäßiger ist eine Frage nach den Entscheidungen, die Ihr Team erklären können muss. Die nachfolgende Struktur ist eine Empfehlung für die Organisation der Arbeit. Ob die Informationen in einzelnen Dokumenten, einer kontrollierten Projektmappe oder einem geeigneten Werkzeug geführt werden, hängt von Ihrem Qualitätsverfahren ab.
Für jede wichtige Entscheidung sollte erkennbar sein, auf welchen Systemstand sie sich bezieht, wer sie getroffen hat und welches Ergebnis sie trägt. Doppelte Informationen in vielen Dateien erhöhen dagegen den Pflegeaufwand und können widersprüchliche Stände erzeugen. Verweise sind hilfreich, wenn die referenzierten Nachweise auffindbar bleiben und ihre Aussage für das betrachtete System bewertet wurde.
- Scope und Systembeschreibung: vorgesehener Einsatz, Prozessgrenzen, Schnittstellen und Verantwortliche.
- Anforderungen und Risikobewertung: benötigte Funktionen, Fehlerszenarien und begründete Prüftiefe.
- Lieferantenbewertung: relevante Unterlagen, bewertete Abdeckung und offene Fragen.
- Prüfnachweise: Akzeptanzkriterien, tatsächlich verwendeter Stand, Ergebnisse und Abweichungen.
- Zusammenfassende Bewertung: erreichte Abdeckung, verbleibende Punkte und Entscheidung zur vorgesehenen Nutzung.
- Betriebsübergabe: verantwortliche Rollen, kontrollierte Änderungen, Störungen und benötigte Schulung.
Lieferantennachweise und Cloud-Betrieb bewerten
ISPE hebt die Beteiligung von Lieferanten sowie die Nutzung ihres Wissens und ihrer Dokumentation hervor. Daraus folgt als Umsetzungsempfehlung: Klären Sie früh, welche Nachweise verfügbar sind und welche Aussagen sie tatsächlich unterstützen. Ein Testbericht für eine Produktversion beantwortet eine andere Frage als ein Bericht über die eingerichteten Prozesse Ihres Unternehmens.
Prüfen Sie insbesondere den Bezug zu Version, Konfiguration und Umgebung, die beschriebenen Akzeptanzkriterien sowie den Umgang mit Befunden. Ordnen Sie anschließend zu, welche Anforderungen durch den Nachweis abgedeckt werden und wo zusätzliche Prüfungen benötigt werden. Die bloße Existenz eines Zertifikats oder eines umfangreichen Handbuchs ist dafür noch keine fachliche Bewertung.
Bei Cloud-Diensten empfiehlt sich außerdem eine klare Vereinbarung über Änderungen und verfügbare Informationen: Wer erhält Release-Hinweise, bewertet deren Auswirkungen und stellt eine Testmöglichkeit bereit? Wer bearbeitet Störungen, sichert Daten und ermöglicht deren Rückgabe? Die Antworten sollten zum tatsächlichen Dienstmodell passen. Für GMP-relevante Systeme verlangt Annex 11 formale Vereinbarungen mit externen Beteiligten und eine angemessene Lieferantenbewertung; diese Anforderungen sind zusätzlich zum gewählten GAMP-Vorgehen zu berücksichtigen.
Beispiel: Ein geänderter Freigabeablauf im ERP
Beispiel: Ein Unternehmen verwendet ein konfiguriertes ERP für die Bearbeitung qualitätsrelevanter Bestandsstatus. Eine neue Schnittstelle überträgt einen Status aus einem vorgelagerten System. Das Kernprodukt bleibt gleich, aber die tatsächliche Nutzung und der Datenfluss verändern sich. Die alte Einstufung der Software beantwortet daher nicht, ob der neue Ablauf ausreichend abgesichert ist.
Ein möglicher Bewertungsweg beginnt mit der Statusbedeutung und den zulässigen Folgeschritten. Anschließend werden Zuordnung, Berechtigung und Fehlerbehandlung betrachtet. Geeignete Testfälle könnten eine zulässige Übertragung, eine unbekannte Statuskennung, eine doppelte Nachricht und eine unterbrochene Verbindung abdecken. Zusätzlich wäre zu prüfen, wie das Team einen Fehler erkennt, bewertet und kontrolliert korrigiert. Diese Auswahl illustriert das Vorgehen; die tatsächliche Prüftiefe hängt vom konkreten Prozess ab.
Für die weitere Nutzung empfiehlt sich, die Schnittstelle in Systembeschreibung und Änderungsverfahren aufzunehmen. Eine spätere Anpassung des Mappings kann dann auf denselben Anforderungen und Risiken aufbauen. Auch bei einer Stilllegung bleibt zu klären, welche Nachweise erhalten werden, wie sie lesbar bleiben und wer sie abruft. Der Lebenszyklus endet aus Nachweissicht nicht allein mit dem Abschalten einer Anwendung.
Checkliste für den nächsten Projektschritt
Diese Checkliste ist eine Arbeitshilfe für das Projektgespräch. Eine positive Antwort sollte sich auf einen konkreten Nachweis oder eine benannte Entscheidung beziehen. Ein offener Punkt beschreibt zunächst Klärungsbedarf; seine Bedeutung ist anhand des vorgesehenen Einsatzes zu bewerten.
- Sind die betroffenen Prozesse, Daten, Komponenten und Schnittstellen benannt?
- Ist nachvollziehbar, welche regulatorischen Anforderungen und internen Verfahren gelten?
- Lassen sich die wesentlichen Risiken mit Anforderungen und Nachweisen verbinden?
- Wurde die Verwendbarkeit vorhandener Lieferantennachweise bewertet?
- Sind Akzeptanzkriterien, Testumgebung und Umgang mit Abweichungen geklärt?
- Kann die Entscheidung zur Nutzung anhand des erreichten Stands erklärt werden?
- Sind Verantwortliche für Änderungen, Störungen und den späteren Datenzugriff bestimmt?
Häufige Fragen zu GAMP 5
Ist GAMP 5 gesetzlich vorgeschrieben?
GAMP 5 ist ein ISPE-Leitfaden und keine eigenständige Rechtsvorschrift. Er unterstützt die Umsetzung anwendbarer Anforderungen. Welche Pflichten Ihr Unternehmen erfüllen muss, ergibt sich aus dem konkreten regulatorischen Umfeld. Ein internes Qualitätsverfahren kann die Nutzung von GAMP-Grundsätzen vorsehen; dadurch wird die gewählte Methode Teil Ihres eigenen Vorgehens.
Bestimmt die GAMP-Kategorie den Validierungsumfang?
Die Kategorie ist ein Hilfsmittel zur Bewertung von Komponenten. Sie ersetzt weder die Betrachtung des vorgesehenen Einsatzes noch die Risikobewertung. GxP-Auswirkung, Komplexität, Neuartigkeit und verfügbare Nachweise beeinflussen die Aktivitäten. Eine pauschale Regel wie „Diese Kategorie braucht immer genau diese Dokumente“ bildet diese Unterschiede nicht ausreichend ab.
Muss jede Standardfunktion erneut getestet werden?
Der Bedarf an eigenen Nachweisen ist zu begründen. Bewertete Lieferantenunterlagen können Anforderungen abdecken. Kundenspezifische Konfiguration, Schnittstellen und relevante Prozessabläufe brauchen eine Betrachtung ihres konkreten Einsatzes. Empfehlung: Erstellen Sie zunächst eine Abdeckungsübersicht und entscheiden Sie dann, wo eigene Prüfungen einen erforderlichen zusätzlichen Nachweis liefern.
Ist GAMP 5 mit agiler Entwicklung vereinbar?
Ja. Die ISPE beschreibt den Spezifikations- und Verifikationsansatz ausdrücklich als vereinbar mit iterativen und inkrementellen Methoden. Die Umsetzung sollte Anforderungen, Risiken, Änderungen und Nachweise auch über mehrere Iterationen nachvollziehbar verbinden. Eine kurze Iteration ersetzt diese Verbindung nicht; sie kann deren Bearbeitung in kleinere, überprüfbare Schritte aufteilen.
Was ist bei einem bereits laufenden System sinnvoll?
Empfehlung: Beginnen Sie mit dem heutigen Einsatz und dem vorhandenen Nachweisstand. Bewerten Sie wesentliche Prozessrisiken, bekannte Störungen, Änderungen und verfügbare Unterlagen. Daraus entsteht ein priorisierter Plan für offene Nachweise und notwendige Maßnahmen. Eine historische Dokumentenliste allein zeigt noch nicht, ob die aktuelle Nutzung ausreichend abgedeckt ist.
Kann ein Anbieter unser System nach GAMP 5 zertifizieren?
Ein Anbieter kann Unterlagen und Leistungen zum gewählten Vorgehen bereitstellen. Ein solcher Hinweis ersetzt die Bewertung des konkreten Einsatzes im regulierten Unternehmen nicht. Prüfen Sie bei Aussagen wie „GAMP-konform“, welche Version, Konfiguration, Prozesse und Nachweise damit gemeint sind. Eine behördliche Zulassung Ihres Einsatzes lässt sich daraus nicht ableiten.
Worin unterscheidet sich dieser Leitfaden vom Artikel zur zweiten Ausgabe?
Dieser Leitfaden erklärt die dauerhaften Grundlagen und ihre Anwendung: Scope, Risiken, Nachweise und Betrieb. Der Vertiefungsartikel zur zweiten Ausgabe behandelt den Änderungsblick auf die 2022 veröffentlichte Ausgabe. Für die Planung eines Projekts ist die konkrete Nutzung entscheidend; für die Überarbeitung einer bestehenden Methodik kann der Ausgabenvergleich ergänzend helfen.
Quellen & fachlicher Stand
Grundlage sind öffentliche ISPE-Veröffentlichungen und die ergänzend genannten Regelwerktexte. Die vollständige kostenpflichtige Ausgabe des Leitfadens wurde für diesen Artikel nicht ausgewertet. Vorgehensweisen, Tabelle, Beispiel und Checkliste sind ausdrücklich praktische Empfehlungen; sie ersetzen keine Bewertung Ihres konkreten Einsatzes.
- ISPE: GAMP – Zweck, Lebenszyklus und Einordnung
- ISPE: GAMP 5 Guide, Second Edition – Verlagsbeschreibung
- ISPE Pharmaceutical Engineering: When Is a Category Not a Category? (2026)
- Europäische Kommission: Annex 11 – Computerised Systems (2011)
- eCFR: 21 CFR Part 11 – Electronic Records; Electronic Signatures
Zuletzt fachlich geprüft am 06.10.2026.
Daniel Herrmann Consulting
GAMP-Grundsätze in Ihrem Team anwenden
Wir unterstützen Sie dabei, die beschriebene Methodik in nachvollziehbare Entscheidungen und passende Nachweise für Ihre Systemlandschaft zu übersetzen.
- IT-GxP-Coaching →
Wir begleiten Ihr Team bei konkreten Bewertungsfragen und der Anwendung vorhandener SOPs und Vorlagen.
- IT-GxP-Compliance-Programm →
Wir unterstützen den Aufbau eines passenden Regelwerks mit Policy, SOPs, Vorlagen und Schulung.