Elektronische Signaturen gemäß Annex 11 und Part 11: Was Inspektoren erwarten

Ihr Standort stellt die Überprüfung von Chargenprotokollen, die Genehmigung von Abweichungen oder die Freigabe von SOPs von handschriftlichen auf elektronische Verfahren um – oder hat dies bereits getan, und eine Inspektion steht bevor. In beiden Fällen wird Sie bald jemand bitten nachzuweisen, dass eine elektronische Signatur in Ihrem System dieselbe Bedeutung hat wie früher eine handschriftliche und dass niemand einen Datensatz nach der Unterzeichnung unbemerkt ändern kann. Dieser Artikel erläutert, was EU-GMP-Annex 11 und 21 CFR Part 11 tatsächlich für elektronische Aufzeichnungen und Signaturen verlangen, wie die Datenintegritätsleitlinien der MHRA und PIC/S diese Anforderungen in die Inspektionspraxis übertragen und welche konkreten Nachweise Sie bereithalten sollten.

Zwei Texte, eine Absicht

EU-GMP-Annex 11 (EudraLex Volume 4, Computerised Systems) gilt seit dem 30. Juni 2011. Der Text ist kurz, etwa fünf Seiten, und basiert auf Grundsätzen: Das Risikomanagement bestimmt den Umfang der Validierung und der Datenintegritätskontrollen. Eine wesentlich längere Überarbeitung wurde im Juli 2025 als Entwurf zur Konsultation veröffentlicht, zusammen mit einem überarbeiteten Kapitel 4 und einem neuen Annex 22 zu künstlicher Intelligenz. Bis der endgültige Text verabschiedet ist und in Kraft tritt, werden Sie nach der Fassung von 2011 inspiziert. Der Entwurf gibt jedoch einen guten Hinweis darauf, worauf Inspektoren künftig achten werden.

21 CFR Part 11 ist die US-amerikanische Vorschrift für elektronische Aufzeichnungen und elektronische Signaturen. Sie ist präziser als Annex 11. Wenn Sie den US-Markt beliefern oder von einem US-Partner auditiert werden, werden Sie ihr begegnen. Die beiden Texte stehen nur selten im Widerspruch. Wo Annex 11 das erwartete Ergebnis beschreibt, legt Part 11 häufig genau fest, welche Informationen enthalten sein müssen. Ein System, das für beide Anforderungen ausgelegt ist, erfüllt daher in der Regel beide.

Elektronische Signaturen: Bedeutung, Verknüpfung und Identität

Annex 11, Klausel 14, umfasst nur drei Zeilen. Elektronische Signaturen sollen innerhalb des Unternehmens dieselbe Wirkung wie handschriftliche Signaturen haben, dauerhaft mit dem jeweiligen Datensatz verknüpft sein und Datum und Uhrzeit ihrer Anwendung enthalten. Klausel 15 ergänzt, dass die Chargenzertifizierung in einem System nur durch Sachkundige Personen erfolgen darf und mit einer elektronischen Signatur zu versehen ist.

Part 11 führt die Einzelheiten aus. Abschnitt 11.50 verlangt, dass ein signierter Datensatz den ausgeschriebenen Namen des Unterzeichners, Datum und Uhrzeit der Unterzeichnung sowie die Bedeutung der Signatur enthält, beispielsweise Prüfung, Genehmigung, Verantwortung oder Urheberschaft. Diese Angaben müssen in jeder menschenlesbaren Form des Datensatzes erscheinen, auch in einem Ausdruck oder einer PDF-Datei. Abschnitt 11.70 verlangt, dass Signaturen mit den zugehörigen Datensätzen verknüpft sind, sodass sie nicht herausgelöst, kopiert oder übertragen werden können, um einen anderen Datensatz zu verfälschen. Abschnitt 11.100 verlangt, dass jede Signatur einer einzelnen Person zugeordnet und niemals neu vergeben wird. Abschnitt 11.200 schreibt für Signaturen, die nicht auf biometrischen Daten beruhen, mindestens zwei unterschiedliche Identifikationskomponenten vor, beispielsweise Benutzer-ID und Passwort.

Die GXP-Leitlinie der MHRA zur Datenintegrität (Abschnitt 6.14) äußert sich unmissverständlich zu einer verbreiteten Abkürzung: Ein eingefügtes Signaturbild oder eine Fußnote, die besagt, dass ein Dokument elektronisch signiert wurde, ist nicht ausreichend, sofern die Signatur nicht über den validierten Signaturprozess erstellt wurde. Die Leitlinie bezeichnet sichtbaren Namen, Titel, Datum und Bedeutung als „signature manifestation“ (sichtbare Signaturangaben). PIC/S PI 041-1 ergänzt eine Prüfung, an der die meisten unzureichenden Systeme scheitern: Wird ein signierter Datensatz anschließend geändert, sollte die Signatur ungültig werden, bis der Datensatz erneut geprüft und signiert wurde.

Testen Sie das System daher wie folgt: Signieren Sie den Abschluss einer Abweichung und versuchen Sie anschließend drei Dinge. Bearbeiten Sie ein Feld im signierten Datensatz. Drucken oder exportieren Sie ihn und prüfen Sie, ob die sichtbaren Signaturangaben weiterhin vorhanden sind. Bitten Sie einen Administrator, zu ändern, wer den Datensatz signiert hat. In einem gut konzipierten System wird die Signatur durch den ersten Versuch ungültig oder eine neue Version erzwungen, beim zweiten sind Name, Datum, Uhrzeit und Bedeutung sichtbar, und der dritte Versuch ist unmöglich oder hinterlässt zumindest einen Audit-Trail-Eintrag, in dem der Administrator namentlich genannt wird.

Audit-Trail-Anforderungen in der Praxis

Annex 11, Klausel 9, verlangt, dass das System auf Grundlage einer Risikobewertung alle GMP-relevanten Änderungen und Löschungen aufzeichnet und die Gründe dafür dokumentiert. Audit Trails müssen verfügbar, in eine allgemein verständliche Form konvertierbar und regelmäßig überprüft werden. Part 11, Abschnitt 11.10(e), verlangt sichere, computergenerierte und mit einem Zeitstempel versehene Audit Trails, die Bedienereingaben sowie Aktionen, durch die Datensätze erstellt, geändert oder gelöscht werden, unabhängig aufzeichnen, ohne zuvor aufgezeichnete Informationen unkenntlich zu machen.

Die MHRA-Leitlinie (Abschnitt 6.13) beschreibt den Inhalt als „Wer, Was, Wann und Warum“ jeder Aktion, einschließlich der Zeitzone, soweit relevant. Nutzer sollen den Audit Trail weder ändern noch deaktivieren können. PIC/S PI 041-1, Abschnitt 9.6, geht weiter: Die Audit-Trail-Funktionalität sollte aktiviert und gesperrt sein. Kann ein Administrator sie deaktivieren, sollte diese Handlung selbst automatisch aufgezeichnet werden. Kritische Audit Trails sollten zusammen mit den übrigen Aufzeichnungen eines Vorgangs geprüft werden, bevor dieser abgeschlossen ist, beispielsweise vor der Chargenfreigabe. Nicht kritische Audit Trails können im Rahmen der regelmäßigen Systemüberprüfung geprüft werden.

Bei der Überprüfung erfüllen Standorte die Anforderungen am häufigsten nicht. Niemand erwartet, dass ein Prüfer jedes Anmeldeereignis liest; das stellt die MHRA-Leitlinie ausdrücklich klar. Inspektoren erwarten eine dokumentierte Entscheidung darüber, welche Audit-Trail-Einträge relevant sind, ein Verfahren, das festlegt, wer sie wann prüft, und Aufzeichnungen, die belegen, dass dies geschehen ist. Eine Prüfung nach Ausnahmen ist zulässig: Filtern Sie nach Änderungen an kritischen Feldern, Löschungen, mit großer Verzögerung angewendeten Signaturen oder Änderungen durch Administratoren und dokumentieren Sie Ihre Feststellungen sowie die ergriffenen Maßnahmen.

Ein praktisches Beispiel: Für eine Temperaturabweichung in einem Kühlraum wird eine Abweichung erfasst. Der Untersuchende trägt zunächst 40 Minuten ein und ändert den Wert zwei Tage später auf 25 Minuten. Der Audit Trail sollte beide Werte, die Person, die die Änderung vorgenommen hat, den Zeitpunkt und den Grund („nach Prüfung des Logger-Exports korrigiert“) ausweisen. Der Prüfer, der den Abschluss der Abweichung genehmigt, sollte diese Änderung sehen. Die Aufzeichnung der Audit-Trail-Prüfung sollte belegen, dass sie berücksichtigt wurde. Lautet der Grund „Tippfehler“, während die Logger-Daten 40 Minuten ausweisen, haben Sie selbst einen Datenintegritätsmangel geschaffen.

Zugriffskontrolle

Annex 11, Klausel 12, verlangt physische oder logische Kontrollen, die den Zugriff entsprechend der Kritikalität des Systems auf autorisierte Personen beschränken; Aufzeichnungen über die Erstellung, Änderung und Aufhebung von Zugriffsberechtigungen; sowie Systeme, die die Identität aller Personen erfassen, die Daten eingeben, ändern, bestätigen oder löschen, einschließlich Datum und Uhrzeit. Part 11, Abschnitte 11.10(d) und (g), verlangen, dass der Zugriff auf autorisierte Personen beschränkt ist und geprüft wird, wer Datensätze signieren oder ändern beziehungsweise Vorgänge ausführen darf.

Die MHRA-Leitlinie stellt ausdrücklich klar, dass gemeinsam genutzte Anmeldedaten und generische Nutzerzugänge nicht für GxP-Daten verwendet werden sollten, selbst wenn individuelle Konten zusätzliche Lizenzen kosten. Der Zugriff als Systemadministrator sollte auf möglichst wenige Personen beschränkt sein. Administratorrechte sollten nicht an Personen vergeben werden, die ein direktes Interesse an den Daten haben, etwa an einen Analysten, dessen Ergebnisse sich im System befinden. PIC/S ergänzt, dass das System alle Nutzer samt ihren Rollen auflisten können sollte und dass diese Liste bei regelmäßigen Überprüfungen der Nutzerzugriffe herangezogen werden sollte.

In einem kleinen Unternehmen wird es an dieser Stelle oft unangenehm. Der QA-Manager ist häufig zugleich Systemadministrator. Ist das unvermeidbar, dokumentieren Sie die Risikobewertung, führen Sie ein separates, namentlich zugeordnetes Administratorkonto, das ausschließlich für administrative Aufgaben verwendet wird, und lassen Sie den Audit Trail dieses Kontos von einer anderen Person prüfen.

ALCOA+ als praktische Checkliste

Sowohl die MHRA-Leitlinie (Abschnitt 3.10) als auch PIC/S PI 041-1 verwenden ALCOA+: Attributable (zuordenbar), Legible (lesbar), Contemporaneous (zeitnah), Original (Original) und Accurate (richtig) sowie Complete (vollständig), Consistent (konsistent), Enduring (dauerhaft) und Available (verfügbar). Die MHRA weist darauf hin, dass die Erwartungen unabhängig davon gleich bleiben, welches Akronym verwendet wird. Die Checkliste wird nützlich, wenn Sie sie jeweils auf einen Datensatztyp anwenden.

Wenden Sie diese Tabelle auf Ihre Abweichungs-, CAPA-, Änderungskontroll- und Schulungsaufzeichnungen an. Damit haben Sie das Grundgerüst einer Risikobewertung zur Datenintegrität.

Regelmäßige Überprüfung

Annex 11, Klausel 11, verlangt, dass computergestützte Systeme regelmäßig bewertet werden, um zu bestätigen, dass sie weiterhin validiert und GMP-konform sind. Die Bewertung sollte gegebenenfalls die aktuelle Funktionalität, Abweichungsaufzeichnungen, Vorfälle, Probleme, Upgrade-Historie, Leistung, Zuverlässigkeit, Sicherheit und den Validierungsstatus abdecken. PIC/S PI 041-1 verlangt, dass die Häufigkeit risikobasiert festgelegt wird und die kumulativen Auswirkungen von Änderungen seit der letzten Überprüfung berücksichtigt werden.

Bei einem cloudbasierten eQMS, das mehrere Releases pro Jahr erhält, ist dieser kumulative Aspekt wichtig. Jedes Release kann seine eigene Auswirkungsbewertung bestanden haben, doch die Änderungen eines ganzen Jahres können beeinflussen, wie Genehmigungen weitergeleitet oder welche Informationen im Audit Trail erfasst werden. Bei einer sinnvollen jährlichen Überprüfung vergleichen Sie das validierte System mit dem heute laufenden System, prüfen die Nutzerzugriffe erneut, ziehen Stichproben aus den Aufzeichnungen der Audit-Trail-Prüfungen, bestätigen, dass eine Wiederherstellung aus der Datensicherung getestet wurde (Annex 11, Klausel 7.2), und halten abschließend eine signierte Schlussfolgerung fest: weiterhin validierter Zustand oder nicht, jeweils mit Maßnahmen.

Was Inspektoren sehen möchten

Inspektoren werden Sie in der Regel bitten, das System live vorzuführen, statt ihnen einen Aktenordner zu zeigen. Rechnen Sie mit Anfragen wie diesen:

1. Das Inventar der computergestützten Systeme und ihrer GMP-Funktionen (Annex 11, Klausel 4.3).
2. Die Validierungszusammenfassung für das betreffende System und die Zuordnung der Nutzeranforderungen zu den Tests.
3. Einen signierten Datensatz und anschließend eine Demonstration, was geschieht, wenn jemand versucht, ihn zu ändern.
4. Den Audit Trail eines von ihnen ausgewählten Datensatzes sowie die Aufzeichnung seiner Prüfung.
5. Die aktuelle Nutzerliste mit Rollen und die letzte regelmäßige Überprüfung der Zugriffsrechte.
6. Die Vereinbarung mit dem Systemanbieter und Ihre Bewertung des Anbieters (Annex 11, Klausel 3).
7. Den Bericht der letzten regelmäßigen Überprüfung und den Nachweis einer getesteten Wiederherstellung aus der Datensicherung.
8. Bei Aufzeichnungen zur Chargenfreigabe einen Ausdruck, aus dem hervorgeht, ob Daten nach der ursprünglichen Eingabe geändert wurden (Annex 11, Klausel 8.2).

Üben Sie das. Lassen Sie die Person, die die Demonstration durchführen wird, sie anhand eines Testdatensatzes proben. Eine unabhängige Kollegin oder ein unabhängiger Kollege übernimmt dabei die Rolle des Inspektors und wählt den Datensatz aus.

Fazit

Annex 11 und Part 11 verlangen dasselbe, wenn auch mit unterschiedlichen Worten: Eine Signatur muss eine Person identifizieren, ihre Bedeutung angeben, genau mit dem signierten Datensatz verknüpft bleiben und auch beim Ausdruck erhalten bleiben. Ein Audit Trail muss zeigen, wer wann was und warum geändert hat, und jemand muss ihn prüfen. Wählen Sie diese Woche drei Datensatztypen aus, wenden Sie die ALCOA+-Tabelle und die Signaturtests auf sie an und beheben Sie alle Mängel, bevor ein Inspektor sie entdeckt.

Wenn Sie diese Tests mit einem System durchführen möchten, das für regulierte Hersteller entwickelt wurde: InnoQualis ist ein in der EU gehostetes eQMS mit einem nur erweiterbaren Audit Trail und elektronischen Signaturen, die 21 CFR Part 11 und EU-GMP-Annex 11 unterstützen sollen.