Compliance-Frameworks fordern einen Audit-Trail. Interne Incident-Reviews fordern ihn. Auditoren fordern ihn. Das Auditprotokoll ist die Antwort auf alle drei — direkt im Core ISMS, damit es nie ein Integrationsprojekt wird.
Jede zustandsändernde Aktion auf der Plattform schreibt einen strukturierten Eintrag — Asset angelegt, Risikobehandlung aktualisiert, Control als umgesetzt markiert, Dokument freigegeben, Incident geschlossen, Benutzerrechte geändert. Jeder Eintrag enthält, wer es getan hat, wann, von welcher IP aus, gegen welche Entität, und das Before/After-JSON der Änderung.
- Filterbar. Nach Aktionsnamen (CONTROL_IMPLEMENTED, ASSET_UPDATED, INCIDENT_CLOSED, ...), nach Benutzer, Entität, Instanz, Datumsbereich. Volltext-Suche über Aktion, Entitätstyp, IP, Benutzername, E-Mail und Instanzname.
- Ludwig-Zuordnung. Aktionen, die aus einer Ludwig-Konversation hervorgegangen sind, tragen das Flag
viaLudwigund die ursprüngliche Thread-ID. Filtern Sie auf "nur KI-initiiert", um getrennt zu prüfen, was der Assistent in Ihrem Namen getan hat. - Föderations-bewusst. Aktionen, die über föderierte Installationen ausgelöst wurden, tragen eine
federationActorId, damit der Hub Änderungen dem konkreten Spoke-Benutzer zuordnen kann — nicht nur dem Föderations-Link. - Live-Stream. Ein Server-Sent-Events-Endpunkt erlaubt Dashboards, sich auf neue Einträge zu abonnieren, sobald sie geschehen — Echtzeit-Lageübersicht an arbeitsreichen Tagen.
Im Katalog gelistet, damit das Feature auffindbar bleibt, aber niemals separat berechnet — jede Cybsis-Installation enthält es. Das ist der Boden, den jede regulierte Organisation braucht, und das Fundament, auf dem jede Audit-Kampagne aufbaut. Zusammen mit Benutzeraktivität ergibt sich die per-Benutzer-Beitragsaggregation, die das chronologische Protokoll in Verantwortlichkeitskennzahlen überführt.