Inhaltsverzeichnis
Das Wichtigste vorab
Wie behandelt man Audit Trails und elektronische Signaturen bei einer Migration?
Erhalten Sie den erforderlichen Zusammenhang zwischen Aufzeichnung, Änderungshistorie und Signatur. Historische Ereignisse dürfen nicht als neu ausgeführte Handlungen im Ziel erscheinen. Prüfen Sie, wie Name, Zeitpunkt, Bedeutung und Datensatzbezug weiterhin lesbar und nachvollziehbar bleiben. Ein Importstempel ersetzt weder die ursprüngliche Freigabe noch ihren Kontext.
Einordnung und Geltungsbereich
Die konkrete Pflicht richtet sich nach dem anwendbaren Aufzeichnungs- und Signaturregelwerk. Part 11 wird nur für seinen Geltungsbereich herangezogen. Eine pauschale technische Übertragbarkeit jeder Signaturart wird nicht behauptet.
Historischer Nachweis und neues Importereignis haben verschiedene Aufgaben
Für historische Signaturen ist die Verknüpfung zum tatsächlich unterzeichneten Inhalt wesentlich. Prüfen Sie, ob sich spätere Änderungen von diesem Stand unterscheiden lassen. Wenn die Zielanwendung die ursprüngliche technische Signatur nicht nativ darstellen kann, muss eine geeignete nachweisbare Erhaltungs- und Zugriffslösung bewertet werden.
Audit-Trail-Exporte benötigen ebenfalls Kontext. Ereigniscodes ohne verständliche Bedeutung, fehlende Zeitzonen oder verlorene Objektbezüge können die Historie praktisch unbrauchbar machen. Testen Sie deshalb einen vollständigen Änderungsvorgang und seine spätere Darstellung, statt nur die Existenz einer CSV-Datei festzustellen.
Historische Bedeutung statt bloßer Tabellenübernahme erhalten
Ein Audit-Trail-Ereignis kann erklären, wer einen Datensatz wann und weshalb verändert hat. Eine elektronische Unterschrift kann eine Entscheidung mit einer Person und einem konkreten Record verbinden. Bei Migration muss die benötigte Aussage erhalten bleiben. Das bedeutet nicht automatisch, dass jedes historische Ereignis als native Zielsystemaktion importiert werden kann.
Erfassen Sie Datenmodell und technischen Umfang beider Systeme. Auditfelder, Benutzerkennungen, Zeitzonen und Signaturmodelle können unterschiedlich sein. Eine direkte Feldzuordnung reicht nicht, wenn die Zielanzeige eine andere Bedeutung erzeugt. Die geeignete Lösung kann Migration, ein verknüpftes Archiv oder kontrollierten Quellzugriff kombinieren.
Trennen Sie historische Belege von neuen Entscheidungen. Eine übernommene Unterschrift wird nicht allein durch Import erneut vom früheren Unterzeichner ausgeführt. Ebenso darf eine heutige technische Identität nicht als ursprünglicher Bearbeiter erscheinen. Herkunft und Übernahmebezug müssen angemessen erkennbar bleiben.
Eine Kontextmatrix für Auditdaten und Entscheidungen aufbauen
Beginnen Sie mit konkreten Recherchefragen. Welche Änderung soll später erklärbar sein? Welche Entscheidung benötigt den damaligen Recordstand? Daraus werden erforderliche Felder und Beziehungen abgeleitet. Der Umfang richtet sich nach den anwendbaren Aufzeichnungen und Vorgaben, nicht nach einer universellen Liste für jedes System.
Prüfen Sie auch gelöschte oder deaktivierte Benutzerkennungen. Ein historischer Benutzer kann heute nicht mehr aktiv sein und muss dennoch in seiner damaligen Rolle zugeordnet werden können. Die bloße Ersetzung durch einen aktuellen Systemadministrator kann die Aussage verfälschen. Eine geeignete Referenz- oder Archivlösung sollte diese Geschichte erhalten.
| Kontext | Zu klärende Frage | Eigener Nachweis |
|---|---|---|
| Person | Wer führte Handlung oder Entscheidung tatsächlich aus? | Historische Kennung und geeignete Zuordnung |
| Zeit | Welcher Zeitpunkt und welche Zeitzone gelten? | Nachvollziehbare Darstellung und Transformation |
| Inhalt | Welcher Recordstand wurde verändert oder bestätigt? | Eindeutiger Versions- und Objektbezug |
| Bedeutung | Prüfung, Genehmigung oder andere Handlung? | Erhaltene fachliche Aussage |
| Herkunft | Was ist Originalhistorie, was Migrationsaktion? | Klare Kennzeichnung und Bezug |
Beispiel: historischer Name wird durch Importbenutzer ersetzt
Das Szenario ist konstruiert. Ein QMS exportiert eine frühere Genehmigung durch Benutzer U-8. Im Ziel legt ein Importkonto den Datensatz an. Eine Standardansicht zeigt nun den Importbenutzer als Ersteller. Ohne zusätzlichen historischen Kontext könnte ein Reviewer die Person fälschlich als ursprünglichen Entscheider interpretieren.
Definieren Sie, wie ursprüngliche Entscheidung und heutige Übernahme unterschieden werden. Der historische Beleg kann in einem geeigneten Feld, Dokument oder Archivweg erhalten bleiben. Prüfen Sie die Anzeige aus Sicht des vorgesehenen Reviewers. Eine technisch vorhandene Information ist wenig hilfreich, wenn sie im üblichen Rechercheweg verborgen oder missverständlich bleibt.
Ergänzen Sie einen korrigierten Record und mehrere Entscheidungen zum selben Vorgang. Der Test sollte zeigen, welcher Inhalt zu welcher Entscheidung gehört. Eine Liste von Namen und Zeitpunkten ohne Recordversion kann unzureichend sein. Der gewählte Zielweg wird anhand der vollständigen historischen Frage beurteilt.
| Testfall | Aktion | Erwartete Aussage |
|---|---|---|
| Historische Genehmigung | Ursprünglichen Entscheider recherchieren | Nicht mit Importkonto verwechselt |
| Recordänderung | Vorherigen und späteren Stand öffnen | Auditbezug erklärt die Veränderung |
| Mehrere Entscheidungen | Bestätigungen demselben Vorgang zuordnen | Inhalt und Bedeutung bleiben unterscheidbar |
| Zeitzonenwechsel | Bezeichnetes Zeitereignis vergleichen | Keine ungeklärte chronologische Verschiebung |
| Deaktivierter Benutzer | Frühere Kennung recherchieren | Historische Zuordnung bleibt verfügbar |
Signaturdarstellung und rechtliche Einordnung begrenzen
Eine grafische Namensdarstellung ist nicht automatisch eine elektronisch neu geleistete Unterschrift. Prüfen Sie die benötigte Verbindung zwischen Person, Bedeutung, Zeit und Datensatz. Für Part-11-relevante Anwendungen sind insbesondere Signaturmanifestation und Recordverknüpfung im anwendbaren Rahmen zu betrachten. Annex 11 besitzt ebenfalls Anforderungen an elektronische Signaturen im GMP-Kontext.
Der Migrationsplan sollte erklären, welche Funktion im Ziel aktiv weitergeführt und welche als historische Evidenz erhalten wird. Ein PDF kann Teil eines Belegs sein, bestätigt aber nicht für sich jede technische Signaturanforderung. Eine pauschale Gleichsetzung mit handschriftlichen oder qualifizierten eIDAS-Signaturen wäre ebenfalls unpräzise.
Erhalten Sie erforderliche Originalzusammenhänge, bis der geeignete Zielweg nachgewiesen ist. Die technische Unmöglichkeit eines nativen Imports hebt Aufbewahrungs- oder Nachweisanforderungen nicht auf. Sie verändert die Architekturentscheidung. Benennen Sie Grenzen offen, statt den Export als vollständig gleichwertige Zielsystemfunktion auszugeben.
Prüfauswahl und Akzeptanzkriterien konkret machen
Wählen Sie Fälle mit einfacher Entscheidung, Korrektur, mehreren Versionen und gegebenenfalls deaktivierten Benutzern. Berücksichtigen Sie unterschiedliche historische Formate, soweit sie vorkommen. Eine Prüfung nur neuer, vollständig ausgefüllter Datensätze kann frühere Besonderheiten auslassen.
Legen Sie fest, welche Transformation zulässig ist. Eine einheitliche Zeitzonendarstellung kann geeignet sein, wenn ursprünglicher Bezug und Umrechnung nachvollziehbar bleiben. Eine bloße Löschung der Zeitzoneninformation kann dagegen die Reihenfolge unklar machen. Die Entscheidung sollte Wert und Bedeutung gemeinsam behandeln.
Dokumentieren Sie erwartete historische Aussagen und tatsächliche Rechercheergebnisse. Ein technischer Zeilenzähler reicht nicht. Der Reviewer sollte die Frage anhand des vorgesehenen Zugriffs beantworten können. Ungeklärte kritische Lücken werden vor Abschaltung oder entsprechender Nutzung behandelt.
Zugriff und langfristige Verfügbarkeit erhalten
Ein verknüpftes Archiv muss auch nach Ende des Migrationsprojekts erreichbar bleiben. Prüfen Sie Links, Viewer, Berechtigungen und technische Abhängigkeiten. Eine vorübergehende Exportablage im persönlichen Arbeitsordner ist kein ausreichendes langfristiges Modell, wenn sie die einzige benötigte Historie enthält.
Benennen Sie Verantwortliche für spätere Recherche und Änderungen. Eine neue Archivplattform kann erneut Transformationen auslösen. Erhalten Sie Quell-Ziel-Bezug und geeignete Referenzfälle, damit historische Bedeutung auch bei diesem Wechsel geprüft werden kann. Archivmigration ist ein weiterer Datenlebenszyklusschritt.
Übergeben Sie bekannte Grenzen verständlich. Ein Nutzer sollte erkennen, ob er eine aktuelle Zielsystementscheidung oder einen historischen übernommenen Beleg betrachtet. Diese Klarheit unterstützt sowohl Auditfragen als auch die alltägliche Bearbeitung alter Vorgänge.
Arbeitsvorlage: historische Entscheidung im Ziel oder Archiv rekonstruieren
Wählen Sie einen Record mit früherer Unterschrift und späterer Änderung. Beschreiben Sie die historische Frage: Wer bestätigte welchen Inhalt, mit welcher Bedeutung und zu welchem Zeitpunkt? Prüfen Sie diese Aussage über den vorgesehenen Ziel- oder Archivweg. Ein importierter Name ohne Versionsbezug ist dafür möglicherweise zu wenig.
Trennen Sie die heutige Übernahmeaktion sichtbar von der früheren Entscheidung. Das Importkonto kann den Datensatz technisch anlegen, ist aber nicht der ursprüngliche Unterzeichner. Prüfen Sie die Darstellung aus Sicht eines berechtigten Reviewers. Die Information sollte nicht nur irgendwo gespeichert, sondern im vorgesehenen Rechercheweg verständlich sein.
Wenn eine native Übernahme nicht möglich ist, wird der geeignete alternative Weg bewertet und praktisch geprüft. Eine technische Grenze wird nicht als Wegfall des historischen Bedarfs ausgegeben. Erhalten Sie notwendige Quellzugänge, bis die benötigte Aussage im Zielzustand angemessen nachgewiesen ist.
| Kontextfeld | Konstruierter Eintrag | Akzeptanzfrage |
|---|---|---|
| Record | Bezeichnetes Dokument in früherer Version. | Welcher Inhalt wurde bestätigt? |
| Person | Historische Kennung U-8. | Bleibt sie von Importkonto unterschieden? |
| Bedeutung | Genehmigung im damaligen Verfahren. | Keine neue Handlung vorgetäuscht? |
| Zeit | Ursprünglicher Bezug mit erklärter Zeitzone. | Chronologie verständlich? |
| Änderung | Späterer Recordstand mit eigener Historie. | Frühere und neue Aussage getrennt? |
| Zielweg | Geprüfter Zugriff auf erforderliche Belege. | Nach Abschaltung weiterhin nutzbar? |
Die nächsten Schritte
- Historische Records, Signaturen und erforderliche Ereignisse abgrenzen.
- Darstellung im Ziel und alternative Archivbezüge planen.
- Zusammenhängende Freigabe- und Änderungsfälle prüfen.
- Importnachweis und historischen Nachweis eindeutig unterscheiden.
Häufige Fragen zu Migration: Historie und Signaturen
Müssen alte Ereignisse im nativen Audit Trail des Zielsystems stehen?
Kann man fehlende Signaturen neu nachtragen?
Sind PDF-Ausgaben immer ausreichend?
Müssen historische elektronische Unterschriften im Ziel neu geleistet werden?
Nicht pauschal. Eine neue Unterschrift wäre eine neue Handlung und nicht automatisch der Ersatz einer historischen Entscheidung. Bewerten Sie, welche Aussage und Verbindung erhalten werden müssen und wie der Ziel- oder Archivweg dies nachweist. Herkunft, damaliger Recordstand und heutige Migrationsaktion sollten nicht miteinander verwechselt werden.
Können wir Audit Trails als separate Datei archivieren?
Das kann Teil einer geeigneten Lösung sein, wenn der benötigte Zusammenhang zu Daten, Personen und Zeit erhalten sowie recherchierbar bleibt. Prüfen Sie Format, Zugriff und Vollständigkeit anhand konkreter Fälle. Eine isolierte Datei ohne eindeutige Recordreferenzen oder langfristige Lesbarkeit erfüllt diesen Zweck nicht automatisch.
Warum ist ein historischer Benutzer nicht einfach durch einen aktuellen Namen zu ersetzen?
Dadurch kann die Zuordnung der damaligen Handlung verfälscht werden. Erhalten Sie geeignete historische Referenz und Herkunft. Ein heutiger Benutzer kann für die Migration verantwortlich sein, hat aber nicht automatisch die frühere Entscheidung getroffen. Der Nachweis muss diese Rollen unterscheiden.
Wie prüfen wir einen exportierten Signaturbeleg?
Vergleichen Sie Person, Bedeutung, Zeit und Verbindung zum richtigen Recordstand. Prüfen Sie außerdem benötigten Kontext und späteren Zugriff. Eine grafische Namensdarstellung allein bestätigt nicht jede technische oder regulatorische Signaturanforderung. Die Aussage wird auf den konkreten historischen Nachweiszweck bezogen.
Quellen & fachlicher Stand
Die Quellen bilden den fachlichen Rahmen. Tabellen, Checklisten und ausdrücklich illustrative Beispiele sind eigene methodische Ableitungen, keine wörtlichen Normvorgaben. Herstellerinformationen sind auf die eingesetzte Version und Konfiguration zu beziehen.
- Europäische Kommission: EU-GMP Annex 11, Computerised Systems (2011)§ 4.8 sowie §§ 7, 9, 14 und 17: Übertragung, Historie, Signaturbezug und Archivierung. Geltende Fassung laut EudraLex am 14.10.2026; keine universelle Projekt- oder Fristvorgabe.
- eCFR: 21 CFR Part 11 – Electronic Records; Electronic SignaturesAktueller Regeltext. Anwendbarkeit und ergänzende Aufzeichnungspflichten sind pro Prozess zu prüfen.
- PIC/S: PI 041-1, Good Practices for Data Management and Integrity (2021)Inspektionsleitlinie zur Datenintegrität; insbesondere elektronische Daten, Übertragung, Zugriff und Review.
Zuletzt fachlich geprüft am 14.10.2026.
Daniel Herrmann Consulting
Vom offenen Punkt zu einem nachvollziehbaren Vorgehen.
Wir unterstützen Sie dabei, die Ausgangslage einzuordnen, Verantwortlichkeiten zu klären und passende Nachweise im Betrieb umzusetzen. Welche Unterstützung sinnvoll ist, hängt von Ihrem System, Ihrem Team und dem konkreten Ziel ab.
- IT-GxP-Audit →
Offene Punkte und Prioritäten für Ihren Betrieb einordnen.
- IT-GxP-Consulting →
Vereinbarte Systemprojekte strukturiert umsetzen und übergeben.