Datensouveränität im ISMS: Warum dein Risikoregister nicht in die Cloud gehört

Dein ISMS weiß mehr über dich als jedes andere System

Dein ERP kennt deine Umsätze. Dein CRM kennt deine Kunden. Aber dein ISMS kennt deine Schwächen. Es dokumentiert jede Schwachstelle, die du gefunden hast, jedes Risiko, das du akzeptiert hast, jeden Vorfall, der dir passiert ist, und jede Maßnahme, die du noch nicht umgesetzt hast. Es enthält die komplette Landkarte deiner Angriffsfläche.

Wenn jemand wissen will, wo dein Unternehmen verwundbar ist, muss er nicht dein Netzwerk scannen. Er muss nur dein Risikoregister lesen.

Genau diese Daten vertrauen viele Unternehmen einer SaaS-Plattform an, die auf Servern läuft, die sie nicht kontrollieren, betrieben von einem Anbieter, dessen Geschäftsbedingungen sich jederzeit ändern können, in einer Jurisdiktion, die möglicherweise nicht den eigenen Datenschutzanforderungen entspricht.

Dieser Artikel erklärt, warum Datensouveränität gerade bei ISMS-Software keine Nebensache ist, sondern eine strategische Entscheidung mit Auswirkungen auf Compliance, Sicherheit und langfristige Kosten.

Was bedeutet Datensouveränität?

Datensouveränität beschreibt die Fähigkeit, die volle Kontrolle über die eigenen Daten zu behalten: wo sie gespeichert werden, wer Zugriff hat, welchem Recht sie unterliegen und wie sie verarbeitet werden. Es geht nicht darum, Cloud-Technologie grundsätzlich abzulehnen. Es geht darum, bewusst zu entscheiden, welche Daten du welchem Dritten anvertraust und welche du besser unter eigener Kontrolle behältst.

Für die meisten Geschäftsanwendungen ist Cloud-Hosting eine sinnvolle Entscheidung. E-Mail, Projektmanagement, Collaboration - all das funktioniert in der Cloud hervorragend. Aber es gibt eine Kategorie von Daten, bei denen Kontrollverlust nicht nur ärgerlich, sondern potenziell geschäftsschädigend ist. Und ISMS-Daten gehören zu dieser Kategorie.

Die DSGVO spricht in Erwägungsgrund 7 vom Recht natürlicher Personen, die Kontrolle über ihre Daten zu behalten. Datensouveränität überträgt diesen Gedanken auf Unternehmensdaten: Du entscheidest, nicht der Anbieter.

Die Kronjuwelen: Was dein ISMS tatsächlich enthält

Um zu verstehen, warum ISMS-Daten besonders schützenswert sind, hilft ein Blick auf die konkreten Inhalte. Ein vollständig betriebenes ISMS nach ISO 27001 enthält unter anderem:

Risikoregister und Risikobewertungen. Jedes identifizierte Risiko mit Eintrittswahrscheinlichkeit, Schadenshöhe und aktuellem Behandlungsstatus. Wer dieses Register liest, kennt jeden Schwachpunkt deines Unternehmens - inklusive der Risiken, die du bewusst akzeptiert hast, weil Budget oder Ressourcen fehlen.

Schwachstellen und Maßnahmenstatus. Dein Schwachstellenmanagement dokumentiert offene Schwachstellen, priorisiert nach Kritikalität, zusammen mit dem geplanten Behebungsdatum. Eine Liste offener Schwachstellen in fremden Händen ist eine Einladung.

Incident-Details. Jeder Sicherheitsvorfall wird dokumentiert: Was ist passiert, welche Systeme waren betroffen, welche Daten waren exponiert, wie wurde reagiert. Incident-Reports enthalten technische Details, die weit über das hinausgehen, was extern kommuniziert wird.

Audit-Berichte und Feststellungen. Interne Audits und externe Prüfberichte dokumentieren, wo dein ISMS die Anforderungen noch nicht erfüllt. Audit-Feststellungen sind im Grunde eine priorisierte To-do-Liste deiner Sicherheitslücken.

Berechtigungskonzepte und Netzwerkpläne. Dein Berechtigungskonzept zeigt, wer auf welche Systeme Zugriff hat. Zusammen mit Netzwerkplänen ergibt sich ein detailliertes Bild deiner Infrastruktur.

Maßnahmenpläne und Umsetzungsstatus. Was geplant ist, aber noch nicht umgesetzt. Diese Information ist besonders brisant, weil sie zeigt, wo du weißt, dass du verwundbar bist, aber noch nichts dagegen getan hast.

Zusammengefasst: Dein ISMS enthält das vollständige Sicherheitsprofil deines Unternehmens. Stärken und Schwächen, inklusive Timeline. Es gibt kein einzelnes System, das einen umfassenderen Überblick über deine Angriffsfläche bietet.

Das Paradox: Sicherheitsdaten in unsicheren Händen

Hier entsteht ein Widerspruch, der im Alltag oft übersehen wird. Du baust ein ISMS auf, um die Informationssicherheit deines Unternehmens systematisch zu verbessern. Du dokumentierst deine Schwachstellen, deine Risiken und deine Maßnahmen. Und dann lädst du all das in ein Cloud-Tool hoch, das selbst eine potenzielle Schwachstelle darstellt.

Das ist kein theoretisches Szenario. Compliance-Plattformen sind attraktive Ziele, weil sie aggregierte Sicherheitsinformationen vieler Unternehmen an einem Ort bündeln. Ein erfolgreicher Angriff auf eine SaaS-ISMS-Plattform liefert nicht die Daten eines Unternehmens, sondern die Sicherheitsprofile Hunderter oder Tausender Organisationen auf einen Schlag.

Die Frage lautet nicht: Ist der Cloud-Anbieter unsicher? Die meisten großen Anbieter betreiben professionelle Infrastruktur mit hohen Sicherheitsstandards. Die Frage lautet: Willst du das Risiko tragen, dass ein Dritter - unabhängig davon, wie gut er ist - über deine sensibelsten Sicherheitsdaten verfügt?

Beim Audit wird diese Frage konkret. Der Auditor fragt: Wo werden die ISMS-Daten verarbeitet? Wer hat Zugriff? Welchem Recht unterliegen sie? Hast du einen Auftragsverarbeitungsvertrag? Wie stellst du sicher, dass die technischen und organisatorischen Maßnahmen des Anbieters dein Schutzniveau erreichen? Mit Self-Hosting lauten die Antworten: bei uns, wir, deutschem Recht, nicht nötig, wir kontrollieren sie selbst.

Cloud Act und Schrems II: Das Jurisdiktionsproblem

Der Cloud Act (Clarifying Lawful Overseas Use of Data Act) ist ein US-Bundesgesetz aus dem Jahr 2018. Es verpflichtet US-Unternehmen, gespeicherte Daten auf Anordnung amerikanischer Behörden herauszugeben - unabhängig davon, wo auf der Welt diese Daten physisch gespeichert sind. Ein europäischer Serverstandort schützt nicht vor einem Cloud-Act-Zugriff, solange der Betreiber ein US-Unternehmen oder ein Tochterunternehmen eines US-Konzerns ist.

Das betrifft alle großen Cloud-Anbieter: AWS, Azure, Google Cloud. Und es betrifft jede SaaS-Plattform, die auf der Infrastruktur dieser Anbieter läuft. Wenn dein ISMS-Tool auf AWS in Frankfurt gehostet wird, aber der Anbieter seinen Hauptsitz in den USA hat, greift der Cloud Act.

Das Schrems-II-Urteil des EuGH aus dem Jahr 2020 verschärfte die Lage zusätzlich. Der Europäische Gerichtshof erklärte das EU-US Privacy Shield für ungültig, weil die US-Überwachungsgesetze kein angemessenes Schutzniveau für personenbezogene Daten von EU-Bürgern bieten. Der Nachfolger, das EU-US Data Privacy Framework von 2023, wird von Datenschutzexperten kritisch gesehen und könnte erneut gekippt werden.

Was bedeutet das für dein ISMS? Die Daten in deinem Risikoregister sind zwar nicht zwingend personenbezogen, aber sie sind hochsensibel. Die DSGVO-Logik zeigt die Richtung: Wenn selbst personenbezogene Daten nicht ohne Weiteres in den Einflussbereich US-amerikanischer Gesetze gelangen sollen, wie rechtfertigst du dann die Speicherung deiner kompletten Sicherheitsarchitektur in genau diesem Einflussbereich?

Dabei geht es nicht um Paranoia. Es geht um eine nüchterne Risikoanalyse. Die Wahrscheinlichkeit, dass eine US-Behörde ausgerechnet dein Risikoregister anfordert, mag gering sein. Aber die Möglichkeit besteht, und allein das Bestehen dieser Möglichkeit erzeugt ein Compliance-Problem. Dein Auditor wird fragen: Hast du dieses Risiko bewertet? Was ist deine Risikobehandlung? Und "das passiert schon nicht" ist keine akzeptable Antwort in einem ISMS, das auf systematischem Risikomanagement basiert.

Auch europäische Regulierungsbehörden werden aufmerksamer. Die französische Datenschutzbehörde CNIL hat bereits mehrfach gegen den Einsatz von US-Cloud-Diensten in sensiblen Bereichen entschieden. Die deutsche Datenschutzkonferenz empfiehlt bei besonders schutzbedürftigen Daten, europäische Anbieter ohne US-Muttergesellschaft zu bevorzugen. ISMS-Daten fallen eindeutig in die Kategorie "besonders schutzbedürftig".

Für NIS2-regulierte Unternehmen kommt ein weiterer Aspekt hinzu. Die NIS2-Richtlinie fordert in Artikel 21 angemessene Maßnahmen zum Risikomanagement, einschließlich der Sicherheit der Lieferkette. Ein Cloud-basiertes ISMS-Tool ist Teil deiner Lieferkette. Du musst nachweisen können, dass dieser Dienstleister dein Sicherheitsniveau nicht gefährdet. Bei einem Self-Hosted-System entfällt diese Nachweispflicht.

Vendor Lock-in: Die schleichende Abhängigkeit

Vendor Lock-in wird bei der Auswahl von Compliance-Software oft unterschätzt, weil er sich langsam aufbaut. Am Anfang wirkt SaaS unkompliziert: Account anlegen, Daten eingeben, loslegen. Aber mit jedem Monat, in dem du Risiken dokumentierst, Maßnahmen trackst und Audit-Berichte erstellst, wächst die Abhängigkeit.

Nach zwei Jahren stecken hunderte Stunden Arbeit im System. Dein gesamtes Risikoregister, deine Schutzbedarfsfeststellung, deine Maßnahmenhistorie, deine Audit-Berichte, deine Schulungsnachweise. Ein Wechsel bedeutet nicht nur ein neues Tool einzurichten, sondern diese gesamte Historie zu migrieren.

Und genau hier wird es problematisch. Die meisten SaaS-Anbieter bieten keinen vollständigen Datenexport an. Du bekommst vielleicht ein CSV mit den Risikotiteln, aber nicht die verknüpften Maßnahmen, nicht die Audit-Historie, nicht die Dokumentenversionen. Die Daten gehören dir rechtlich, aber praktisch kommst du nicht an sie heran.

Was passiert in diesen Szenarien?

Der Anbieter erhöht den Preis. SaaS-Preise steigen regelmäßig, typischerweise 5 bis 15 Prozent pro Jahr. Nach fünf Jahren zahlst du deutlich mehr als zu Beginn, und ein Wechsel ist aufwändig, weil du Jahre an Daten migrieren musst. Du bist faktisch gefangen.

Der Anbieter wird aufgekauft. Startups im Compliance-Bereich werden häufig von größeren Anbietern übernommen. Die Produktstrategie ändert sich, Features werden eingestellt oder in teurere Pakete verschoben. Deine Workflows funktionieren plötzlich nicht mehr.

Der Anbieter stellt den Dienst ein. Nicht jedes SaaS-Unternehmen überlebt. Wenn dein ISMS-Anbieter den Betrieb einstellt, brauchst du kurzfristig eine Alternative - mitten in einem laufenden ISMS-Betrieb, möglicherweise kurz vor einem Audit.

Der Anbieter ändert die Nutzungsbedingungen. Neue Datenschutzrichtlinien, geänderte Speicherorte, erweiterte Analysen deiner Daten. Du stimmst zu oder verlierst den Zugang.

Self-Hosting eliminiert diese Risiken nicht vollständig - auch bei On-Premise-Software gibt es Lizenzmodelle und Update-Zyklen. Aber du behältst die Kontrolle über deine Daten, dein Tempo und deine Infrastruktur. Wenn du unzufrieden bist, exportierst du deine Daten und wechselst, ohne dass ein Anbieter dir den Zugang sperren kann.

TCO-Vergleich: SaaS vs. Self-Hosted über 5 Jahre

Das Argument für SaaS lautet oft: geringere Anfangsinvestition, kein eigener Server, kein IT-Aufwand. Das stimmt für die ersten Monate. Über einen Zeitraum von fünf Jahren sieht die Rechnung anders aus.

Nehmen wir ein konkretes Beispiel: Ein Unternehmen mit 150 Mitarbeitern, einem ISB und vier weiteren ISMS-Nutzern (IT-Leiter, CISO, QM-Beauftragter, Datenschutzbeauftragter).

Szenario A: Typisches SaaS-ISMS-Tool

Dabei sind externe Beraterkosten für die Datenmigration bei einem eventuellen Wechsel nicht eingerechnet. Auch nicht das Risiko, dass der Anbieter Nutzerlizenzen auf Pro-Kopf-Basis abrechnet und sich die Kosten bei zehn statt fünf Nutzern verdoppeln.

Szenario B: Self-Hosted mit ISMS Lite

Der Unterschied ist erheblich: Faktor 5 bis 7 über fünf Jahre. Und dabei ist ISMS Lite nicht limitiert auf eine bestimmte Nutzeranzahl. Ob fünf oder fünfzehn Personen im System arbeiten, der Preis bleibt gleich.

Natürlich hat Self-Hosting Anforderungen: Du brauchst jemanden, der einen Docker-Container starten und ein Backup konfigurieren kann. Bei einem Unternehmen mit 150 Mitarbeitern und einer IT-Abteilung ist das Alltagsgeschäft, keine Sonderleistung.

On-Premise als Compliance-Vorteil beim Audit

Im Audit wird die Datenhaltung regelmäßig hinterfragt. Und hier wird Self-Hosting vom vermeintlichen Nachteil zum handfesten Vorteil.

Nachweisführung bei ISO-27001-Audits

Ein ISO-27001-Auditor prüft unter anderem die Einhaltung von Annex A.5.23 (Cloud-Dienste). Wenn dein ISMS-Tool selbst ein Cloud-Dienst ist, musst du nachweisen, dass du den Anbieter bewertet hast, dass ein AVV existiert, dass die TOMs dokumentiert sind und dass ein Exit-Plan vorliegt. Das sind vier zusätzliche Nachweispunkte, die bei Self-Hosting komplett entfallen.

Stattdessen dokumentierst du: Das ISMS-Tool läuft auf Server X in unserem Rechenzentrum (oder bei unserem deutschen Hoster Y), die Daten werden verschlüsselt gespeichert, die Backups liegen auf einem separaten System, der Zugriff ist auf die ISMS-Rollen beschränkt. Fertig. Kein Drittanbietermanagement, kein Lieferantenbewertungsbogen, keine zusätzliche Risikobetrachtung.

Nachweisführung bei NIS2-Prüfungen

NIS2 fordert in Artikel 21 Absatz 2d die Sicherheit der Lieferkette. Jeder Cloud-Dienst, den du nutzt, ist Teil dieser Lieferkette und muss bewertet werden. Ein Self-Hosted-Tool steht unter deiner eigenen Kontrolle und ist damit kein Lieferkettenglied, sondern ein internes System.

Datenschutz und DSGVO

Wenn dein ISMS personenbezogene Daten verarbeitet - und das tut es spätestens, wenn Incident-Reports Namen von Mitarbeitern enthalten - brauchst du bei einem Cloud-Anbieter einen AVV, eine Datenschutz-Folgenabschätzung und eine Bewertung der internationalen Datentransfers. Bei Self-Hosting im eigenen Haus verarbeitest du die Daten als Verantwortlicher selbst, ohne Auftragsverarbeiter.

Backup und Datenhoheit

Du bestimmst die Backup-Strategie. Du weißt, wo die Backups liegen, wie oft sie erstellt werden und wie schnell ein Restore möglich ist. Bei einem SaaS-Anbieter musst du darauf vertrauen, dass seine Backup-Strategie deinen Anforderungen entspricht. Testen kannst du das in der Regel nicht.

Was Self-Hosting nicht ist: Eine Absage an moderne Technologie

Ein häufiges Missverständnis: Self-Hosting bedeute, Server im Keller zu betreiben und auf Updates zu verzichten. Das war vielleicht 2010 so. Heute bedeutet Self-Hosting einen Docker-Container auf einem V-Server oder in der eigenen Infrastruktur zu deployen. Das dauert weniger als eine Stunde und erfordert keine Spezialkenntnisse über das hinaus, was jede IT-Abteilung im Mittelstand mitbringt.

Moderne Self-Hosted-Software ist nicht weniger komfortabel als SaaS. Du bekommst ein Webinterface, automatische Updates (die du kontrolliert einspielen kannst), Backups auf Knopfdruck und eine API für Integrationen. Der einzige Unterschied: Die Daten bleiben bei dir.

Self-Hosting und Cloud schließen sich auch nicht gegenseitig aus. Du kannst dein ISMS-Tool bei einem deutschen Hoster als V-Server betreiben. Die Infrastruktur ist dann "in der Cloud" im technischen Sinne, aber unter deiner Kontrolle. Der entscheidende Punkt ist nicht, ob der Server physisch in deinem Gebäude steht, sondern ob du die administrative Kontrolle über System und Daten hast.

Es hilft, die Unterscheidung so zu denken: Bei SaaS mietest du ein fertiges Apartment - der Vermieter hat den Zweitschlüssel und kann die Hausordnung ändern. Bei Self-Hosting auf einem V-Server mietest du einen Rohbau und richtest ihn selbst ein. Der Hoster stellt die Infrastruktur, aber er hat keinen Zugriff auf deine Anwendung und deine Daten. Du entscheidest, wer reinkommt.

Checkliste: Datensouveränität bei der ISMS-Tool-Auswahl

Wenn du ein ISMS-Tool evaluierst, prüfe diese Punkte zur Datensouveränität:

• Datenstandort: Wo werden die Daten physisch gespeichert? Welchem Recht unterliegen sie?
• Zugriff Dritter: Kann der Anbieter auf deine Daten zugreifen? Unter welchen Bedingungen?
• Cloud Act: Unterliegt der Anbieter oder sein Infrastruktur-Provider dem US Cloud Act?
• Datenexport: Kannst du alle Daten jederzeit vollständig exportieren? In welchem Format?
• Datenportabilität: Sind die exportierten Daten in einem offenen Format, das du in ein anderes System importieren kannst?
• Vendor Lock-in: Was passiert, wenn du den Anbieter wechseln willst? Welcher Aufwand entsteht?
• Preisbindung: Gibt es eine vertragliche Preisbindung? Wie oft wurde der Preis in der Vergangenheit erhöht?
• Exit-Strategie: Was passiert, wenn der Anbieter den Betrieb einstellt? Wie schnell kannst du migrieren?
• AVV und TOMs: Liegt ein AVV vor? Sind die TOMs des Anbieters dokumentiert und geprüft?
• Backup-Kontrolle: Kannst du die Backup-Frequenz und den Speicherort selbst bestimmen?
• Verschlüsselung: Wer hält die Schlüssel? Kann der Anbieter die Daten entschlüsseln?
• Audit-Recht: Hast du das Recht, den Anbieter zu auditieren oder Audit-Berichte einzusehen?

Häufige Einwände gegen Self-Hosting - und die Antworten

"Wir haben keine Kapazität für Serverbetrieb"

Ein Docker-Container ist kein Serverbetrieb im klassischen Sinne. Die Einrichtung dauert unter einer Stunde, Updates sind ein einzelner Befehl, Backups laufen automatisiert. Der laufende Aufwand liegt bei wenigen Stunden pro Quartal. Wenn dein Unternehmen einen Drucker warten kann, kann es einen Docker-Container betreiben.

"SaaS ist sicherer, weil der Anbieter Experten hat"

Die Sicherheit der Infrastruktur ist bei großen Cloud-Anbietern tatsächlich auf hohem Niveau. Aber Infrastruktur-Sicherheit ist nur ein Aspekt. Die Frage der Datensouveränität - wer hat Zugriff, welchem Recht unterliegen die Daten, was passiert bei einem Breach beim Anbieter - beantwortet die beste Infrastruktur nicht.

"Cloud-Lösungen sind immer aktuell"

Self-Hosted-Software kann genauso aktuelle Sicherheitspatches erhalten wie SaaS. Der Unterschied: Du entscheidest, wann du ein Update einspielst, nachdem du es in einer Testumgebung geprüft hast. Bei SaaS wird das Update eingespielt, ob du bereit bist oder nicht.

"Wir wollen kein eigenes Rechenzentrum"

Brauchst du auch nicht. Ein V-Server bei einem deutschen Hoster für 5 bis 15 Euro pro Monat reicht für ein ISMS-Tool mit fünf bis fünfzehn Nutzern vollständig aus. Du mietest Rechenleistung, aber du kontrollierst das System.

Wie ISMS Lite Datensouveränität umsetzt

ISMS Lite wurde von Anfang an als Self-Hosted-Lösung konzipiert, weil die Gründer genau die in diesem Artikel beschriebenen Probleme in der Praxis erlebt haben: Kunden, deren Risikoregister bei US-Cloud-Anbietern lag. Unternehmen, die nach einer Preiserhöhung nicht wechseln konnten, weil kein vollständiger Export möglich war. ISBs, die im Audit erklären mussten, warum ihre Schwachstellendokumentation bei einem Drittanbieter ohne AVV gespeichert war.

Docker-basiert. ISMS Lite läuft als Docker-Container auf jedem Linux-Server, Windows-Server oder in einer bestehenden Container-Infrastruktur. docker compose up und das System ist betriebsbereit. Keine komplexe Installation, keine Abhängigkeiten, keine Datenbankkonfiguration.

Eigener Server, eigene Regeln. Die Daten liegen dort, wo du es bestimmst. Auf einem eigenen Server im Rechenzentrum, bei einem deutschen Hoster deiner Wahl oder auf einer VM in deinem Unternehmensnetzwerk. Du kontrollierst den Zugang, die Firewall-Regeln und die Verschlüsselung.

Vollständiger JSON-Export. Alle Daten lassen sich jederzeit als strukturiertes JSON exportieren: Risiken, Maßnahmen, Assets, Audits, Dokumente. Kein Lock-in, keine proprietären Formate. Wenn du wechseln willst, nimmst du deine Daten mit.

Unbegrenzte Nutzer. Ob drei oder dreißig Nutzer im System arbeiten - der Preis bleibt gleich. Kein Per-Seat-Pricing, das die Kosten mit jeder zusätzlichen Person in die Höhe treibt.

Transparente Preise. ab 500 Euro pro Jahr oder als Einmalkauf für 2.500 Euro. Keine versteckten Kosten, keine Add-ons, keine "Enterprise-Tier" für Features, die eigentlich Standard sein sollten.

Häufige Fehler bei der Datensouveränität im ISMS

"Europäischer Serverstandort" mit Datensouveränität verwechseln. Viele Anbieter werben mit "Daten in Deutschland" oder "EU-Hosting". Das klingt gut, aber wenn der Anbieter ein US-Unternehmen ist oder US-Infrastruktur nutzt, schützt der Serverstandort nicht vor dem Cloud Act. Entscheidend ist nicht, wo der Server steht, sondern wer die rechtliche Kontrolle über die Daten hat.

Keinen Exit-Plan haben. Viele Unternehmen steigen in ein SaaS-ISMS ein, ohne vorher zu prüfen, wie ein Ausstieg aussehen würde. Teste den Datenexport bevor du produktive Daten einpflegst, nicht erst, wenn du wechseln musst.

Die Klassifizierung der ISMS-Daten vergessen. ISMS-Daten werden in der eigenen Klassifizierungsrichtlinie oft übersehen. Risikoregister, Schwachstellenlisten und Audit-Berichte gehören mindestens in die Kategorie "Vertraulich". Wenn deine Klassifizierung vorschreibt, dass vertrauliche Daten nicht bei Dritten gespeichert werden dürfen, darfst du kein Cloud-ISMS nutzen, ohne eine Ausnahme zu dokumentieren und zu begründen.

TOMs des SaaS-Anbieters nicht prüfen. Ein AVV allein reicht nicht. Du musst die technischen und organisatorischen Maßnahmen des Anbieters kennen und bewerten. Wie verschlüsselt er die Daten? Wer hat intern Zugriff? Wie sieht das Incident-Management aus? Viele Unternehmen unterschreiben den AVV und legen ihn ab, ohne die TOMs jemals gelesen zu haben.

Self-Hosting als "alles selbst machen" missverstehen. Self-Hosting bedeutet nicht, dass du den kompletten Stack selbst betreibst. Du nutzt eine fertige Anwendung und bestimmst lediglich, wo sie läuft. Der Entwicklungsaufwand liegt beim Hersteller, die Betriebsverantwortung für die Infrastruktur bei dir. Das ist weniger Aufwand, als viele befürchten.

Fazit

Datensouveränität bei ISMS-Software ist keine ideologische Frage und kein Technik-Purismus. Es ist eine Risikomanagement-Entscheidung. Du dokumentierst deine Schwachstellen, deine Risiken und deine Maßnahmenlücken, und du solltest die Kontrolle darüber nicht aus der Hand geben. Self-Hosting gibt dir diese Kontrolle zurück: über den Speicherort, über den Zugriff, über die Kosten und über den Zeitpunkt, an dem du gehst, wenn etwas nicht mehr passt.

Weiterführende Artikel

• Self-Hosted vs. Cloud: Datensouveränität bei Compliance-Software
• Risikobewertung im ISMS: Methodik, Matrix und Praxisbeispiel
• ISMS-Software auswählen: Worauf es bei der Evaluation ankommt
• Was kostet ein ISMS? Budget, Aufwand und ROI realistisch einschätzen
• Build vs. Buy: Eigenentwicklung oder fertige Lösung für ISMS-Prozesse