Ein Audit-Protokoll für Fachsoftware soll eine betriebliche Entscheidung später verständlich machen. Die Frage lautet beispielsweise nicht nur, ob eine Anfrage erfolgreich war, sondern wer eine Lieferadresse geändert oder eine Freigabe widerrufen hat. Allgemeine Serverlogs enthalten dafür oft zu wenig fachlichen Zusammenhang und manchmal mehr personenbezogene Details, als zur Klärung erforderlich wären.
Stellen Sie sich eine fiktive Serviceanwendung vor, in der ein Auftrag nachträglich einem anderen Team zugeordnet wird. Die neue Zuordnung beeinflusst Termine und Verantwortlichkeit. Im Supportfall muss nachvollziehbar sein, welche Änderung beabsichtigt war und ob davon abhängige Aufgaben tatsächlich angepasst wurden. Eine Zeitangabe allein beantwortet diese Fragen nicht.
Die relevanten Entscheidungen auswählen
Beginnen Sie mit wenigen wichtigen Ereignissen wie Freigabe, Rollenänderung, Datenexport und Korrektur eines abgeschlossenen Vorgangs. Beschreiben Sie für jedes Ereignis, welche betriebliche Frage später beantwortet werden soll. So entsteht ein zweckbezogenes Protokoll statt einer unübersichtlichen Sammlung aller möglichen technischen Aktivitäten.
Notieren Sie die verantwortliche Identität, den betroffenen Vorgang und das Ergebnis. Unterscheiden Sie einen menschlichen Auslöser von einer automatisch ausgeführten Folgeaufgabe. Wenn eine Integration im Auftrag einer Person arbeitet, sollte die Verbindung nachvollziehbar bleiben. Die konkrete technische Umsetzung muss verhindern, dass vom Browser frei mitgelieferte Identitätsangaben ungeprüft als Wahrheit gelten.
Erforderlichen Kontext ohne unnötige Inhalte speichern
Überlegen Sie, ob ein geänderter Feldname und die zugehörige Version ausreichen oder ob bestimmte alte und neue Werte benötigt werden. Für vertrauliche Inhalte können besondere Beschränkungen erforderlich sein. Die Entscheidung über Umfang und Aufbewahrung sollte mit den zuständigen Personen im Unternehmen getroffen und dokumentiert werden.
Zugangsschlüssel, Sitzungstoken und vollständige Dokumentinhalte gehören nicht unüberlegt in eine allgemeine Ereignisansicht. Auch Fehlertexte eines angebundenen Systems können unerwartete Inhalte enthalten. Prüfen Sie deshalb mit repräsentativen Beispielen, was tatsächlich gespeichert und angezeigt wird. Ein Logeintrag ist ein eigener Datenzugriff und keine automatisch unbedenkliche Kopie des ursprünglichen Vorgangs.
Korrekturen und Rechte ausdrücklich gestalten
Legen Sie fest, wer das Protokoll lesen, exportieren oder administrieren darf. Die Person, die einen Auftrag bearbeitet, benötigt nicht zwangsläufig Zugriff auf sämtliche Ereignisse anderer Kunden. Mandantengrenzen und organisatorische Zuständigkeiten gelten auch für die historische Ansicht und ihre heruntergeladenen Dateien.
Ein fachlicher Irrtum sollte durch einen nachvollziehbaren neuen Vorgang korrigiert werden können. Definieren Sie, wie der Zusammenhang zur ursprünglichen Entscheidung sichtbar bleibt. Die Forderung nach einem Audit-Log beschreibt noch keine bestimmte rechtliche Beweiskraft oder Zertifizierung. Solche Anforderungen müssen gegebenenfalls gesondert geprüft und in den konkreten Leistungsumfang aufgenommen werden.
Einen Supportfall als Abnahme verwenden
Ändern Sie in einer Testumgebung die Zuständigkeit eines Auftrags und lösen Sie eine Folgeaufgabe aus. Lassen Sie anschließend eine andere berechtigte Person den Ablauf ausschließlich anhand der vorgesehenen Ansicht erklären. Wiederholen Sie den Versuch mit fehlender Berechtigung und mit einem absichtlich abgewiesenen Änderungsversuch.
Prüfen Sie auch, ob Fehler in der Protokollierung erkannt werden und welche Reaktion vorgesehen ist. Brainbaby Labs kann mit Ihrer Fachabteilung die wichtigsten erklärbaren Entscheidungen eines Produkts auswählen. Bringen Sie einen typischen Klärungsfall mit, damit das Protokoll einen konkreten betrieblichen Nutzen erhält. Daraus entsteht eine überprüfbare Anforderung an Oberfläche, Backend und laufenden Betrieb.