SMILEdataguard: Warum prüfbare ITSM-Historie vor der nächsten Prüfung beginnen muss

ITSM-Systeme verändern sich ständig. Tickets werden aktualisiert, CIs bekommen neue Attribute, Beziehungen zwischen Systemen ändern sich, Daten werden bereinigt oder gelöscht. Für den laufenden Betrieb ist das normal. Für Revision, Compliance und spätere Nachweise entsteht daraus aber eine unangenehme Frage: Was galt zu einem bestimmten Zeitpunkt wirklich — und lässt sich das heute noch beweisen?

Die wichtigste Antwort ist unbequem: Die Beweiskette beginnt ab dem Anschlusszeitpunkt. Was vorher nicht archiviert wurde, lässt sich später nicht vollständig nachweisen. Jeder Monat ohne Archivierung ist ein Monat, der bei der nächsten Prüfung, DORA-Meldung oder Systemablösung unbelegbar bleiben kann.

Die neue Version von SMILEdataguard setzt genau dort an. Sie versteht sich nicht mehr nur als technische Absicherung einzelner Änderungen, sondern als prüfbares Archiv für ITSM-, CMDB- und Fremdsystemdaten. Jede Version bleibt erhalten, Löschungen werden als Ereignis dokumentiert, Bestände lassen sich zu einem Stichtag rekonstruieren und Exporte können unabhängig geprüft werden.

Warum ein normales Archiv nicht reicht

Viele Systeme können Historien speichern. Das beantwortet aber nur einen Teil der Audit-Frage. Entscheidend ist nicht nur, ob eine Historie vorhanden ist, sondern ob sie nachträglich verändert worden sein könnte.

SMILEdataguard trennt deshalb zwei Dinge sauber voneinander: die fachliche Historie und den technischen Nachweis. Die fachliche Historie zeigt, welches Objekt wann welchen Zustand hatte. Der technische Nachweis zeigt, ob diese Historie seit der Archivierung unverändert geblieben ist.

Dafür nutzt SMILEdataguard Hash-Ketten je Objekt, Merkle-Bäume und signierte Anker. Wird ein archivierter Datensatz später verändert, entfernt oder ersetzt, bricht die Beweiskette an einer nachvollziehbaren Stelle. Ein Finding sagt also nicht nur allgemein, dass etwas nicht stimmt, sondern wo der Widerspruch liegt.

Bestand zum Zeitpunkt: Zeitreise für die CMDB

Ein zentraler Use Case ist die Rekonstruktion eines Bestands zu einem bestimmten Zeitpunkt. Wer etwa wissen muss, welche Server, Anwendungen oder Beziehungen am 1. Juli um 12:00 Uhr gültig waren, kann diesen Stand aus dem Archiv erzeugen — ohne das Quellsystem erneut zu befragen.

Das ist besonders wertvoll, wenn Quellsysteme abgelöst werden, Daten später bereinigt wurden oder eine Prüfung nachträglich einen alten Zustand nachvollziehen muss. SMILEdataguard kennzeichnet dabei ehrlich, ab wann ein Bestand nachweislich vollständig ist. Das ist wichtig: Ein Archiv sollte keine Sicherheit vortäuschen, die es nicht belegen kann.

Datenschutz ohne zerstörte Integrität

Integritätsnachweis und Datenschutz wirken auf den ersten Blick widersprüchlich. Ein Archiv soll unverändert prüfbar bleiben, die DSGVO kennt aber Lösch- und Schutzpflichten für personenbezogene Daten.

Die neue Version löst diesen Konflikt über Pseudonymisierung, Verschlüsselung und Crypto-Shredding. Personenbezüge können vor dem Hashen geschützt werden. Wenn ein personenbezogener Schlüssel später nach Art. 17 gelöscht werden muss, werden die betroffenen Werte dauerhaft unlesbar, ohne die Integrität des Archivs zu brechen.

Auch diese Vorgänge sind governance-tauglich umgesetzt: sensible Änderungen laufen über Vier-Augen-Anträge, Entscheidungen werden protokolliert und Pseudonym-Auflösungen landen nachvollziehbar im Audit-Log.

Compliance-Baselines und signierte Prüfberichte

Neben der Historie einzelner Objekte unterstützt SMILEdataguard auch die Prüfung gegen Soll-Zustände. Compliance-Baselines beschreiben je Objekttyp, welche Attribute, Werte und Beziehungen erwartet werden. Diese Regeln sind selbst versioniert und lassen sich gegen den aktuellen oder historischen Bestand prüfen.

Für Audits entstehen daraus belastbare Berichte: Was wurde geprüft? Gegen welche Baseline-Version? Welche Objekte waren konform, welche nicht, und warum? Prüfberichte und Exporte können signiert ausgegeben und offline verifiziert werden.

Offener für Fremdsysteme

SMILEdataguard bleibt für ITSM- und CMDB-Szenarien gemacht, wird aber offener für andere Quellen. Über den generischen REST-Connector können Systeme angebunden werden, die einen Änderungsfeed, Einzelobjekt-Endpunkte und Bestandslisten bereitstellen.

Damit wird SMILEdataguard auch für Umgebungen interessant, in denen nicht alle relevanten Daten in einem einzigen ITSM-System liegen. Entscheidend ist: Die Beweiskette beginnt ab dem Anschlusszeitpunkt und macht die weitere Historie nachvollziehbar.

Für wen die neue Version besonders relevant ist

Für IT-Revisoren liefert SMILEdataguard prüfbare Nachweise statt bloßer Systemauskünfte. Für IT-Betrieb und Configuration Management macht es Änderungen, Historien und Stichtagsbestände schneller nachvollziehbar. Für Compliance-Verantwortliche verbindet es Archivierung, Datenschutz, Vier-Augen-Prinzip und Audit-Log in einem konsistenten Prozess.

Kurz gesagt: SMILEdataguard macht aus operativen ITSM-Daten ein belastbares Archiv. Nicht, weil man dem System vertrauen muss, sondern weil die Integrität mathematisch und organisatorisch nachweisbar wird.

Der richtige Zeitpunkt für den Anschluss ist deshalb nicht „wenn der Prüfer fragt“, sondern bevor die nächste relevante Historie entsteht.

Das aktuelle Handbuch ist öffentlich verfügbar unter smiledataguard.manyosdocs.de.