GAMP 5 und das V-Modell bilden seit fast zwanzig Jahren das Fundament der Validierung computergestützter Systeme in der Pharmaindustrie. Mit der Second Edition von GAMP 5 (ISPE, Juli 2022) wurde das Modell nicht aufgegeben, sondern flexibler gemacht und mit Critical Thinking, agilen Ansätzen und dem Computer Software Assurance (CSA) der FDA verzahnt. In diesem Praxisleitfaden zeigen wir, wie Sie das V-Modell auf ein reales CSV-Projekt anwenden — vom Validierungsplan bis zur Freigabe — ohne unnötige Dokumentation zu produzieren und mit belastbaren Nachweisen ins Audit zu gehen.
GAMP 5 und V-Modell: was sie sind und warum sie der Standard bleiben
GAMP 5 („A Risk-Based Approach to Compliant GxP Computerized Systems“) ist die maßgebliche ISPE-Leitlinie für die Validierung computergestützter GxP-Systeme. Sie ist kein Gesetz, aber der Rahmen, den Inspektoren von EMA, FDA und PIC/S in der Praxis erwarten — im Einklang mit Annex 11 des EU-GMP-Leitfadens und 21 CFR Part 11.
Das V-Modell ist die grafische Darstellung des Kernprinzips: jede Spezifikation braucht eine zugehörige Verifizierung. Die linke Seite des „V“ führt durch die Spezifikationen nach unten (Nutzeranforderungen/URS, funktionale Spezifikationen, Konfigurations- oder Design-Spezifikationen); die rechte Seite steigt über die Verifizierungen wieder auf (IQ, OQ, PQ oder ihre risikobasierten Äquivalente). Die Spitze ist die Realisierung des Systems. Wird eine Anforderung durch keinen Test verifiziert oder lässt sich ein Test keiner Anforderung zuordnen, ist das „V“ gebrochen — genau das muss eine Traceability Matrix aufdecken, bevor es ein Inspektor tut.
Die GAMP-5-Software-Kategorien: den Aufwand kalibrieren
Das V-Modell wird nicht bei jedem System mit derselben Tiefe angewendet. GAMP 5 teilt Software in Kategorien ein, und die Kategorie bestimmt — zusammen mit dem Risk Assessment —, wie „breit“ das V ist: welche Spezifikationen wirklich nötig sind und wie viel dokumentierte Verifizierung verhältnismäßig ist.
| GAMP-5-Kategorie | Beschreibung | Typischer Validierungsansatz |
|---|---|---|
| Kategorie 1 — Infrastruktur | Betriebssysteme, Datenbanken, Middleware | Qualifizierung der Infrastruktur und Versionskontrolle |
| Kategorie 3 — Nicht konfigurierte Produkte | Kommerzielle Software „as is“ | URS, Installationsprüfung und Tests gegen die Nutzungsanforderungen |
| Kategorie 4 — Konfigurierte Produkte | LIMS, MES, DMS, ERP, auf den Prozess konfiguriert | Vollständiges V-Modell mit Fokus auf Konfiguration und kritische Workflows |
| Kategorie 5 — Individualentwicklungen | Maßgeschneiderter Code (einschließlich komplexer Makros und Tabellenkalkulationen) | Vollständiges V-Modell, erweitert um Design- und Code-Verifizierung |
Die Second Edition empfiehlt, die Kategorien als Ausgangspunkt des Denkens zu nutzen, nicht als bürokratisches Etikett: ein Kategorie-3-System mit direktem Einfluss auf die Chargenfreigabe kann mehr Aufmerksamkeit verdienen als eine risikoarme Kategorie 4.
Wenn Sie in QA, IT oder Validierung arbeiten und wöchentlich pragmatische Ansätze zur GxP-Compliance suchen — von CSV bis Datenintegrität — abonnieren Sie The Pragmatic GMP, den kostenlosen wöchentlichen Newsletter von GuideGxP: jede Woche ein operatives Thema, null Theorie um ihrer selbst willen.
Die linke Seite des V: Planung und Spezifikationen
Alles beginnt mit dem Validierungsplan, der Umfang, Rollen (Business/Process Owner, IT, QA, Lieferant) und Strategie festlegt. Davor setzen zwei Bewertungen den Kurs:
- GxP-Assessment: Beeinflusst das System Produktqualität, Patientensicherheit oder Datenintegrität? Nur wenn ja, fällt das System in den Validierungsumfang.
- Risk Assessment: identifiziert die kritischen Funktionen (Berechnungen, elektronische Signaturen, Audit Trail, Schnittstellen), auf die detaillierte Spezifikationen und strenge Tests konzentriert werden, während risikoarme Funktionen leichtere — auch unscripted — Prüfungen erhalten.
Es folgen die Spezifikationen, angemessen zur Systemkategorie:
- URS (User Requirements Specification): spezifische, messbare, prüfbare Anforderungen. Nehmen Sie immer Datenintegritäts-Anforderungen (Audit Trail, Backup und Restore, Zeitsynchronisation) und Sicherheitsanforderungen (Zugriffsverwaltung, Passwort-Policy) auf: Danach sucht ein Inspektor in der Matrix zuerst.
- Funktionale und Konfigurations-Spezifikationen: beschreiben, wie das System die Anforderungen erfüllt. Bei konfigurierten kommerziellen Produkten dokumentiert die Konfigurationsspezifikation die Prozessentscheidungen; Lieferantendokumentation kann nach einem positiven Supplier Assessment genutzt statt neu geschrieben werden.
Die rechte Seite des V: Verifizierung mit IQ, OQ und PQ
Hier steigt das V wieder auf: Jede Verifizierungsebene beantwortet eine Spezifikationsebene.
- IQ (Installation Qualification): Ist das System wie spezifiziert installiert? Versionen, Komponenten, getrennte Umgebungen (Entwicklung, Test, Produktion), physischer und logischer Schutz der Infrastruktur.
- OQ (Operational Qualification): Arbeiten die Funktionen wie spezifiziert? Jetzt werden kritische Funktionen getestet, Negativtests durchgeführt (fehlerhafte Eingaben, Netzwerkunterbrechungen, unbefugte Zugriffsversuche) und der Audit Trail verifiziert.
- PQ (Performance Qualification): Besteht das System im realen Prozess? Geschulte Anwender, repräsentative Daten, End-to-End-Abläufe: Hier trifft die Validierung auf den Betriebsalltag, oft in Form eines User Acceptance Tests.
GAMP 5 Second Edition legitimiert ausdrücklich gemischte Teststrategien: scripted Tests für Hochrisiko-Funktionen, unscripted und explorative Tests mit schlanker Dokumentation für den Rest. Das Ziel ist der Nachweis der Eignung für den vorgesehenen Gebrauch, nicht der Aktenordner.
Traceability Matrix und Testabweichungen
Die Traceability Matrix verknüpft Anforderung → Spezifikation → Testfall → Ergebnis. Sie ist das Instrument, das in der Inspektion die Abdeckung belegt: Ohne sie können Sie nicht nachweisen, alles getestet zu haben, was Sie als kritisch deklariert haben. Halten Sie sie bei jedem Change Control aktuell, nicht nur bei der Erstvalidierung.
Wenn ein Test fehlschlägt, ist die Versuchung groß, still zu korrigieren und zu wiederholen: ein Fehler. Eröffnen Sie eine Testabweichung, untersuchen Sie die Ursache (Systemfehler, Skriptfehler, Bedienfehler), korrigieren Sie und wiederholen Sie den Test mit vollständiger Dokumentation. Gut gemanagte Abweichungen sind ein Beleg für Prozesskontrolle, keine Schwäche.
Critical Thinking, CSA und die Zukunft des V-Modells
Das regulatorische Umfeld bewegt sich in dieselbe Richtung wie GAMP 5. Im September 2025 hat die FDA die Guidance Computer Software Assurance for Production and Quality System Software finalisiert, die einen risikobasierten Assurance-Ansatz mit risikoproportionalen Tests und weniger Dokumentation um ihrer selbst willen fördert. In Europa stärkt die Revision des EU-GMP-Annex 11 — seit 2025 im Entwurf — die Anforderungen an Datenintegrität, Zugriffsverwaltung und Lieferantenkontrolle. Das V-Modell bleibt das Rückgrat: Die Papiermenge ändert sich, nicht die Logik Spezifikation-Verifizierung.
Häufige Fehler und wie man sie vermeidet
- Nur den Happy Path testen: Planen Sie bei kritischen Funktionen immer Negativtests und Grenzfälle ein.
- URS erst nach der Konfiguration schreiben: Anforderungen als „Fotokopie“ des bereits installierten Systems machen die Validierung zur Kreisübung. Schreiben Sie die URS vorher, auch in schlanker Form.
- Neu schreiben, was der Lieferant schon getestet hat: Nutzen Sie nach positivem Supplier Assessment die Lieferantendokumentation und konzentrieren Sie Ihre Tests auf Konfiguration und Prozess.
- Validieren und vergessen: Ohne Periodic Review und Change Control erodiert der validierte Zustand mit jedem Update.
GuideGxP-Empfehlung
Entwerfen Sie Ihr V nach Maß des Risikos: ein Validierungsplan mit wenigen, aber ehrlichen Seiten zum Umfang, URS mit expliziten Datenintegritäts-Anforderungen, strenge Tests bei hohem und schlanke Tests bei niedrigem Risiko, eine stets aktuelle Traceability Matrix und ein Validierungsbericht, der die Eignung für den vorgesehenen Gebrauch klar erklärt. Im Audit gewinnt, wer erklären kann, warum er getestet hat, was er getestet hat — und warum nicht den Rest.
Wer mit einer fertigen Struktur starten will: Der Operative Leitfaden zur Computer System Validation (CSV) im GxP-Umfeld von GuideGxP enthält 175 operative Seiten sowie Excel- und Word-Vorlagen für Validierungsplan, URS, Risk Assessment, IQ/OQ/PQ-Protokolle und Traceability Matrix — bereits abgestimmt auf GAMP 5 Second Edition und das neue Annex-11/CSA-Umfeld.
