Validierung des WMS im GDP-Umfeld: Data Integrity und Audit Trail für die Responsible Person

Validierung des WMS im GDP-Umfeld: Data Integrity und Audit Trail – was der Inspektor wirklich verlangt

Wenn man Sie in einer Inspektion fragt: „Wer hat das Verfallsdatum dieser Charge geändert und warum?“, dann testet man nicht den Lageristen. Man testet Ihr System.

Und genau hier liegt der Punkt: Heute entscheidet sich Compliance im GDP-Umfeld nicht mehr nur an Kühlzellen und Lieferscheinen, sondern an elektronischen Aufzeichnungen, Audit Trails und IT-Governance.

In 30 Sekunden

Ein WMS ist nicht deshalb „GDP-compliant“, weil es funktioniert. Es ist GDP-compliant, wenn es nachweisen kann, was passiert ist, wer es getan hat und wann.
Die CSV (Computer System Validation) in der Logistik scheitert fast immer an denselben Punkten: schwache URS, oberflächliche Tests, zu weit gefasste Zugriffsrechte, Audit Trail vorhanden – aber nie überprüft.
Der gefährliche Mythos lautet: „Wir drucken ein PDF aus und dann passt das schon.“
Spoiler: nein.

Das Vokabular, das in Findings auftaucht (LSI „aus Inspektorensicht“)

Im digitalen GDP-Umfeld sollten Sie darauf vorbereitet sein, folgende Begriffe zu hören – und belegen zu können:

CSV, URS, Traceability Matrix, IQ/OQ/PQ, GAMP 5, EU Annex 11, 21 CFR Part 11, ALCOA+, Audit Trail Review, RBAC (Role-Based Access Control), Segregation of Duties, Change Impact Assessment, Backup/Restore Test, Disaster Recovery.

Welche WMS-Daten wirklich „GDP-kritisch“ sind

Im Audit lautet die implizite Frage fast immer:
„Wenn diese Information falsch oder manipuliert wäre – könnte ich dann die Rückverfolgbarkeit verlieren oder nicht geeignetes Produkt freigeben?“

Tabelle: kritische Daten und erwartete Kontrollen

Aus Produktionssicht wird ein WMS oft als „außerhalb des GMP-Bereichs“ betrachtet. In GDP-Inspektionen wird es jedoch zu einem Qualitätssystem: Wenn es nicht beherrscht wird, bleibt der Responsible Person der objektive Nachweis verwehrt.

CSV im GDP-Umfeld: wie man sie macht, ohne eine „Papiermaché-Validierung“ zu bauen

Im Audit sehe ich am häufigsten folgendes Problem: Unternehmen mit einem schönen „Validation Report“, aber ohne Risikologik, ohne Rückverfolgbarkeit von Anforderungen zu Tests und mit Tests, die die echten Failure Modes gar nicht abdecken.

Ein praktischer Ansatz, der in der Inspektion standhält

1) GxP-Scoping & Risk Assessment

Identifizieren Sie Funktionen mit GxP-Impact, zum Beispiel:

• Sperrung von Verfallsdaten
• Quarantäne
• Rückverfolgbarkeit
• Serial Integration

Klassifizieren Sie das System nach GAMP-5-Logik: konfiguriert, kundenspezifisch, SaaS?

2) Robuste URS formulieren – nicht „das System soll funktionieren“

Beispiel für eine brauchbare URS:

„Das System muss den Versand von Chargen verhindern, deren Verfallsdatum vor dem Versanddatum liegt, und das Ereignis im Audit Trail protokollieren.“

3) Traceability Matrix

Jede URS muss in Testfälle überführt werden. Fehlt diese Verknüpfung, ist das im Audit eine Lücke.

4) IQ/OQ/PQ-Testing – mit „schmutzigen“ Fällen

• IQ: Installation / Umgebung
• OQ: Funktionen und Kontrollen (Rollen, Sperren, Audit Trail, Zeitstempel)
• PQ: reale Prozesse (Wareneingang → Einlagerung → Picking → Versand → Rework)

5) Data Migration & Master Data Governance

Wenn Sie Stammdaten, Produkte oder Verfallsdaten importieren, brauchen Sie Nachweise, dass die Daten nicht „verschmutzt“ wurden.

Hier entstehen typische Vorfälle wie:
falsch interpretierte Maßeinheit (Box vs. Pack) → fehlerhafte Auslieferungen.

6) Go-Live mit „Quality Gate“

Nicht die IT allein entscheidet. Der Go-Live muss ein Qualitäts-Gate mit geschlossenen Mindestnachweisen haben.

Merksatz

Ein WMS ist nicht deshalb validiert, weil der Anbieter sagt, dass es validiert ist.
Es ist validiert, wenn Sie nachweisen können, dass Konfiguration und Nutzung in Ihrem GDP-Prozess unter Kontrolle sind.

Audit Trail: Aktivieren reicht nicht – er muss auch überprüft werden

Contrarian insight (verbreiteter Mythos):
„Wir aktivieren den Audit Trail – und wenn nötig, schauen wir ihn uns später an.“

Das ist eine veraltete Praxis, weil sie:

• den Audit Trail zu einem reaktiven statt zu einem präventiven Kontrollinstrument macht,
• Tür und Tor für Data-Integrity-Drift öffnet, also für wiederkehrende Fehler oder opportunistisches Verhalten.

Was „Audit Trail Review“ in der Praxis bedeutet

Definieren Sie zunächst kritische Felder:

• Verfallsdatum
• Charge
• Status
• Mengenanpassungen
• Override von Sperren

Definieren Sie dann eine risikobasierte Frequenz:

• monatlich auf Stichprobenbasis,
• quartalsweise für Trends,
• ad hoc bei Ereignissen.

Suchen Sie gezielt nach typischen Mustern:

• wiederholte Änderungen an Verfallsdaten,
• ungewöhnliche Löschungen oder Overrides,
• Aktivitäten „außerhalb der Arbeitszeiten“ ohne Begründung,
• übermäßige Nutzung von Admin-Profilen.

Im Audit lautet die Killerfrage:
„Können Sie mir belegen, dass der Audit Trail überprüft wird, bevor ein Problem zu einem Recall wird?“

Zugriffe, Rollen und Segregation: hier scheitern auch gute Unternehmen

Das häufigste Problem, das ich in Audits sehe, ist ein gemeinsamer Account auf Handheld-Geräten wie „MAGAZZINO1“ oder übermächtige Profile „aus Bequemlichkeit“.

Maßnahmen, die wirklich funktionieren

• RBAC: minimale notwendige Rollen
  Picking ≠ Master Data ≠ Release/Quarantäne
• Joiner–Mover–Leaver-Prozess: für Erstellen, Ändern und Deaktivieren von Zugängen
• Regelmäßige User Access Review: mindestens jährlich, besser halbjährlich bei kritischen Rollen
• MFA, wo möglich, insbesondere bei Remote Access und Admin-Rollen
• Segregation of Duties: wer Stammdaten anlegt oder ändert, sollte Ausnahmen nicht selbst genehmigen

Patches und Upgrades: wenn die IT „verbessert“ und GDP verschlechtert

Ein System zu aktualisieren ist normal. Es ohne Kontrolle zu tun, ist ein GDP-Risiko.

Praktische Checkliste

• Jede Patch-/Upgrade-Maßnahme durchläuft ein Change Impact Assessment
• Es gibt eine getrennte TEST-Umgebung
• Sie führen Regressionstests für GDP-kritische Prozesse durch
• Ergebnis und Freigabe werden dokumentiert
• Bei SaaS: Lieferantenqualifizierung + Nachweis von Release Notes und Impact-Bewertung

Aus IT-Sicht ist ein Software-Change oft „Routine“.
Aus GDP-Sicht kann er die Ursache sein für:

• nicht mehr funktionierende Verfallsdatums-Sperren,
• degradierten Audit Trail,
• nicht reproduzierbare Rückverfolgbarkeitsberichte.

Merkkasten

• CSV im GDP-Umfeld = Prozess + Evidenz, nicht ein PDF im Shared Folder
• Audit Trail = aktiv + geschützt + überprüft
• Die 3 größten Audit-Killer: Zugriffsrechte, fehlende Review, ungesteuerte IT-Changes
• Wenn Sie Data Integrity verlieren, verlieren Sie auch die Fähigkeit zu einem wirksamen Recall

FAQ

Ist 21 CFR Part 11 in einem EU-Unternehmen erforderlich?

Nicht immer als direkte gesetzliche Pflicht. Die zugrunde liegenden Konzepte – Audit Trail, elektronische Signaturen, Zugriffskontrollen – werden jedoch häufig als Best Practice erwartet, wenn GxP-relevante elektronische Aufzeichnungen geführt werden.

Welche Systeme muss ich im GDP-Umfeld validieren?

Alle Systeme, die Rückverfolgbarkeit, Bestandsstatus, Verfallsdaten, Temperatur, Serialisierung und Recall-Reporting beeinflussen. Typischerweise also:

• WMS / ERP
• Temperaturüberwachungssysteme
• Serialisierungs-Module
• Bestellschnittstellen

Wie oft sollte eine Audit Trail Review durchgeführt werden?

Der beste Ansatz ist risikobasiert: monatlich auf Stichprobenbasis für kritische Felder, häufiger, wenn viele Ausnahmen auftreten.