Inhaltsverzeichnis
Das Wichtigste vorab
Wie bestimmen Sie die passende GAMP-Kategorie?
Betrachten Sie die konkrete Softwarekomponente und ihre Umsetzung: technische Grundlage, Standardfunktion, konfigurierte Prozesslogik oder individuell entwickelte Funktion. Begründen Sie die Einordnung anhand des tatsächlichen Stands. Die Kategorie unterstützt die Planung, bestimmt aber weder das GxP-Risiko noch automatisch den Validierungsumfang. Ein eigenes Skript verändert die Bewertung seiner Funktion und Abhängigkeiten; es macht nicht pauschal jede andere Komponente zu Individualsoftware.
- Kategorisieren Sie nachvollziehbare Komponenten statt Handelsnamen.
- Trennen Sie Beschaffenheit, GxP-Auswirkung und verfügbare Evidenz.
- Behandeln Sie Grenzfälle anhand der tatsächlich geänderten Logik.
- Leiten Sie Nachweise aus konkreten Risiken und offenen Fragen ab.
1. Von der Produktbezeichnung zur konkreten Entscheidung kommen
GAMP ist ein methodischer Leitfaden der ISPE und keine gesetzliche Einteilung von Softwareprodukten. Im Humanarzneimittel-GMP-Kontext bleibt der tatsächliche Einsatz unter den anwendbaren Anforderungen zu beurteilen. Annex 11 richtet den Blick unter anderem auf Systemfunktion, Risiken und Nachweise. Eine Kategorienummer ersetzt diese Betrachtung nicht.
Der ISPE-Fachbeitrag von 2026 erläutert die Kategorisierung vor allem auf Komponentenebene. Eine frühe Gesamtsicht kann bei der Planung der Lieferantenbewertung helfen; daraus entsteht jedoch keine vollständige Validierungscheckliste. Der Nutzen liegt darin, die Beschaffenheit eines Bausteins verständlich zu machen.
Für die Praxis beginnt die Arbeit deshalb mit einer Frage: Welche Funktion verändern oder verwenden Sie hier tatsächlich? Erst danach folgen Kategorie, Begründung und benötigte Evidenz. Eine Produktaussage des Vertriebs kann ein Hinweis sein, beantwortet diese Frage für Ihre Installation aber nicht allein.
2. Die Kategorien 1, 3, 4 und 5 mit ihrem Zweck verstehen
Die bekannten Nummern bezeichnen unterschiedliche Arten von Softwarebestandteilen. Die folgende knappe Orientierung verbindet die historische Nummerierung mit den im öffentlichen ISPE-Beitrag von 2026 erläuterten Komponentenarten. Sie ist keine Wiedergabe des kostenpflichtigen Leitfadens und keine Liste vorgeschriebener Dokumente.
Kategorie 2 bezeichnete früher Firmware als eigene Softwarekategorie. Bereits der ISPE-Bericht zur Einführung von GAMP 5 aus dem Jahr 2008 beschreibt ihre Entfernung. Sie ist daher keine fehlende Rechtskategorie und wurde nicht erst mit der zweiten Auflage 2022 gestrichen.
- 1: Infrastruktursoftware, Werkzeuge und technische Dienste als Grundlage der Anwendung.
- 3: Standardkomponenten ohne kundenspezifische Konfiguration des Geschäftsprozesses; reine Laufzeitparameter können trotzdem vorhanden sein.
- 4: Komponenten, deren vorhandene Funktionen für den konkreten Geschäftsprozess konfiguriert werden.
- 5: Anwendungen oder Bestandteile mit eigens entwickelter oder angepasster Programmlogik.
3. Die Einordnung mit den richtigen Informationen vorbereiten
Zeichnen Sie zunächst einen kleinen Datenfluss: Wo entstehen die Informationen, welcher Baustein verändert sie und welche Entscheidung verwendet sie? Ordnen Sie dazu Version, Konfiguration, eigene Erweiterung und Betreiber zu. Trennen Sie nur so weit, dass Unterschiede für Nachweise und Änderungen tatsächlich verständlich werden.
Fragen Sie den Lieferanten konkret nach der Grenze zwischen ausgelieferter Funktion und Ihrer Anpassung. Ein Konfigurationsauszug ist hilfreicher als die pauschale Antwort „alles Standard“. Für eigenen Code benötigen Sie eine identifizierbare Fassung und eine Beschreibung seiner Aufgabe. Noch unbekannte Bestandteile bleiben als offene Frage sichtbar.
Eine brauchbare Einordnung nennt auch, welche Information sie trägt. So kann ein späterer Bearbeiter erkennen, ob das Urteil auf einer angesehenen Konfiguration, einer Herstellerbeschreibung oder lediglich einer noch zu bestätigenden Annahme beruht. Ein vorläufiger Eintrag ist sinnvoller als eine unbegründet endgültige Zahl.
4. Vollständiges illustratives Beispiel: Ein Qualitätsstatus wird weitergegeben
Das folgende System und alle Bezeichnungen sind frei erfunden. Ein Betrieb verwaltet den Qualitätsstatus interner Materialgebinde. Ein Standardmodul zeigt Datensätze an, ein konfigurierter Ablauf erlaubt den vorgesehenen Statuswechsel und ein eigenes Skript übergibt ausgewählte Informationen an eine Planungsliste. Diese Liste darf im Beispiel nur Datensätze mit Status „bereit“ übernehmen.
Der betrachtete Stand heißt F4. Seine sechs Bausteine werden unten vollständig für diesen abgegrenzten Fall eingeordnet. „Vollständig“ bezieht sich auf das beschriebene Beispiel, nicht auf jede denkbare Unternehmensarchitektur. Physische Geräte und weitere Betriebsdienste wären im realen Projekt entsprechend ihrem Einfluss zusätzlich zu erfassen.
Die letzte Spalte enthält eigene Vorschläge für Nachweisentscheidungen. Sie sind keine vorgeschriebenen Prüfpakete der jeweiligen Kategorie. Jede Zeile verbindet Beschaffenheit und konkreten Fehlerfall, damit aus der Einordnung eine bearbeitbare Aufgabe entsteht.
| Komponente und Funktion | Einordnung mit Begründung | Konkrete Auswirkung im Beispiel | Nachweisentscheidung |
|---|---|---|---|
| B7: Betriebssystem und Laufzeit | 1; technische Grundlage, keine individuelle fachliche Logik beschrieben | Ausfall oder unpassender Stand kann Anwendung und Export beeinträchtigen | Benötigte Version und Betriebsgrundlage bestätigen; Wiederanlauf nach tatsächlichem Prozessbedarf betrachten |
| D3: Standard-Datenbankdienst | 1; Speicherung als technische Plattform; fachliche Tabellen-/Anwendungslogik separat betrachten | Fehlende oder falsch wiederhergestellte Daten verändern den Arbeitsstand | Sicherung und Wiederherstellbarkeit relevanter Daten sowie Zusammenspiel mit F4 bewerten |
| V1: unveränderte Datensatzanzeige | 3; ausgelieferte Anzeige ohne eigenen Geschäftsablauf; Darstellungsparameter bleiben Standardparameter | Anwender könnte falsches Gebinde oder unvollständigen Status sehen | Geeignete Lieferantenbelege zu Anzeige übernehmen; lokale Zuordnung und benötigte Felder prüfen |
| W4: konfigurierter Statusablauf | 4; vorhandene Zustände und Übergangsregeln werden für den Ablauf eingestellt | Unzulässiger Wechsel könnte ein gesperrtes Gebinde als bereit kennzeichnen | Konfigurationsreview plus relevante Rollen-, Übergangs- und Fehlerfälle ausführen |
| E2: selbst geschriebener Export | 5; eigener Code wählt Datensätze aus und bildet die Übergabe | Falsche Auswahl oder Zuordnung könnte ein gesperrtes Gebinde weitergeben | Codefassung und Anforderungen verbinden; Auswahl, Kennung, Status und Fehlermeldung gezielt verifizieren |
| J1: Standard-Zeitsteuerung | 1; technisches Werkzeug startet E2, ohne eigene fachliche Auswahlregel | Doppelte oder ausgebliebene Ausführung kann die Planungsliste verfälschen | Startbedingungen und Wiederanlauf betrachten; Doppelverarbeitung gemeinsam mit E2 prüfen |
5. Die Matrix in eine überprüfbare Entscheidung übersetzen
Im konstruierten Test werden drei Datensätze vorbereitet: G-31 steht auf „bereit“, G-32 auf „gesperrt“ und G-33 auf „in Prüfung“. Das vorab definierte Soll für E2 lautet: Nur G-31 erscheint mit unveränderter Kennung in der Planungsliste. Die beiden anderen Datensätze bleiben ausgeschlossen. Die Kategorienummer allein liefert dieses Soll nicht.
Angenommen, nach einer Änderung der Statusbezeichnungen überträgt E2 auch G-32. Dann wird der Zusammenhang zwischen W4, Datenübergabe und Export untersucht. Eine Korrektur am Skript erfordert passende Wiederholungs- und Folgeprüfungen. Daraus folgt jedoch nicht, dass das unveränderte Betriebssystem B7 nun ebenfalls individuell entwickelt wäre.
Ein zweiter Fall betrifft die Zeitsteuerung: Wird derselbe Lauf wiederholt, muss die im Beispiel geforderte Behandlung bereits übertragener Gebinde überprüft werden. Die Plattformkomponente kann Kategorie 1 bleiben, obwohl ihr Zusammenspiel mit E2 für die Prozesssicherheit wesentlich ist.
Die Entscheidung lautet damit nicht „Kategorie 5, alles neu testen“. Sie benennt betroffene Funktionen, veränderte Voraussetzungen, geeignete vorhandene Belege und konkrete Lücken. Das hält den Umfang nachvollziehbar, ohne Auswirkungen außerhalb des Skripts zu übersehen.
6. Grenzfälle zwischen Parameter, Konfiguration und Entwicklung klären
Die entscheidende Grenze verläuft nicht entlang einer Benutzeroberfläche. Ein grafischer Editor kann komplexe Prozesslogik erzeugen; eine Texteingabe kann lediglich einen unveränderten Laufzeitparameter setzen. Untersuchen Sie, was die Einstellung bewirkt und welche Logik tatsächlich neu entsteht.
Die folgende Arbeitshilfe trifft bewusst keine Entscheidung allein anhand von Schlagwörtern wie No-Code, Standard oder Schnittstelle. Sie nennt die Information, die für eine begründete Zuordnung noch benötigt wird. Die Beispielszenarien sind unabhängig vom zuvor beschriebenen Stand F4.
| Situation | Entscheidende Frage | Begründete Behandlung |
|---|---|---|
| Standardanzeige mit einstellbarer Zeitzone | Wird nur die vorhandene Darstellung parametriert oder fachliche Entscheidungslogik verändert? | Reiner Laufzeitparameter macht die Komponente nicht automatisch zu Kategorie 4; seine Wirkung trotzdem prüfen |
| Workflow im grafischen Editor | Werden vorhandene Zustände/Regeln konfiguriert oder eigener Code eingebettet? | Konfigurierten Ablauf betrachten; eigene Codebausteine getrennt identifizieren |
| Standard-Konnektor mit Feldzuordnung | Überträgt er unverändert, transformiert die Konfiguration oder ruft er eigenen Code auf? | Standardfunktion, Mapping und Erweiterung sachlich trennen; Datenwirkung bestimmt Nachweisfragen |
| Kleines Makro in verbreiteter Standardsoftware | Welche eigene Logik verarbeitet welche entscheidungsrelevanten Daten? | Makro als individuellen Bestandteil bewerten, Basissoftware nicht pauschal umklassifizieren |
| Vom Anbieter gepflegte Erweiterung | Ist sie unverändert bereitgestellt, für Sie konfiguriert oder individuell entwickelt? | Lieferantenherkunft allein entscheidet nicht; konkrete Implementierung und verfügbare Evidenz bewerten |
7. Kategorie, GxP-Auswirkung und Unsicherheit getrennt bewerten
Eine Kategorienummer beschreibt nicht, wie schwer die Folge eines Fehlers wäre. Im Beispiel könnte die falsche Statusanzeige einer Standardkomponente eine ungeeignete Materialentscheidung begünstigen. Ein individueller Export für eine rein informelle Auswertung kann dagegen einen anderen Einfluss haben. Die tatsächliche Nutzung entscheidet über diese Folgen.
Der öffentliche ISPE-Beitrag von 2026 betont unter anderem Komplexität und Neuartigkeit. Er zeigt, dass eine komplex konfigurierte Komponente mehr Anlass zur Prüfung geben kann als ein einfacher individueller Baustein. Daraus wird jedoch keine neue pauschale Umkehrregel.
Notieren Sie für jede wichtige Funktion, was fehlschlagen kann, welche Kontrolle den Fehler erkennt oder verhindert und welche Unsicherheit bleibt. ICH Q9(R1) unterstützt eine an Risiko und Wissensstand angepasste Beurteilung. Eine künstliche Genauigkeit wie „Kategorie mal Kritikalität ergibt Testanzahl“ erklärt diese fachlichen Zusammenhänge nicht.
8. Lieferantennachweise und Änderungen auf Komponenten beziehen
Fragen Sie bei einem Herstellerpaket, welche konkrete Aussage für welchen Baustein belegt ist. Ein Test der Standardanzeige V1 kann nützlich sein, während die Auswahlregel in E2 oder Ihr Ablauf W4 außerhalb des geprüften Umfangs liegt. Umgekehrt kann ein Anbieter auch geeignete Belege für eine individuell entwickelte Erweiterung liefern.
Führen Sie deshalb neben der Einordnung die Evidenzreichweite. Eine Kategorie ist weder ein Qualitätszertifikat noch ein Grund, geeignete Unterlagen zu ignorieren. Entscheidend bleibt, ob Stand, Bedingungen und Ergebnis Ihre Frage beantworten.
Bei einer Änderung prüfen Sie Beschaffenheit und Wirkung erneut. Wird aus einer einfachen Feldzuordnung eine selbst programmierte Transformation, ändert sich die Begründung für diesen Bestandteil. Bleibt die Kategorie gleich, kann dennoch ein anderer fachlicher Nachweis erforderlich werden. Eine neue Sperrregel in W4 ist dafür im Beispiel bereits ausreichend.
9. Die Einordnung im KMU mit klaren Aufgaben bearbeiten
Für einen ersten gemeinsamen Durchgang benötigen Sie Prozesswissen, Kenntnis der tatsächlich eingesetzten Konfiguration und Zugang zu den relevanten Lieferantenunterlagen. Nicht jeder Beteiligte muss alle technischen Details beherrschen. Benennen Sie aber, wer offene Fragen beantworten und wer die daraus folgende Planung beurteilen kann.
Bearbeiten Sie zuerst die Komponenten, deren Fehler wichtige Entscheidungen beeinflussen oder deren Umsetzung unklar ist. Halten Sie fehlende Informationen als Aufgabe mit Verantwortlichem fest. Ein schwieriger Grenzfall darf nicht dazu führen, dass die übrigen, gut verstandenen Teile monatelang unbeschrieben bleiben.
Der Aufwand folgt unter anderem Schnittstellen, Eigenentwicklungen, Konfigurationskomplexität und Beleglücken. Die Anzahl der Kategorien sagt darüber wenig aus. Planen Sie nach konkreten Aufgaben wie Konfigurationsreview, Datenabgleich oder Codeprüfung; pauschale Zeit- und Preisversprechen wären ohne diese Informationen nicht belastbar.
10. Checkliste für eine belastbare Komponentenentscheidung
Diese eigene Arbeitshilfe unterstützt den Abschluss Ihrer Einordnung. Sie ist kein ISPE-Formblatt. Ein anderer fachkundiger Bearbeiter sollte die Entscheidung mit den angegebenen Informationen verstehen und bei Änderungen gezielt wieder aufgreifen können.
Bleibt eine Zuordnung unklar, beschreiben Sie zunächst die offene technische Frage und die notwendige Absicherung. Eine unsichere Zahl darf weder eine relevante Prüfung ersetzen noch automatisch ein vollständiges Maximalpaket auslösen.
- Der vorgesehene Einsatz und seine GxP-Grenze sind benannt.
- Komponenten sind nach Funktion und tatsächlichem Stand unterscheidbar.
- Standardfunktion, Prozesskonfiguration und eigener Code werden nicht vermischt.
- Die Begründung verweist auf überprüfbare Informationen.
- Unklare Annahmen sind sichtbar und einer Klärungsaufgabe zugeordnet.
- Die GxP-Auswirkung wird unabhängig von der Kategorienummer bewertet.
- Relevante Abhängigkeiten zwischen Komponenten sind erfasst.
- Lieferantenbelege sind mit ihrer konkreten Reichweite zugeordnet.
- Nachweisentscheidungen beantworten ein Risiko oder eine offene Frage.
- Änderungen können anhand von Version, Konfiguration und Entscheidung nachverfolgt werden.
Häufige Fragen zu GAMP-Kategorien
Kann ein System mehrere GAMP-Kategorien enthalten?
Ja. Eine Anwendung kann technische Plattformen, unveränderte Standardfunktionen, konfigurierte Abläufe und eigenen Code verbinden. Beschreiben Sie diese Bestandteile so, dass ihre Unterschiede für Nachweise und Änderungen nutzbar werden. Eine grobe Gesamteinschätzung kann bei frühen Lieferantenfragen helfen; sie sollte die spätere Komponentenbetrachtung und fachliche Risikobewertung nicht ersetzen.
Quellen: [1]
Warum gibt es bei GAMP 5 keine eigene Softwarekategorie 2?
Kategorie 2 bezeichnete früher Firmware. Der öffentliche ISPE-Bericht von Mai/Juni 2008 nennt die Entfernung dieser eigenständigen Kategorie bereits beim Übergang zu GAMP 5. Das geschah nicht erst 2022. Firmware wird dadurch nicht automatisch unkritisch oder von Nachweisen befreit. Ihre konkrete Funktion und Beschaffenheit müssen im betrachteten System weiterhin verstanden werden.
Ist Kategorie 5 immer riskanter als Kategorie 3?
Nein. Die Nummer ist keine Rangfolge der möglichen GxP-Folgen. Eine unveränderte Standardfunktion kann eine sehr wichtige Entscheidung unterstützen. Auch Komplexität, Neuartigkeit, wirksame Kontrollen und verfügbare Evidenz beeinflussen die Beurteilung. Prüfen Sie das konkrete Fehlerszenario. Weder eine niedrige Nummer noch die Bezeichnung Standard begründet allein einen geringeren Nachweisbedarf.
Macht ein kleines Skript das gesamte System zu Kategorie 5?
Nicht pauschal. Identifizieren Sie den individuellen Bestandteil, seine Aufgabe und seine Abhängigkeiten. Im Beispiel ist E2 eigener Code, während B7 seine Rolle als technische Grundlage behält. Der erforderliche Prüfbereich kann dennoch über das Skript hinausgehen, etwa wenn dessen Ausgabe einen nachfolgenden Prozess beeinflusst. Begrenzte Kategorisierung bedeutet deshalb nicht isoliertes Testen ohne Übergaben.
Bleibt Standardsoftware mit Einstellungen immer Kategorie 3?
Nicht jede Einstellung ist gleich. Eine Zeitzone oder ein Laufzeitparameter kann Teil einer unveränderten Standardfunktion bleiben. Werden vorhandene Funktionen zur konkreten Geschäftsprozesslogik zusammengestellt, ist diese konfigurierte Komponente anders zu betrachten. Beschreiben Sie die tatsächliche Wirkung der Einstellung. Die bloße Existenz eines Einstellungsmenüs oder dessen Bezeichnung entscheidet den Grenzfall nicht.
Quellen: [1]
Sind No-Code-Workflows grundsätzlich Kategorie 4?
Die technische Umsetzung muss geprüft werden. Ein grafisch konfigurierter Ablauf kann vorhandene Funktionen zusammensetzen; eingebettete Skripte oder eigens entwickelte Bausteine ergänzen individuelle Logik. Trennen Sie diese Teile, statt eine Plattformbezeichnung zu klassifizieren. Auch ohne eigenen Code kann ein komplexer Ablauf gezielte Nachweise erfordern. Die Bedienoberfläche sagt wenig über seine fachlichen Auswirkungen aus.
Dürfen wir die Kategorienangabe des Lieferanten übernehmen?
Nutzen Sie sie als begründungsbedürftige Information. Fragen Sie nach betroffenem Produktstand, betrachteten Komponenten und ausgeschlossenen Anpassungen. Eine plausible Einordnung des Standardkerns kann zutreffen, während lokale Konfiguration und Erweiterung gesondert zu betrachten sind. Ebenso können passende Lieferantenbelege Ihre Bewertung tragen. Weder unkritische Übernahme noch pauschale Zurückweisung hilft bei der konkreten Nachweisplanung.
Welche Dokumente sind je GAMP-Kategorie zwingend vorgeschrieben?
Eine Kategorienummer ergibt für sich kein universelles Dokumentenpaket. Legen Sie fest, welche Anforderungen, Entscheidungen und Ergebnisse für den betrachteten Einsatz nachvollziehbar sein müssen. Daraus folgen geeignete Belege und deren Organisation. Der öffentliche ISPE-Beitrag von 2026 warnt ausdrücklich vor einem reinen Checklistenansatz. Interne Verfahren und anwendbare regulatorische Anforderungen müssen daneben berücksichtigt werden.
Müssen wir die Einordnung nach jeder Änderung neu erstellen?
Bewerten Sie zunächst, ob Beschaffenheit, Funktion oder Abhängigkeiten betroffen sind. Eine reine Versionsänderung muss keine neue Kategorie ergeben; neue eigene Programmlogik kann die Einordnung eines Bestandteils verändern. Halten Sie die Entscheidung und ihren Bezug zum neuen Stand fest. Auch bei unveränderter Kategorie können andere Tests nötig werden, wenn sich das fachliche Verhalten ändert.
Ist eine niedrige GAMP-Kategorie ein Compliance-Nachweis?
Nein. Sie beschreibt eine methodische Einordnung, keine behördliche Zulassung oder Bestätigung Ihrer Installation. Ob das System den vorgesehenen Einsatz trägt, hängt von passenden Anforderungen, kontrollierter Umsetzung, geeigneten Nachweisen und beherrschtem Betrieb ab. Eine niedrige Nummer darf weder offene Fehler verdecken noch fehlende Evidenz ersetzen. Dasselbe gilt umgekehrt für einen umfangreichen Dokumentensatz einer höheren Kategorie.
Quellen & fachlicher Stand
Quellenstand: 6. Oktober 2026. Öffentliche ISPE-Beiträge und die Verlagsübersicht wurden gelesen, nicht der kostenpflichtige GAMP-Volltext. Die Beiträge von 2008/2010 belegen historische Einordnung und Nummerierung. Komponentenmatrix, Grenzfälle und Prüffall sind eigene illustrative Arbeitshilfen. Regulatorischer Schwerpunkt: Humanarzneimittel-GMP.
- ISPE / Karen Ashworth: When Is a Category Not a Category?
- ISPE: GAMP 5 Guide, 2nd Edition – öffentliche Verlagsübersicht
- ISPE Update: GAMP 5 Debuts to a Record Breaking European Audience
- ISPE: Guide for using Open Source Software in Regulated Industries based on GAMP
- Europäische Kommission: EU-GMP Annex 11 – Computerised Systems
- ICH Q9(R1): Quality Risk Management – offizielle EU-Fassung
Zuletzt fachlich geprüft am 06.10.2026.
Daniel Herrmann Consulting
Von der Kategorie zu konkreten Nachweisfragen
Wir unterstützen Sie dabei, Softwarebestandteile, Konfiguration und eigene Erweiterungen nachvollziehbar zu erfassen. Daraus entwickeln wir mit Ihrem Team eine begründete Planung der benötigten Nachweise.
- IT-GxP-Consulting →
Komponenten, Abhängigkeiten und Prüfbedarf für den vorgesehenen Einsatz ausarbeiten.
- IT-GxP-Audit →
Vorhandene Einordnungen und ihre Nachweisgrundlage gezielt bewerten.