Prüfbare ITSM-Historie.
Die Beweiskette beginnt ab dem Anschlusszeitpunkt. Jeder Monat ohne Archivierung ist ein Monat, der bei der nächsten Prüfung, DORA-Meldung oder Systemablösung nicht mehr nachweisbar ist.
Neue Version
Mehr als ein Änderungsprotokoll
Die aktuelle Version macht SMILEdataguard zur nachvollziehbaren Arbeitsoberfläche für Archiv, Audit und Betrieb: mit Rollen, Dashboard, Suche, Zeitreise, Datenschutzprozessen, Vier-Augen-Anträgen und maschinenlesbarer API. Entscheidend bleibt: Die Beweiskette wächst erst ab Anschluss.
Handbuch öffnenFür Auditoren
Integritätsstatus, Audit-Log, signierte Exporte und präzise Findings für belastbare Nachweise.
Für Compliance
Versionierte Regeln, Baselines, Datenschutzmaßnahmen und Vier-Augen-Freigaben schaffen klare Governance.
Für Migrationen
Vor der Systemablösung angeschlossen, bleibt die Historie später durchsuchbar, auswertbar und prüfbar. Nach der Abschaltung lässt sich der Verlauf nicht mehr nachholen.
Für IT-Betrieb
Suchen, Historien prüfen, Bestände zu Stichtagen rekonstruieren und Quellsysteme kontrolliert anbinden.
Warum der Zeitpunkt zählt
Archivierung ist nicht rückwirkend möglich
SMILEdataguard beweist nicht nachträglich, was nie archiviert wurde. Die prüfbare Historie beginnt erst, wenn das Quellsystem angeschlossen ist. Wer wartet, bis der Prüfer fragt, hat für die Vergangenheit genau den Nachweis nicht.
Ohne Nachweis
Änderungen vor dem Anschluss bleiben auskunftspflichtig, aber technisch nicht mehr vollständig belegbar.
Prüfbare Beweiskette
Ab Anschluss entstehen Versionen, Hash-Ketten, signierte Anker und offline prüfbare Exporte.
Der Schnitt liegt beim technischen Anschluss des Quellsystems, nicht beim Budgetbeschluss und nicht beim späteren Audit.
Das Problem
In ITSM- und CMDB-Systemen ändern sich täglich tausende Objekte, Attribute und Beziehungen. Für Audits reicht es nicht, dem aktuellen Stand zu vertrauen: Es muss belegbar sein, was zu einem bestimmten Zeitpunkt galt und ob diese Historie unverändert geblieben ist.
Die Lösung
SMILEdataguard macht aus operativen Daten ein prüfbares Änderungsarchiv. Versionen werden kryptografisch verkettet, regelmäßig signiert verankert und bleiben auch dann auswertbar, wenn das Quellsystem gelöscht, verändert oder abgelöst wurde.
Beweise statt Zusicherungen
Für Auditoren, Compliance-Verantwortliche und IT-Betrieb, die nicht nur Daten brauchen, sondern belastbare Nachweise.
Vollständiges Änderungsarchiv
CMDB-Objekte, Changes, Tickets und weitere Daten werden versioniert archiviert. Jede Version bleibt erhalten — inklusive Historie, Löschereignissen und rekonstruierbarem Bestand.
Nachweisbare Manipulationssicherheit
Hash-Ketten, Merkle-Bäume und signierte Anker machen Veränderungen prüfbar. Findings zeigen nicht nur, dass etwas nicht stimmt, sondern auch wo.
Zeitreise für IT-Bestände
Der Bestand lässt sich für jeden Zeitpunkt rekonstruieren. So sehen Auditoren und Betrieb, welche Objekte, Beziehungen und Attribute zu einem Stichtag gültig waren.
Datenschutz ohne Integritätsbruch
Pseudonymisierung, Verschlüsselung und Crypto-Shredding ermöglichen DSGVO-konforme Löschkonzepte, ohne die Beweiskette des Archivs zu zerstören.
Compliance-Baselines
Soll-Zustände für Objekttypen werden versioniert abgelegt und gegen den archivierten Bestand geprüft — inklusive signierbarer Prüfberichte.
Flexible Fremdsysteme
Neben Remedy/BMC lassen sich REST-Quellen anbinden, wenn sie Änderungsfeed, Einzelobjekt und Bestandsliste bereitstellen. Secrets bleiben dabei außerhalb der Konfiguration.
Häufiger Einwand
„Wir behalten einfach die alte Datenbank“
Eine stillgelegte Datenbank kann Aufbewahrung bedeuten. Sie erfüllt aber nicht automatisch die Auskunfts- und Nachweispflicht.
Eine Datenbank beweist nichts
Datenbanken sind dafür gebaut, per UPDATE verändert zu werden. Wer DBA-Rechte hat, kann Rohdaten ändern, ohne dass daraus automatisch ein unabhängiger Integritätsnachweis entsteht.
Die Historie ist oft unvollständig
Remedy-Audit ist opt-in: pro Formular, pro Feld. In gewachsenen Installationen ist häufig nur ein Teil aktiv. Dann bleibt ein Endzustand, kein belastbarer Verlauf.
Rohdaten sind keine Auskunft
Formulare liegen als technische Tabellen und Feld-IDs vor; Diary-Felder, Join-Formulare und Attachments brauchen Kontext. Ohne Applikationsmodell wird „vorhanden“ nicht automatisch „lesbar“.
Fazit: Eine stillgelegte Datenbank kann Daten aufbewahren. Sie liefert aber keine dauerhaft maschinenlesbare, fachlich rekonstruierbare und unabhängig prüfbare Beweiskette.
Abgrenzung
Was vorhandene Werkzeuge nicht beantworten
Viele Systeme liefern Ausschnitte. Die kritische Frage bleibt: Welcher fachliche Zustand war zu einem Stichtag gültig — und ist diese Aussage prüfbar?
BMC Helix Audit / History
Hilft im Quellsystem, ersetzt aber keinen unabhängigen Integritätsnachweis. Je nach Konfiguration bleiben Löschungen, privilegierte Änderungen oder abgeschaltete Quellsysteme blinde Flecken.
SMILEdataguard archiviert außerhalb des fachlichen Arbeitsprozesses, verkettet Versionen kryptografisch und prüft die Beweiskette unabhängig vom Quellsystem.
SIEM wie Splunk oder Elastic
Sammelt Events. Es rekonstruiert nicht zuverlässig den fachlichen Objektzustand mit Attributen und Beziehungen zu einem Stichtag.
SMILEdataguard beantwortet die Stichtagsfrage: Welche Version eines Objekts war wann gültig, mit welchen Beziehungen und welchem Integritätsstatus?
Backup oder Snapshot
Wiederherstellung ist kein Nachweis. Ein Backup zeigt nicht, ob der gesicherte fachliche Zustand vollständig, unverändert und auswertbar ist.
SMILEdataguard speichert Versionen, Anker, Prüfpfade und Exporte so, dass Integrität gezielt nachgewiesen werden kann.
WORM-Storage
Schützt ein Medium vor Überschreiben. Er erklärt nicht die fachliche Historie, die CMDB-Beziehungen oder den Objektzustand zu einem konkreten Datum.
SMILEdataguard verbindet unveränderte Speicherung mit fachlicher Auskunftsfähigkeit und maschinell prüfbaren Exporten.
Regulatorik
Anforderungen werden konkreter, Fristen bleiben kurz
Für Revision und Compliance zählt nicht das Versprechen, dass Daten irgendwo liegen. Gefordert sind Verfügbarkeit, Nachvollziehbarkeit, Integrität und Auswertbarkeit über Jahre.
DORA
VO (EU) 2022/2554, anwendbar seit 17.01.2025: IKT-Risikomanagement, Nachvollziehbarkeit und kurze Meldefristen.
Ein Änderungsarchiv, das privilegierte Administratoren nicht still ändern können, hilft bei der schnellen Klärung, was wann betroffen war.
BAIT-Auslauf
VAIT, KAIT und ZAIT wurden zum 16.01.2025 aufgehoben; BAIT läuft zum 31.12.2026 aus.
SMILEdataguard schafft eine technische Nachweisbasis für die Übergangsphase von alten Verwaltungsvorgaben zu DORA-orientierter Governance.
GoBD / HGB / AO
Aufbewahrungsfristen von 6 und 10 Jahren betreffen nicht nur BaFin-regulierte Organisationen.
Historische ITSM- und CMDB-Daten bleiben auffindbar, maschinenlesbar und mit prüfbarer Integrität verfügbar.
ISO 27001 / NIS2
Protokollierung, Schutz von Aufzeichnungen, Nachvollziehbarkeit und Steuerung von IKT-Risiken.
Hash-Ketten, signierte Anker, Vier-Augen-Anträge und Audit-Logs unterstützen nachvollziehbare Kontrollen.
So entsteht eine prüfbare Beweiskette
Daten aus Quellen archivieren
SMILEdataguard übernimmt Änderungen und Bestände aus ITSM-, CMDB- oder REST-Quellen und speichert jede Version dauerhaft im Archiv.
Versionen verketten und verankern
Jede Version erhält einen Hash und verweist auf ihren Vorgänger. Signierte Anker versiegeln Archivbereiche zusätzlich und machen nachträgliche Änderungen sichtbar.
Nachweise liefern und offline prüfen
Suche, Zeitreise, Integritätsberichte und signierte Exporte liefern die Belege, die Auditoren auch unabhängig vom laufenden System prüfen können.
Weitere SMILE-Produkte
Entdecken Sie die gesamte SMILE-Produktfamilie für Ihre BMC ITSM Suite.
Der beste Anschlusszeitpunkt ist vor der nächsten Prüfung
Erfahren Sie in einer 30-Minuten-Demo, wie SMILEdataguard Ihre ITSM- und CMDB-Historie ab Anschlusszeitpunkt prüfbar macht — inklusive Zeitreise, Datenschutz und Beweiskette.