SMILEdataguard · Prüfbares Archiv für ITSM und CMDB

SMILEdataguard macht die Historie von ITSM- und CMDB-Daten prüfbar.

Jede Version eines Tickets, Changes oder CIs wird archiviert und kryptografisch verkettet. So lässt sich später belegen, was zu einem Stichtag galt und dass diese Historie unverändert ist. Die Beweiskette beginnt mit dem Anschluss des Quellsystems.

30-Minuten-Demo anfragen Handbuch öffnen

Datenblatt

Quellen: BMC Remedy und BMC ITSM mit CMDB; REST-Quellen mit Änderungsfeed, Einzelobjekt und Bestandsliste
Archiv: Jede Version eines Objekts, inklusive Historie und Löschereignissen
Integrität: Hash-Ketten je Objekt, Merkle-Bäume, signierte Anker
Auswertung: Suche, Bestand zu einem Stichtag, Compliance-Baselines
Datenschutz: Pseudonymisierung, Verschlüsselung, Crypto-Shredding
Nachweise: Signierte Prüfberichte und Exporte, offline prüfbar
Governance: Rollen, Vier-Augen-Anträge, Audit-Log, maschinenlesbare API

Warum der Zeitpunkt zählt

Archivierung ist nicht rückwirkend möglich

SMILEdataguard kann nicht nachträglich belegen, was nie archiviert wurde. Die prüfbare Historie beginnt, wenn das Quellsystem angeschlossen ist. Wer wartet, bis der Prüfer fragt, hat für die Vergangenheit keinen Nachweis.

Anschluss

Vor dem Anschluss

Ohne Nachweis

Änderungen vor dem Anschluss bleiben auskunftspflichtig, sind technisch aber nicht mehr vollständig belegbar.

Ab Anschluss

Prüfbare Beweiskette

Es 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.

Funktionen

Mehr als ein Änderungsprotokoll

In ITSM- und CMDB-Systemen ändern sich täglich tausende Objekte, Attribute und Beziehungen. Für ein Audit reicht es nicht, dem aktuellen Stand zu vertrauen. Belegbar sein muss, was zu einem bestimmten Zeitpunkt galt und ob diese Historie unverändert geblieben ist, auch wenn das Quellsystem inzwischen geändert, bereinigt oder abgelöst wurde.

01

Vollständiges Änderungsarchiv

CMDB-Objekte, Changes, Tickets und weitere Daten werden versioniert archiviert. Jede Version bleibt erhalten, inklusive Historie, Löschereignissen und rekonstruierbarem Bestand.
02

Manipulation wird sichtbar

Hash-Ketten, Merkle-Bäume und signierte Anker machen Veränderungen prüfbar. Ein Finding zeigt nicht nur, dass etwas nicht stimmt, sondern auch, wo der Widerspruch liegt.
03

Bestand zu einem Stichtag

Der Bestand lässt sich für jeden Zeitpunkt rekonstruieren. Auditoren und Betrieb sehen, welche Objekte, Beziehungen und Attribute an einem bestimmten Datum gültig waren.
04

Datenschutz, ohne die Beweiskette zu brechen

Pseudonymisierung, Verschlüsselung und Crypto-Shredding ermöglichen DSGVO-konforme Löschkonzepte. Die Integrität des Archivs bleibt dabei erhalten.
05

Compliance-Baselines

Soll-Zustände für Objekttypen werden versioniert abgelegt und gegen den archivierten Bestand geprüft. Die Prüfberichte lassen sich signieren.
06

Fremdsysteme über REST

Neben BMC Remedy lassen sich REST-Quellen anbinden, wenn sie einen Änderungsfeed, Einzelobjekte und eine Bestandsliste bereitstellen. Secrets bleiben außerhalb der Konfiguration.

Rollen

Wer mit SMILEdataguard arbeitet

Die aktuelle Version ist eine Arbeitsoberfläche für Archiv, Audit und Betrieb: mit Rollen, Dashboard, Suche, Zeitreise, Datenschutzprozessen, Vier-Augen-Anträgen und maschinenlesbarer API.

Auditoren: Integritätsstatus, Audit-Log, signierte Exporte und präzise Findings für belastbare Nachweise.
Compliance: Versionierte Regeln, Baselines, Datenschutzmaßnahmen und Vier-Augen-Freigaben für klare Zuständigkeiten.
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.
IT-Betrieb: Suchen, Historien prüfen, Bestände zu Stichtagen rekonstruieren und Quellsysteme kontrolliert anbinden.

Handbuch öffnen

Häufiger Einwand

„Wir behalten einfach die alte Datenbank.“

Eine stillgelegte Datenbank kann Aufbewahrung bedeuten. Die Auskunfts- und Nachweispflicht erfüllt sie damit nicht automatisch.

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 ein unabhängiger Integritätsnachweis entsteht.

Die Historie ist oft unvollständig

Remedy-Audit ist opt-in, pro Formular und pro Feld. In gewachsenen Installationen ist häufig nur ein Teil aktiv. Dann bleibt ein Endzustand, aber 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 ist „vorhanden“ nicht gleich „lesbar“.

Eine stillgelegte Datenbank kann Daten aufbewahren. Eine dauerhaft maschinenlesbare, fachlich rekonstruierbare und unabhängig prüfbare Beweiskette liefert sie nicht.

Abgrenzung

Was vorhandene Werkzeuge nicht beantworten

Viele Systeme liefern Ausschnitte. Offen bleibt die Frage, welcher fachliche Zustand zu einem Stichtag galt und ob sich diese Aussage prüfen lässt.

Werkzeug	Was fehlt	Was SMILEdataguard ergänzt
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.	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, rekonstruiert aber nicht zuverlässig den fachlichen Objektzustand mit Attributen und Beziehungen zu einem Stichtag.	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.	Speichert Versionen, Anker, Prüfpfade und Exporte so, dass sich die Integrität gezielt nachweisen lässt.
WORM-Storage	Schützt ein Medium vor Überschreiben, erklärt aber nicht die fachliche Historie, die CMDB-Beziehungen oder den Objektzustand zu einem konkreten Datum.	Verbindet unveränderte Speicherung mit fachlicher Auskunftsfähigkeit und maschinell prüfbaren Exporten.

Regulatorik

Die Anforderungen werden konkreter, die Fristen bleiben kurz

Für Revision und Compliance zählt nicht, dass Daten irgendwo liegen. Gefordert sind Verfügbarkeit, Nachvollziehbarkeit, Integrität und Auswertbarkeit über Jahre.

Vorgabe	Worum es geht	Beitrag von SMILEdataguard
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.

Ablauf

So entsteht die Beweiskette

01

Daten aus Quellen archivieren

SMILEdataguard übernimmt Änderungen und Bestände aus ITSM-, CMDB- oder REST-Quellen und speichert jede Version dauerhaft im Archiv.
02

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.
03

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.

Mehr zu SMILEdataguard im Blog

Weitere Produkte

Die anderen SMILE-Produkte

Kontakt

Der beste Anschlusszeitpunkt liegt vor der nächsten Prüfung.

In einer 30-Minuten-Demo zeigen wir, wie SMILEdataguard Ihre ITSM- und CMDB-Historie ab dem Anschluss prüfbar macht, mit Zeitreise, Datenschutzfunktionen und Beweiskette.

30-Minuten-Demo anfragen

Sie sprechen direkt mit