Von BAIT zu DORA: Was sich für die Nachweispflicht in ITSM und CMDB ändert
Viele IT-Organisationen haben BAIT, VAIT, KAIT oder ZAIT jahrelang als Orientierungsrahmen für IT-Governance und Informationssicherheit genutzt. Diese Landschaft verändert sich. VAIT, KAIT und ZAIT wurden bereits zum 16. Januar 2025 aufgehoben. Die BAIT läuft zum 31. Dezember 2026 aus. Gleichzeitig ist DORA, die Verordnung (EU) 2022/2554 über die digitale operationale Resilienz im Finanzsektor, seit dem 17. Januar 2025 anwendbar.
Für ITSM und CMDB ist das kein rein regulatorischer Namenswechsel. Die zentrale Frage wird praktischer: Kann eine Organisation in kurzer Zeit belegen, was passiert ist, welche Systeme betroffen waren und welcher Bestand zu einem bestimmten Zeitpunkt galt?
DORA macht Nachvollziehbarkeit zeitkritisch
DORA verlangt von Finanzunternehmen ein belastbares IKT-Risikomanagement und strukturierte Prozesse für IKT-bezogene Vorfälle. Bei schwerwiegenden Vorfällen greifen kurze Meldefristen: eine Erstmeldung innerhalb von 4 Stunden ab Einstufung, ein Zwischenbericht nach 72 Stunden und ein Abschlussbericht innerhalb eines Monats.
Wer binnen Stunden melden muss, was passiert ist, kann nicht erst mit forensischer Spurensuche in alten Systemen beginnen. Besonders kritisch wird es, wenn ein Administrator mit hohen Rechten potenziell selbst Teil des Problems ist. Dann reicht eine Datenbankauskunft aus dem Quellsystem nicht als unabhängiger Nachweis.
Die Beweiskette beginnt nicht rückwirkend
Der entscheidende Punkt wird in Projekten oft unterschätzt: Eine prüfbare Historie entsteht erst ab dem Anschlusszeitpunkt. Was vorher nicht archiviert wurde, lässt sich später nicht vollständig nachweisen.
Das betrifft besonders ITSM-Migrationen und Systemablösungen. Wenn ein altes Remedy-System abgeschaltet wird und nur eine Datenbankkopie übrig bleibt, ist zwar etwas aufbewahrt. Aber aus Sicht von Revision und Compliance ist damit noch nicht beantwortet, ob die Historie vollständig ist, ob sie unverändert blieb und ob sie in sieben Jahren noch maschinell auswertbar ist.
Warum die alte Datenbank allein nicht genügt
Eine Datenbank ist veränderbar. Das ist ihr Zweck. Wer ausreichende Rechte hat, kann Rohdaten ändern, ohne dass daraus automatisch ein unabhängiger Integritätsnachweis entsteht.
Dazu kommt: Die fachliche Historie ist in vielen ITSM-Systemen nicht vollständig vorhanden. Remedy-Audit ist beispielsweise konfigurationsabhängig und typischerweise pro Formular und Feld aktivierbar. In gewachsenen Installationen ist es häufig nur teilweise eingeschaltet. Ohne vollständige Historie wird ein Endzustand konserviert, nicht der Verlauf.
Und selbst wenn Rohdaten noch vorhanden sind, sind sie nicht automatisch auskunftsfähig. Technische Tabellen- und Feldstrukturen, Diary-Felder, Join-Formulare, Attachments und Metadatenmodelle müssen später noch verstanden werden. Aufbewahrungspflichten verlangen aber mehr als „irgendwo vorhanden“: Informationen müssen verfügbar, lesbar und auswertbar bleiben.
Was SMILEdataguard anders macht
SMILEdataguard archiviert ITSM-, CMDB- und Fremdsystemdaten als fachlich rekonstruierbare Historie. Jede Version eines Objekts wird gespeichert, kryptografisch mit ihrer Vorgängerversion verkettet und regelmäßig über signierte Anker abgesichert. So lässt sich später prüfen, ob ein Datensatz seit der Archivierung unverändert blieb.
Für Audits ist besonders die Stichtagsfrage wichtig: Welche CIs, Attribute und Beziehungen waren zu einem bestimmten Zeitpunkt gültig? SMILEdataguard kann solche Bestände rekonstruieren und gleichzeitig kennzeichnen, ab wann ein Bestand nachweislich vollständig ist. Diese Ehrlichkeit ist wichtig, weil ein Archiv keine Sicherheit vortäuschen sollte, die es nicht belegen kann.
GoBD, HGB und AO betreffen mehr als Finanzunternehmen
DORA ist vor allem für den Finanzsektor relevant. Aufbewahrungs- und Auskunftspflichten reichen aber weiter. GoBD, HGB und AO führen zu Fristen von 6 und 10 Jahren. Auch Unternehmen außerhalb der BaFin-Regulierung müssen deshalb klären, wie historische Systemdaten lesbar, auswertbar und nachvollziehbar bleiben.
Für ITSM- und CMDB-Daten wird das spätestens bei Migrationen konkret. Wer ein Altsystem abschaltet, sollte vorher entscheiden, welche Historie künftig beweisbar bleiben muss. Nach der Abschaltung ist es zu spät, eine lückenlose Beweiskette für die Vergangenheit zu starten.
Fazit
BAIT läuft aus, DORA gilt bereits, und die technische Realität bleibt dieselbe: Nachweise entstehen nicht rückwirkend. Wer erst archiviert, wenn der Prüfer fragt, hat für genau diese Frage meist nichts gewonnen.
Der richtige Zeitpunkt für eine prüfbare ITSM- und CMDB-Archivierung ist vor der nächsten Prüfung, vor der nächsten DORA-relevanten Meldung und vor der Systemablösung.