Audit Trail: Definition, Anforderungen und MES-Praxis

Was ist ein Audit Trail?

Ein Audit Trail (deutsch: Prüfpfad) ist eine chronologische, manipulationssichere Aufzeichnung aller Aktivitäten, Änderungen und Entscheidungen innerhalb eines IT-Systems. Er dokumentiert, wer wann was geändert hat und warum. Im Kontext der Fertigung betrifft das alle Systeme, die Produktionsdaten verarbeiten: MES, ERP, Qualitätsmanagementsysteme, SCADA und Prozessdatenarchive.

Der Audit Trail ist kein optionales Feature. In regulierten Branchen (Pharma, Medizintechnik, Lebensmittel) ist er eine gesetzliche Pflicht. In der Automobilindustrie ist er eine Kundenanforderung. Und in jeder datengetriebenen Fertigung ist er die Grundlage dafür, dass Kennzahlen wie die OEE vertrauenswürdig sind.

Ohne Audit Trail sind digitale Daten im Ernstfall nicht beweisbar. Wenn ein Stillstand nachträglich umklassifiziert wird, ein Prozessparameter geändert wird oder ein Qualitätsmerkmal korrigiert wird, muss nachvollziehbar sein: Wer hat das getan? Wann? Was war der vorherige Wert? Und warum wurde die Änderung vorgenommen? Fehlt diese Nachvollziehbarkeit, öffnet sich die Tür für Datenkosmetik, für geschönte OEE-Werte, für nicht nachweisbare Qualitätseingriffe und für Audit-Befunde, die das gesamte Qualitätssystem in Frage stellen.

Die 4 Säulen eines Audit Trails

Ein normgerechter Audit Trail (gemäß FDA 21 CFR Part 11, EU GMP Annex 11 oder IATF 16949) muss vier Kernfragen beantworten:

Regulatorische Anforderungen nach Branche

Die Anforderungen an den Audit Trail variieren je nach Branche und Regulierung:

Audit Trail im MES: Typische Anwendungsfälle

Im Kontext eines MES gibt es konkrete Stellen, an denen der Audit Trail greift:

Audit Trail vs. System-Log vs. Traceability

Die drei Begriffe werden oft verwechselt, beschreiben aber unterschiedliche Dinge:

Ein System-Log ist kein Ersatz für einen fachlichen Audit Trail. Und Traceability ist kein Audit Trail, sondern eine Produkthistorie. In der Praxis braucht ein gut aufgestelltes MES alle drei: den Audit Trail für die Nachvollziehbarkeit von Datenänderungen, das System-Log für die IT-Betriebsüberwachung und die Traceability für die Produktrückverfolgung.

Wie SYMESTIC Datenintegrität sicherstellt

Die SYMESTIC Cloud-MES-Plattform ist auf Microsoft Azure aufgebaut, cloud-native, mit Microservice-Architektur. Die Architekturentscheidungen, die für Audit-Trail-Fähigkeit relevant sind:

Individuelle Benutzerkonten: "Unbegrenzte Anzahl Benutzer" in allen Lizenzstufen. Keine Sammel-Accounts nötig. Im Enterprise-Tier: Anbindung an Azure Active Directory. Jede Aktion im System ist einem eindeutigen Benutzer zugeordnet.

Zeitstempel vom Server: Alle Zeitstempel werden serverseitig gesetzt (Azure-Infrastruktur mit NTP-Synchronisation). Clientseitige Zeitmanipulation ist nicht möglich. Die Serverzeit ist die einzige Wahrheit.

Datenaufbewahrung: 12 Monate im Professional-Tier. Im Enterprise-Tier: "Nach regulatorischen Abhängigkeiten" konfigurierbar. GMP-Kunden (wie Klocke) benötigen oft längere Aufbewahrungsfristen.

Traceability: "Active Traceability" mit Request/Release-Control, Quality-Status-Data, Process-Data, PokaYoke. Jedes Teil hat eine lückenlose Produktionshistorie. Bei Neoperl werden SPS-Alarme mit Stillständen und Qualitätsdefekten korreliert. Die gesamte Kette ist nachvollziehbar.

Klocke (Pharma, GMP-Umfeld): SYMESTIC wird bei Klocke im regulierten Umfeld nach GMP eingesetzt. 7 h mehr Produktionszeit pro Woche, 12 % Verbesserung der Ausbringung, 8 % Verbesserung der Verfügbarkeit. Im GMP-Umfeld ist ein funktionierender Audit Trail keine Option, sondern eine Zulassungsvoraussetzung.

Typische Fehler beim Audit Trail

Fehler 1: Sammel-Accounts verwenden. "Schichtleiter-Login" oder "Werker-1" sind keine individuellen Benutzerkonten. Wenn drei Personen denselben Account nutzen, ist die "Wer"-Säule des Audit Trails wertlos. Jeder Benutzer braucht ein eigenes Konto. In einem Cloud-MES mit unbegrenzten Benutzern gibt es keinen Grund für geteilte Accounts.

Fehler 2: Audit Trail aufzeichnen, aber nie auswerten. Viele Systeme zeichnen Änderungen auf, aber niemand schaut sich die Aufzeichnungen an. EU GMP Annex 11 fordert explizit "Audit Trail Reviews" als Teil der Datenintegritätsprüfung. Das bedeutet: Regelmäßig prüfen, ob kritische Daten geändert wurden und ob die Begründungen plausibel sind.

Fehler 3: System-Log mit Audit Trail verwechseln. Ein System-Log zeigt, dass der Server um 03:14 Uhr neu gestartet wurde. Ein Audit Trail zeigt, dass Benutzer "M. Schmidt" um 14:23 Uhr den Stillstandsgrund von "Technische Störung" auf "Geplante Wartung" geändert hat, mit Begründung "Korrektur: War im Wartungsplan vorgesehen." Beides ist nützlich. Beides ist nicht dasselbe.

Fehler 4: Audit Trail nur für regulierte Branchen halten. Auch ohne GMP oder IATF: Wer OEE-basierte Entscheidungen trifft, braucht vertrauenswürdige Daten. Wenn ein Schichtleiter Stillstände nachträglich umklassifizieren kann, ohne dass es jemand sieht, ist die OEE eine Meinung, keine Kennzahl. Der Audit Trail schützt nicht nur vor dem Auditor, sondern vor der eigenen Datenkosmetik.

Fehler 5: Originalwerte überschreiben statt versionieren. Ein Audit Trail funktioniert nur, wenn der alte Wert erhalten bleibt. Wenn ein Feld einfach überschrieben wird, gibt es nichts zum Nachvollziehen. Die Architektur muss Versionierung erzwingen: Jede Änderung erzeugt einen neuen Datensatz, der alte bleibt als "vorherige Version" gespeichert.

Häufige Fragen zum Audit Trail

Was ist der Unterschied zwischen Audit Trail und Traceability?

Ein Audit Trail dokumentiert Änderungen an Daten: Wer hat wann was geändert und warum? Traceability dokumentiert die Produkthistorie: Welche Materialien, Prozesse und Prüfungen hat ein bestimmtes Teil durchlaufen? Beide sind komplementär. Der Audit Trail schützt die Integrität der Daten. Die Traceability nutzt diese Daten, um Produkte rückzuverfolgen.

Brauche ich einen Audit Trail, wenn ich nicht in einer regulierten Branche bin?

Keine gesetzliche Pflicht, aber eine starke Empfehlung. Sobald Produktionsdaten die Grundlage für Entscheidungen sind (OEE-Verbesserung, Stillstandsanalyse, Kapazitätsplanung), muss die Integrität dieser Daten gewährleistet sein. Ohne Audit Trail kann niemand nachweisen, dass die OEE-Verbesserung des letzten Quartals auf echten Verbesserungen basiert und nicht auf einer Umklassifizierung von Stillständen.

Wie verhindert ein Cloud-MES Datenmanipulation?

Durch serverseitige Zeitstempel (nicht manipulierbar durch den Client), individuelle Benutzerkonten (Azure Active Directory), Versionierung statt Überschreiben und rollenbasierte Zugriffssteuerung. In einer Cloud-Architektur liegt die Datenhoheit auf dem Server, nicht auf dem lokalen Rechner des Benutzers. Das macht Manipulation technisch schwieriger als in einer On-Premise-Umgebung, wo der lokale Administrator theoretisch Datenbankzugriff hat.

Was passiert bei einem Audit, wenn kein Audit Trail vorhanden ist?

In regulierten Branchen (Pharma, Lebensmittel): Major Finding. Kann zur Produktionssperre, zum Rückruf oder zum Verlust der Zulassung führen. In der Automobilindustrie: OEM-Reklamation, Lieferantenbewertung sinkt, im Extremfall Sperrung als Lieferant. Ohne Regulierung: Interne Glaubwürdigkeit der Daten sinkt. Kennzahlen werden angezweifelt. Verbesserungsinitiativen verlieren ihre Basis.

Welche Daten brauchen zwingend einen Audit Trail?

Mindestens: Qualitäts- und Prozessdaten (Messwerte, Prüfergebnisse, Freigaben), Stillstandsklassifizierungen und deren Änderungen, Konfigurationsänderungen (Soll-Taktzeiten, Grenzwerte, Schichtmodelle), Benutzer- und Rechteverwaltung (wer hat welche Rolle erhalten oder verloren), Rezepturen und Arbeitspläne. Im GMP-Umfeld: Alle GxP-relevanten Daten ohne Ausnahme.

Über den Autor:

Mark Kobbert

CTO der symestic GmbH. Verantwortet die Cloud-MES-Architektur seit 2014. B.Sc. Wirtschaftsinformatik.
LinkedIn