- Die häufigsten Wechselgründe sind steigende SaaS-Kosten, fehlende Kontrolle über den Speicherort der Daten und Compliance-Anforderungen, die eine nachweisbare Datenhoheit verlangen.
- Der kritischste Schritt ist der Datenexport beim Altanbieter. Prüfe vor der Kündigung, welche Formate verfügbar sind und ob alle Datentypen exportierbar sind.
- Ein Parallelbetrieb von vier bis acht Wochen sichert dich ab: Das neue System läuft produktiv, während das alte noch lesend verfügbar bleibt.
- Feld-Mapping zwischen den Systemen erfordert mehr Aufwand als erwartet, weil jeder Anbieter eigene Datenstrukturen und Bezeichnungen verwendet.
- Nach der Migration musst du die formale Abschaltung des Cloud-Dienstes dokumentieren, inklusive Bestätigung der Datenlöschung beim Altanbieter.
Warum Unternehmen ihre Cloud-ISMS verlassen
Die Entscheidung für eine Cloud-basierte ISMS-Lösung fällt in den meisten Unternehmen schnell. Kein Server aufsetzen, kein Hosting organisieren, kein Admin-Aufwand. Einfach anmelden, Kreditkarte hinterlegen, loslegen. Drei Jahre später sieht die Rechnung anders aus, und zwar im wörtlichen wie im übertragenen Sinn.
Die Gründe für den Wechsel von Cloud zu Self-Hosted lassen sich in drei Kategorien einteilen, die in der Praxis fast immer gemeinsam auftreten.
Kostenkontrolle
SaaS-Anbieter kalkulieren pro Benutzer, pro Modul oder pro Asset-Anzahl. Was bei 5 Nutzern und 50 Assets im Rahmen bleibt, wird bei 20 Nutzern und 300 Assets zum relevanten Budgetposten. Der typische Verlauf: Im ersten Jahr kostet die ISMS-Plattform 3.000 Euro. Im zweiten Jahr kommen Module dazu, die beim Onboarding noch nicht nötig waren. Im dritten Jahr steigt der Anbieter auf ein neues Preismodell um, und plötzlich stehen 8.000 bis 12.000 Euro auf der Jahresrechnung.
Dazu kommt die eingeschränkte Verhandlungsposition. Wenn dein gesamtes ISMS in einem System steckt, das du nicht einfach exportieren kannst, hat der Anbieter wenig Anreiz, dir beim Preis entgegenzukommen. Das ist kein theoretisches Problem. In einem Vergleich der tatsächlichen Gesamtkosten zeigt sich, dass Self-Hosted-Lösungen ab dem zweiten Jahr oft günstiger sind, weil die Lizenzkosten nicht mit der Nutzerzahl skalieren.
Datenhoheit und Compliance
Für Unternehmen, die unter NIS2 fallen oder eine ISO-27001-Zertifizierung anstreben, ist die Frage "Wo liegen meine ISMS-Daten?" nicht akademisch. Dein ISMS enthält eine detaillierte Landkarte deiner Schwachstellen, deiner Risikobewertungen, deiner noch nicht umgesetzten Maßnahmen. Es ist praktisch das Handbuch dafür, wo dein Unternehmen verwundbar ist. Dieses Handbuch auf einem Server zu speichern, über den du keine direkte Kontrolle hast, ist ein Widerspruch, der spätestens im Audit erklärt werden muss.
Manche Branchen gehen noch weiter. KRITIS-Betreiber, Unternehmen mit Geheimhaltungsanforderungen oder Zulieferer in der Verteidigungsindustrie haben teilweise vertragliche Vorgaben, die eine Speicherung von Sicherheitsdokumentation außerhalb der eigenen Infrastruktur ausschließen.
Abhängigkeit und Kontrolle
Cloud-Dienste sind bequem, solange sie funktionieren. Aber du bist von Entscheidungen abhängig, die du nicht beeinflussen kannst. Der Anbieter ändert die API. Der Anbieter stellt ein Feature ein. Der Anbieter wird aufgekauft und das Produkt in eine andere Plattform integriert. Der Anbieter hat einen Ausfall, und du kommst ausgerechnet während des Audits nicht an deine Dokumentation.
Das sind keine Horrorszenarien, das sind dokumentierte Geschäftsvorfälle in der SaaS-Branche. Wer sein ISMS selbst hostet, tauscht den Komfort des "jemand anders kümmert sich" gegen die Sicherheit des "ich kann mich auf mein System verlassen, weil es meines ist".
Vor der Migration: Bestandsaufnahme und Exportanalyse
Bevor du den Migrationsprozess startest, brauchst du Klarheit über zwei Dinge: Was steckt in deinem Cloud-ISMS, und wie kommst du da ran?
Datenbestand inventarisieren
Erstelle eine vollständige Liste aller Datentypen, die in deinem Cloud-ISMS gespeichert sind:
- Assets und Inventar: Alle erfassten IT-Assets mit Klassifizierung, Schutzbedarf und Verantwortlichkeiten
- Risikobewertungen: Risiken mit Bedrohungen, Schwachstellen, Bewertungsmatrix und Behandlungsentscheidungen
- Maßnahmen: Alle Controls mit Umsetzungsstatus, Verantwortlichen und Fristen
- Statement of Applicability: Die SoA mit Begründungen für jedes Control
- Dokumente und Richtlinien: Alle hochgeladenen oder im System erstellten Dokumente
- Audit-Protokolle: Interne Auditberichte, Feststellungen, Maßnahmen
- Nachweise: Screenshots, Zertifikate, Schulungsnachweise
- Historien und Änderungsprotokolle: Wer hat wann was geändert
Export-Fähigkeiten des Altanbieters prüfen
Hier wird es oft unangenehm. Nicht jeder ISMS-Anbieter macht den Export einfach, und manche machen ihn bewusst schwer. Prüfe folgende Punkte:
| Frage | Warum wichtig |
|---|---|
| Welche Exportformate werden angeboten? (CSV, JSON, XML, PDF) | JSON und CSV sind maschinenlesbar und importierbar. PDF-Exporte sind für die Migration wertlos. |
| Können alle Datentypen exportiert werden? | Manche Anbieter exportieren nur Assets und Risiken, aber keine Audit-Protokolle oder Nachweise. |
| Bleiben Verknüpfungen erhalten? | Die Beziehung zwischen Risiko, Maßnahme und Asset geht bei einfachen CSV-Exporten oft verloren. |
| Gibt es eine API? | Über eine API lassen sich auch Daten extrahieren, die der Standard-Export nicht abdeckt. |
| Was passiert nach der Kündigung? | Manche Anbieter löschen die Daten sofort, andere gewähren eine Übergangsfrist von 30 bis 90 Tagen. |
| Werden Dateianhänge mit exportiert? | Richtlinien-PDFs, Screenshots und Nachweise müssen separat heruntergeladen werden, wenn sie nicht im Export enthalten sind. |
Fallstrick: Der unvollständige Export
Der mit Abstand häufigste Fehler bei der Migration ist, sich auf den Export-Button des Altanbieters zu verlassen, ohne das Ergebnis zu prüfen. Ein reales Beispiel: Ein mittelständischer IT-Dienstleister exportierte sein ISMS aus einer bekannten SaaS-Plattform. Der Export enthielt 230 Risiken als CSV. Was fehlte: die Risikobewertungshistorie (welche Werte hatten die Risiken bei der letzten Bewertung?), die Verknüpfung zwischen Risiken und Maßnahmen (nur die Risiken selbst, nicht ihre Controls), und sämtliche Dateianhänge.
Deshalb: Exportiere frühzeitig einen Testdatensatz und prüfe ihn gegen deine Bestandsliste. Mache das mindestens sechs Wochen vor dem geplanten Migrationstermin. Wenn der Export unvollständig ist, brauchst du Zeit, um Alternativen zu finden, sei es über die API, über den Support oder im schlimmsten Fall durch manuelle Extraktion.
Phase 1: Vorbereitung und Feld-Mapping
Die Zielsystem-Struktur verstehen
Bevor du Daten verschiebst, musst du verstehen, wie das Zielsystem Daten organisiert. Jedes ISMS-Tool hat eine eigene Struktur: andere Feldnamen, andere Hierarchien, andere Pflichtfelder. Was beim Altanbieter "Eintrittswahrscheinlichkeit" heißt, kann im Zielsystem "Häufigkeit" heißen. Was dort eine 5-stufige Skala ist, kann hier eine 3-stufige sein.
Erstelle ein Mapping-Dokument, das für jeden Datentyp die Zuordnung zwischen Alt- und Neusystem definiert:
Beispiel für Risikobewertungen:
| Feld Altsystem | Feld Neusystem | Transformation |
|---|---|---|
| risk_title | name | 1:1 Übernahme |
| probability (1-5) | likelihood (1-3) | 1-2 → 1, 3 → 2, 4-5 → 3 |
| impact (1-5) | impact (1-3) | 1-2 → 1, 3 → 2, 4-5 → 3 |
| risk_owner_email | owner | Lookup gegen Benutzerliste |
| linked_assets (IDs) | assets | Mapping über Asset-ID-Tabelle |
| treatment | treatment_option | Wertemapping: "mitigate" → "mitigieren" |
Dieses Mapping ist Detailarbeit, die leicht zwei bis drei Tage dauert. Aber es ist die Investition, die den Unterschied zwischen einer sauberen Migration und wochenlanger Nacharbeit macht.
Datenbereinigung vor der Migration
Eine Migration ist die perfekte Gelegenheit zum Aufräumen. Übernimm nicht blind alles, was im Altsystem steckt:
- Veraltete Risiken entfernen: Risiken, die sich auf Systeme beziehen, die längst abgeschaltet sind
- Doppelte Assets konsolidieren: Im Lauf der Zeit entstehen oft Duplikate
- Abgeschlossene Maßnahmen archivieren: Maßnahmen mit Status "erledigt" und Abschlussdatum vor über zwei Jahren müssen nicht zwingend migriert werden
- Verwaiste Dokumente identifizieren: Richtlinien, die nie freigegeben oder längst durch neuere Versionen ersetzt wurden
Dokumentiere, was du bewusst nicht migrierst und warum. Das ist kein Nice-to-have, das ist eine Anforderung aus der ISO 27001, die nachvollziehbare Änderungen am ISMS verlangt.
Phase 2: Export und Transformation
Strukturierter Export
Führe den Export systematisch durch, nicht alles auf einmal, sondern nach Datentyp:
- Stammdaten zuerst: Benutzer, Organisationseinheiten, Standorte
- Assets: Alle IT-Assets mit Klassifizierung und Schutzbedarf
- Risikobewertungen: Risiken mit allen Bewertungsdimensionen
- Maßnahmen und Controls: Inklusive Umsetzungsstatus und Verantwortlichkeiten
- SoA: Statement of Applicability mit Begründungen
- Dokumente und Nachweise: Alle Dateianhänge
- Audit-Daten: Auditberichte, Feststellungen, Korrekturmaßnahmen
Speichere jeden Export mit Datum und Beschreibung. Du wirst im Verlauf der Migration mehrfach darauf zurückgreifen.
Datentransformation
Die exportierten Daten müssen in das Format des Zielsystems gebracht werden. Je nachdem, wie unterschiedlich die Systeme strukturiert sind, kann das von einfachem Spaltenumbenennen bis zu komplexen Transformationen reichen.
Für die Transformation empfiehlt sich ein Skript, auch wenn es nur ein Python- oder PowerShell-Script ist, das CSV-Spalten umbenennt und Werte mappt. Der Grund: Wenn du beim ersten Import einen Fehler findest, kannst du das Skript anpassen und den Import wiederholen. Bei manueller Transformation fängst du bei jedem Fehler von vorne an.
Ein typisches Transformationsskript macht folgendes:
- Spalten umbenennen gemäß Mapping-Dokument
- Werte transformieren (Skalen anpassen, Textwerte übersetzen)
- IDs ersetzen (die Asset-IDs des Altsystems durch die des Neusystems)
- Verknüpfungen auflösen und neu herstellen
- Pflichtfelder ergänzen, die im Altsystem nicht existierten
Datenformate und Kompatibilität
Die gängigsten Austauschformate bei ISMS-Migrationen:
CSV: Einfach, weit verbreitet, aber verliert Verknüpfungen und Hierarchien. Funktioniert gut für flache Datenstrukturen wie Asset-Listen. Problematisch bei verschachtelten Daten wie Risiken mit mehreren verknüpften Assets.
JSON: Kann Hierarchien und Verknüpfungen abbilden. Besser geeignet für komplexe Datenstrukturen. ISMS Lite bietet einen JSON-Import, der Assets, Risiken und Maßnahmen mit ihren Verknüpfungen in einem Durchgang einlesen kann.
XML: Ähnlich mächtig wie JSON, aber sperriger. In der Praxis seltener, weil die meisten modernen ISMS-Tools eher JSON verwenden.
PDF: Nur für die menschliche Lesbarkeit. Nicht maschinenlesbar, nicht importierbar. Wenn der Altanbieter nur PDF-Exporte bietet, hast du ein Problem, das manuelle Übertragung oder OCR erfordert.
Phase 3: Import und Validierung
Testimport mit Teilmenge
Importiere nie den kompletten Datensatz auf einen Schlag. Starte mit einer Teilmenge:
- 10 Assets mit unterschiedlichen Klassifizierungen
- 5 Risiken mit unterschiedlichen Bewertungen und verknüpften Assets
- 5 Maßnahmen mit unterschiedlichen Status
- 2 Dokumente als Dateianhänge
Prüfe nach dem Testimport:
- Sind alle Felder korrekt befüllt?
- Stimmen die Verknüpfungen (Risiko → Asset, Maßnahme → Risiko)?
- Sind Umlaute und Sonderzeichen korrekt dargestellt?
- Stimmen die Bewertungsskalen nach der Transformation?
- Sind Verantwortlichkeiten den richtigen Benutzern zugeordnet?
Korrigiere das Transformationsskript, lösche die Testdaten und wiederhole den Import. Plane für diesen Zyklus zwei bis drei Durchläufe ein.
Vollständiger Import
Nach dem erfolgreichen Testimport folgt der vollständige Import. Dokumentiere den Zeitpunkt und mache vorher ein Backup des Zielsystems (bei Self-Hosted ein Snapshot oder Dateisystem-Backup). Der Import sollte außerhalb der Arbeitszeit stattfinden, damit keine anderen Benutzer gleichzeitig im System arbeiten.
Validierungscheckliste
Nach dem vollständigen Import prüfst du systematisch:
- Anzahl der importierten Assets stimmt mit der Export-Anzahl überein (abzüglich bewusst nicht migrierter Einträge)
- Anzahl der Risiken stimmt
- Anzahl der Maßnahmen stimmt
- Stichprobe: 10 zufällige Risiken mit allen Feldern und Verknüpfungen prüfen
- Stichprobe: 5 Assets mit Schutzbedarf und verknüpften Risiken prüfen
- SoA vollständig und Begründungen vorhanden
- Alle Dokumente und Dateianhänge lesbar
- Benutzerberechtigungen korrekt zugeordnet
- Risikomatrix zeigt plausible Verteilung
- Audit-Trail im Zielsystem dokumentiert den Import
Phase 4: Parallelbetrieb
Der Parallelbetrieb ist die Sicherheitsnetze-Phase. Für vier bis acht Wochen führst du das neue System produktiv, während das alte noch lesend zugänglich bleibt.
Regeln für den Parallelbetrieb
- Neues System ist führend: Alle Änderungen werden nur noch im neuen System vorgenommen
- Altes System ist read-only: Es dient nur noch als Referenz für Rückfragen
- Täglicher Abgleich in Woche 1: Prüfe jeden Tag, ob im neuen System Daten fehlen, die im alten noch sichtbar sind
- Wöchentlicher Abgleich ab Woche 2: Reduziere die Prüffrequenz, wenn sich die Datenlage stabilisiert hat
Was im Parallelbetrieb typischerweise auffällt
- Felder, die im Mapping vergessen wurden (besonders: Freitext-Notizen, die im Altsystem an unerwarteter Stelle standen)
- Verknüpfungen, die in der Transformation verloren gegangen sind
- Bewertungsskalen, deren Transformation bei Grenzwerten nicht passt
- Dokumente, die beim Export nicht mit erfasst wurden
Diese Erkenntnisse korrigierst du laufend im neuen System. Dokumentiere jede Korrektur, damit du am Ende eine vollständige Migrationsdokumentation hast.
Phase 5: Abschaltung des Altsystems
Formale Abschaltung
Die Abschaltung des Cloud-Dienstes ist kein technisches, sondern ein organisatorisches Ereignis. Dokumentiere es entsprechend:
- Abschaltungsentscheidung: Management-Freigabe für die Abschaltung, basierend auf dem Validierungsbericht
- Letzte vollständige Sicherung: Einen finalen Export aus dem Altsystem als Archiv, falls später doch noch Fragen auftauchen
- Kündigung beim Anbieter: Schriftlich, unter Berücksichtigung der Kündigungsfristen
- Bestätigung der Datenlöschung: Fordere vom Anbieter eine schriftliche Bestätigung, dass deine Daten gelöscht wurden. Das ist nicht nur Best Practice, sondern eine DSGVO-Anforderung, wenn personenbezogene Daten betroffen sind.
- Dokumentation im ISMS: Die Migration selbst ist eine Änderung am ISMS und gehört ins Change Management
Checkliste für die Abschaltung
- Management hat die Abschaltung freigegeben
- Finaler Archiv-Export liegt gesichert vor (separater Speicherort, nicht im neuen System)
- Alle Benutzer sind informiert und haben Zugang zum neuen System
- Zugangsdaten für das Altsystem sind deaktiviert
- Kündigung ist beim Anbieter eingegangen und bestätigt
- Datenlöschungsbestätigung vom Anbieter liegt vor
- SSO/SAML-Integration zum Altsystem ist entfernt
- Dokumentation der Migration ist im ISMS abgelegt
- IT-Asset-Inventar ist aktualisiert (Altsystem entfernt, Neusystem eingetragen)
Migrationscheckliste: Komplett
Diese Checkliste fasst alle Phasen zusammen und dient als Projektplan:
Vorbereitung (Wochen 1-2)
- Datenbestand im Altsystem vollständig inventarisiert
- Export-Fähigkeiten des Altanbieters geprüft und dokumentiert
- Testexport durchgeführt und gegen Inventar geprüft
- Lücken im Export identifiziert und Workarounds geplant
- Kündigungsfristen und Übergangszeitraum beim Altanbieter geklärt
- Zielsystem installiert und konfiguriert
- Benutzer im Zielsystem angelegt
Mapping und Bereinigung (Wochen 3-4)
- Feld-Mapping zwischen Alt- und Neusystem erstellt
- Skalentransformationen definiert
- Transformationsskript erstellt und getestet
- Datenbereinigung durchgeführt (Duplikate, veraltete Einträge)
- Liste der bewusst nicht migrierten Daten dokumentiert
Export und Import (Wochen 5-6)
- Vollständiger Export aus dem Altsystem
- Datentransformation durchgeführt
- Testimport mit Teilmenge erfolgreich
- Vollständiger Import durchgeführt
- Validierung bestanden (Anzahl, Stichproben, Verknüpfungen)
Parallelbetrieb (Wochen 7-14)
- Neues System als führendes System kommuniziert
- Täglicher Abgleich in Woche 1
- Wöchentlicher Abgleich ab Woche 2
- Korrekturen dokumentiert und durchgeführt
- Schulung der Benutzer im neuen System
Abschaltung (Woche 15)
- Management-Freigabe für Abschaltung
- Finaler Archiv-Export
- Kündigung beim Altanbieter
- Datenlöschungsbestätigung erhalten
- Migrationsdokumentation abgeschlossen
Häufige Fehler bei der ISMS-Migration
1. Zu spät exportieren
Wer erst nach der Kündigung versucht zu exportieren, steht unter Zeitdruck. Manche Anbieter löschen Daten bereits wenige Tage nach Vertragsende. Exportiere mindestens sechs Wochen vor der geplanten Abschaltung und prüfe den Export gründlich.
2. Auf PDF-Exporte vertrauen
Ein PDF-Report deiner Risikobewertung mag auf dem Bildschirm gut aussehen, aber er ist für die Migration wertlos. Du brauchst strukturierte, maschinenlesbare Daten. Wenn der Anbieter nur PDFs exportiert, frage nach CSV oder JSON, oder nutze die API.
3. Verknüpfungen ignorieren
Die eigentliche Stärke eines ISMS-Tools ist nicht die Datenhaltung, sondern die Verknüpfung: Welches Risiko betrifft welches Asset, welche Maßnahme adressiert welches Risiko. Wenn diese Verknüpfungen bei der Migration verloren gehen, hast du zwar alle Daten, aber keine Struktur. Das ist kaum besser als ein ISMS in Excel.
4. Keinen Parallelbetrieb einplanen
Die Versuchung ist groß, das Altsystem sofort abzuschalten, sobald der Import fertig ist. Das spart Geld, erzeugt aber ein Risiko: Wenn in den Wochen nach der Migration Probleme auftauchen, hast du keine Referenz mehr. Die vier bis acht Wochen Parallelbetrieb sind eine Versicherung, die sich lohnt.
5. Die Migration nicht als ISMS-Änderung behandeln
Die Migration deines ISMS ist selbst eine Änderung am ISMS. Sie gehört in dein Change Management, braucht eine Risikobewertung (was passiert, wenn Daten verloren gehen?) und muss dokumentiert werden. Ein Auditor wird dich danach fragen.
Sonderthema: Vendor Lock-in erkennen und vermeiden
Manche Cloud-Anbieter machen den Wechsel absichtlich schwer. Das nennt sich Vendor Lock-in, und es ist eines der stärksten Argumente für Self-Hosted-Lösungen. Typische Lock-in-Mechanismen:
- Proprietäre Datenformate: Daten werden in einem Format gespeichert, das nur der Anbieter lesen kann
- Eingeschränkte Exportfunktionen: Nur Teilexporte möglich, kritische Datentypen fehlen
- Keine API oder eingeschränkte API: Kein programmatischer Zugriff auf die eigenen Daten
- Vertragsklauseln: Datenlöschung unmittelbar nach Vertragsende, keine Übergangsfrist
- Langfristige Vertragsbindung: Kündigungsfristen von sechs oder zwölf Monaten
Bevor du dich für ein neues ISMS-System entscheidest, prüfe genau diese Punkte. Die Frage "Wie komme ich hier wieder raus?" ist genauso wichtig wie "Was kann das System?". In ISMS Lite liegen alle Daten in offenen Formaten auf deinem eigenen Server. Ein Export als JSON oder CSV ist jederzeit möglich, ohne Einschränkungen und ohne den Anbieter um Erlaubnis zu fragen. Die jährlichen Kosten starten bei 500 Euro, ohne Benutzerlimits und ohne Module, die nachgekauft werden müssen.
Nach der Migration: Laufender Betrieb
Die Migration ist abgeschlossen, das neue System läuft. Jetzt beginnt der Alltag. Zwei Dinge solltest du zeitnah angehen:
Backup-Strategie für das Self-Hosted-System
Was du in der Cloud nicht musstest, musst du jetzt selbst organisieren: die Datensicherung. Definiere ein Backup-Konzept für dein ISMS-System, das mindestens tägliche Sicherungen und monatliche Restore-Tests vorsieht. Das ISMS enthält geschäftskritische Daten, und ein Verlust wäre nicht nur ärgerlich, sondern ein Compliance-Problem.
Interne Dokumentation aktualisieren
Aktualisiere alle Referenzen auf das alte System: Verfahrensanweisungen, Schulungsunterlagen, IT-Dokumentation, Notfallhandbuch. Nichts ist verwirrender als Dokumentation, die auf ein System verweist, das es nicht mehr gibt.
Fazit
Eine ISMS-Migration von der Cloud zum eigenen Server ist ein Projekt, kein Wochenendausflug. Rechne mit acht bis fünfzehn Wochen von der ersten Bestandsaufnahme bis zur Abschaltung des Altsystems. Der Aufwand lohnt sich, wenn du danach ein System hast, dessen Daten dir gehören, dessen Kosten du kontrollierst und das verfügbar ist, wenn du es brauchst, nicht wenn der Anbieter es zulässt.
Weiterführende Artikel
- Self-Hosted vs. Cloud: Datensouveränität bei Compliance-Software
- Vom Excel-ISMS zum Tool: Migrationsleitfaden ohne Datenverlust
- ISMS-Software auswählen: Worauf es bei der Evaluation ankommt
- Change Management im ISMS: Änderungen sicher steuern
- Was kostet ein ISMS? Budget, Aufwand und ROI realistisch einschätzen