FDA Warning Letters 2026: Sieben Kontrollen für auditfähige Computersysteme

Aktuelle FDA Warning Letters zeigen kein neues Regelwerk, sondern wiederkehrende Kontrolllücken: gemeinsame Logins, überhöhte Berechtigungen, unvollständige elektronische Rohdaten, nicht geprüfte Audit Trails und Änderungen außerhalb des Qualitätssystems. Für Betreiber GxP-relevanter Computersysteme folgt daraus ein klarer Prüfauftrag: technische Kontrollen, Verfahrensregeln und Quality Oversight müssen gemeinsam nachweisbar funktionieren.

Warum diese Warning Letters für europäische GxP-Organisationen relevant sind

Warning Letters richten sich an konkrete Unternehmen und ersetzen weder Gesetz noch Guidance. Sie zeigen aber, wie die FDA bestehende Anforderungen bei realen Inspektionen anwendet. Drei Schreiben aus März und April 2026 sind für IT-Leiter, QA-Verantwortliche und System Owner besonders aufschlussreich:

• Bei Ava Inc. beanstandete die FDA unter anderem ein gemeinsames HPLC-Benutzerkonto, Administratorrechte für Analysten, gelöschte GC-Sequenzen, nicht gespeicherte Trial Injections und Widersprüche zwischen FTIR-Nutzungsprotokoll und elektronischem Audit Trail.
• Bei Intas Pharmaceuticals sollte ein Softwareanbieter auf Anweisung eines QA-Mitarbeiters einen abgeschlossenen elektronischen Batch Record ändern. Die Änderung erschien laut Warning Letter weder im Audit Trail noch im Qualitätssystem.
• Bei Fareva Morton Grove waren mikrobiologische Ergebnisse über Papier und elektronische Einträge verteilt; Daten fehlten, und negative Ergebnisse wurden nicht zeitnah als einzelne Beobachtung dokumentiert.

Die Fälle unterscheiden sich. Das Muster ist gleich: Ein formal vorhandenes System ist nicht automatisch ein kontrolliertes System. Entscheidend ist, ob sich die vollständige Datenhistorie rekonstruieren lässt und ob nur autorisierte, unabhängige Rollen Änderungen vornehmen können.

Kontrolle 1: Individuelle Identitäten statt gemeinsamer Benutzerkonten

Ein gemeinsamer Login zerstört die eindeutige Zuordnung einer Aktion. Wenn mehrere Analysten denselben Benutzernamen und dasselbe Passwort verwenden, kann ein Audit Trail zwar eine Aktivität anzeigen, aber nicht zuverlässig die verantwortliche Person.

Die Mindestkontrolle ist technisch und organisatorisch:

• jedes relevante Benutzerkonto gehört genau einer Person oder eindeutig definierten technischen Identität;
• Rollen und Rechte folgen dem erforderlichen Aufgabenprofil;
• Eintritt, Rollenwechsel und Austritt lösen einen dokumentierten Berechtigungsprozess aus;
• periodische Reviews prüfen nicht nur vorhandene Konten, sondern auch ihre tatsächlichen Privilegien.

Für die Systemvalidierung reicht deshalb ein einmaliger Screenshot der Benutzerverwaltung nicht. Der Nachweis muss zeigen, dass der Berechtigungsprozess im Betrieb funktioniert.

Kontrolle 2: Administratorrechte von der Fachausführung trennen

Bei Ava Inc. konnten Analysten Daten ändern oder löschen, weil sie über Administratorrechte verfügten. Dieses Design verbindet Ausführung, Datenmanipulation und Kontrolle in einer Rolle.

Wo ein technisches System die Trennung unterstützt, sollten Analysten keine produktiven Administratorrechte besitzen. Wo ein Altsystem diese Trennung nicht ermöglicht, braucht es eine dokumentierte Risikobewertung, kompensierende Kontrollen und einen belastbaren Remediation-Plan. Ein Verfahrenssatz wie „Änderungen sind nicht erlaubt“ kompensiert keine technisch offene Löschfunktion.

Prüfbar wird die Kontrolle durch Rollenmatrix, genehmigte Berechtigungsanträge, periodische Access Reviews und eine Stichprobe realer Benutzer gegen die konfigurierte Rolle.

Kontrolle 3: Audit Trails aktivieren, sichern und risikobasiert prüfen

Ein Audit Trail ist nur dann ein Kontrollinstrument, wenn er die kritischen Ereignisse erfasst, vor unautorisierten Änderungen geschützt ist und von einer geeigneten Rolle geprüft wird. Die FDA-Feststellungen zeigen zwei typische Schwächen: Es fehlen Ereignisse, oder vorhandene Ereignisse werden nicht in die Qualitätsentscheidung einbezogen.

Eine belastbare Audit-Trail-Strategie beantwortet mindestens:

1. Welche Daten und Metadaten sind GxP-kritisch?

2. Welche Ereignisse müssen aufgezeichnet werden – einschließlich Anlage, Änderung, Löschung und relevanter Konfigurationsänderung?

3. Wer prüft den Audit Trail unabhängig von der ausführenden Rolle?

4. Zu welchem Zeitpunkt und mit welcher risikobasierten Frequenz erfolgt die Prüfung?

5. Wie werden Auffälligkeiten untersucht, bewertet und abgeschlossen?

21 CFR 211.68(b) verlangt angemessene Kontrollen über Computer- oder verwandte Systeme, damit nur autorisierte Personen Änderungen an Master Production and Control Records oder anderen Records vornehmen. Die Frequenz der Audit-Trail-Prüfung darf risikobasiert sein. Die Begründung darf aber nicht allein auf Systembezeichnung oder Herstellerkategorie beruhen; Intended Use, Datenkritikalität und mögliche Auswirkungen einer unentdeckten Änderung gehören in die Bewertung. Dieselbe Risikologik steht hinter einer risikobasierten Computer Software Assurance, ohne den FDA-CSA-Scope auf pharmazeutische CGMP-Systeme zu erweitern.

Kontrolle 4: Alle Rohdaten und Wiederholungen erhalten

Nicht gespeicherte Trial Injections, verworfene Sequenzen oder nur selektiv übernommene Ergebnisse verhindern eine vollständige Rekonstruktion. 21 CFR 211.194(a) verlangt vollständige Labordaten aus allen erforderlichen Tests. Die FDA betont in ihrer Data-Integrity-Guidance zudem, dass CGMP-Daten vollständig, konsistent und korrekt sein müssen.

Die operative Kontrolle lautet deshalb nicht „nur finale Ergebnisse archivieren“. Sie muss den gesamten entscheidungsrelevanten Datensatz umfassen: elektronische Rohdaten, relevante Metadaten, Methoden-/Sequenzinformationen, Wiederholungen, OOS-/Abweichungsbezug und die Begründung für verworfene oder wiederholte Arbeit.

Ein Systemtest sollte nicht nur zeigen, dass ein Datensatz gespeichert werden kann. Er sollte auch prüfen, was bei Abbruch, Wiederholung, Export, Reprocessing, Löschversuch und Systemfehler geschieht.

Kontrolle 5: Elektronische Daten mit Betriebsnachweisen abgleichen

Im Ava-Schreiben standen Einträge im FTIR-Nutzungslog einem elektronischen Audit Trail ohne entsprechende Aktivität gegenüber. Solche Widersprüche sind ein Signal für eine Lücke in Systemfunktion, Verfahren oder Aufzeichnung.

Ein periodischer Data-Integrity-Review sollte deshalb Quellen nicht isoliert betrachten. Sinnvolle Abgleiche können je nach System umfassen:

• Instrumenten- oder Anwendungslog gegen Audit Trail;
• Batch- oder Probenprotokoll gegen elektronische Rohdaten;
• Schnittstellenmonitoring gegen empfangene Datensätze;
• Helpdesk-/Vendor-Aktivität gegen Change Records;
• Backup-/Restore-Protokolle gegen festgelegte Wiederherstellungstests.

Das Ziel ist keine wahllose Log-Sammlung. Gesucht werden die wenigen Abgleiche, die eine unvollständige oder außerhalb des vorgesehenen Prozesses veränderte Datenhistorie sichtbar machen.

Kontrolle 6: Vendor- und Datenbankänderungen durch Change Control führen

Der Intas-Fall ist für SaaS-, ERP- und eBR-Betreiber zentral: Auch wenn ein Anbieter die technische Änderung ausführt, bleibt der regulierte Betreiber für einen kontrollierten Prozess verantwortlich. Ein Helpdesk-Ticket allein ist kein Quality Change Record.

Vor einer produktiven Änderung müssen mindestens Zweck, betroffene Daten, Genehmigung, technische Ausführung, Audit-Trail-Auswirkung, Verifikation und mögliche Produkt-/Chargenauswirkung geklärt sein. Direkte Datenbankänderungen oder nachträgliche Record-Korrekturen benötigen besonders strenge Trennung, Protokollierung und unabhängige Prüfung.

Diese Logik gehört in Supplier Agreements, Supportverfahren und die Validierungsstrategie – nicht erst in die Reaktion auf ein Finding.

Kontrolle 7: Systemische CAPA statt isolierter Nachschulung

Mehr Training kann sinnvoll sein, beseitigt aber keine ungeeigneten Berechtigungen, fehlende Audit-Trail-Funktionen oder unkontrollierte Datenänderungen. Die FDA verlangte in den genannten Fällen unter anderem unabhängige Bewertungen, umfassende Remediation-Pläne, Ursachenanalysen und Wirksamkeitskontrollen.

Eine systemische CAPA verbindet daher:

• Scope-Ermittlung über vergleichbare Systeme und Standorte;
• technische Korrektur und Verfahrensanpassung;
• Bewertung möglicher Auswirkungen auf bereits freigegebene Daten oder Chargen;
• klare Verantwortlichkeit von Management, QA, Fachbereich und IT;
• definierte Wirksamkeitskriterien mit späterer unabhängiger Prüfung.

Für eine GxP-Audit-Vorbereitung ist das der entscheidende Unterschied zwischen einer Liste geschlossener Tickets und einem belastbaren Remediation-Nachweis.

Ein 30-Tage-Prüfprogramm für System Owner und QA

Die sieben Kontrollen lassen sich ohne pauschales Großprojekt als fokussierter Review starten:

Woche 1: Zwei bis drei kritische Labor-, Produktions- oder Qualitätsanwendungen auswählen. Individuelle Konten, privilegierte Rollen und letzte Access Reviews prüfen.

Woche 2: Für je einen kritischen Prozess die Datenhistorie vom Geschäftsvorgang bis zu Rohdaten, Metadaten und Audit Trail rekonstruieren. Abweichungen dokumentieren.

Woche 3: Vendor-, Helpdesk- und Datenbankänderungen der letzten Monate gegen Change Control und Audit Trail abgleichen.

Woche 4: Findings risikobasiert priorisieren, systemischen Scope festlegen und CAPA einschließlich Wirksamkeitsprüfung genehmigen.

Die CSV-Beratung von DHC verbindet diesen Review mit bestehender Validierungsdokumentation, statt ein paralleles Kontrollsystem aufzubauen.

Häufige Fragen

Muss jeder Audit Trail vor jeder Freigabe vollständig geprüft werden?

Nicht pauschal jeder technische Log. Umfang und Zeitpunkt richten sich nach Datenkritikalität, Intended Use und Prozessrisiko. Für kritische Daten muss die Organisation begründen, welche Audit-Trail-Ereignisse entscheidungsrelevant sind und wann eine unabhängige Prüfung erforderlich ist.

Reicht ein validiertes System als Nachweis für Datenintegrität?

Nein. Validierung belegt die Eignung für den vorgesehenen Einsatz unter definierten Bedingungen. Datenintegrität hängt zusätzlich von Berechtigungen, Betrieb, Review, Change Control, Training und Quality Oversight ab.

Sind Warning Letters unmittelbar auf jedes europäische Pharmaunternehmen anwendbar?

Nein. Ein Warning Letter adressiert den jeweiligen Empfänger und Sachverhalt. Die zugrunde liegenden FDA-Anforderungen und die erkennbaren Kontrollmuster sind jedoch für Organisationen relevant, die FDA-regulierte Produkte herstellen oder ihre Datenintegritätskontrollen gegen reale Inspektionsfeststellungen prüfen wollen.

Primärquellen

• FDA Warning Letter: Ava Inc., 14. April 2026
• FDA Warning Letter: Intas Pharmaceuticals Limited, 30. März 2026
• FDA Warning Letter: Fareva Morton Grove, 3. März 2026
• FDA: Data Integrity and Compliance With Drug CGMP — Questions and Answers
• eCFR: 21 CFR Part 211

---

Autor

Daniel Herrmann Consulting unterstützt Pharma-, Biotech- und MedTech-Unternehmen bei CSV, GxP-Systemvalidierung, Audit Readiness und risikobasierter Remediation.

Sind Berechtigungen, Audit Trails und Datenänderungen in Ihren kritischen Systemen wirklich rekonstruierbar?

In einem fokussierten Readiness-Review priorisieren wir die Lücken, die vor einer Inspektion oder einem Go-Live geschlossen werden müssen.

Audit-Readiness besprechen