--- title: "Digitale Souveränität: SaaS-Risiken senken" lang: de type: blog canonical: https://www.arocom.de/blog/digitale-souveraenitaet-praktisch alternate: https://www.arocom.de/en/blog/digital-sovereignty-practical author: "Axel Roth" published: 2026-10-31 last_updated: 2026-10-31 --- # Digitale Souveränität: SaaS-Risiken senken Digitale Souveränität bedeutet im Mittelstand nicht Autarkie, sondern Handlungsfähigkeit, wenn ein Anbieter Preise, Bedingungen oder den Dienst selbst ändert. Praktisch wird sie über vier Hebel: eine Exit-Strategie pro kritischem Dienst mit getestetem Datenexport, klare Datenhoheit über Speicherort und Verschlüsselung, der gezielte Einsatz von Open Source dort, wo Wechselkosten sonst zu hoch werden, und EU-Hosting für besonders sensible Daten. Der richtige Maßstab ist nicht maximale Unabhängigkeit von allem, sondern bewusste Abhängigkeit mit bekanntem Ausweg. Anfangen solltet ihr mit einer kurzen Liste eurer drei kritischsten Dienste. ## Digitale Souveränität praktisch: SaaS-Abhängigkeiten abbauen "Digitale Souveränität" klingt nach Standortpolitik und großen Reden. Im Maschinenraum eines mittelständischen Unternehmens ist sie etwas sehr Bodenständiges: die Fähigkeit, handlungsfähig zu bleiben, wenn ein Software-Anbieter etwas tut, das euch nicht passt. Er verdreifacht den Preis. Er streicht ein Feature, auf dem ein Prozess aufbaut. Er verkauft das Unternehmen, oder er stellt den Dienst ein. Genau das ist in den letzten Jahren oft genug passiert, dass es keine Schwarzmalerei mehr ist, sondern eine Planungsannahme. Souveränität heißt deshalb nicht, alles selbst zu betreiben. Sie heißt, jede Abhängigkeit bewusst einzugehen und für jede einen Ausweg zu kennen. Dieser Standpunkt zeigt vier Hebel, mit denen das praktisch gelingt, ohne in Autarkie-Romantik zu verfallen. ## Kein Alles-oder-nichts Vorab eine Klarstellung, weil die Debatte oft ins Grundsätzliche kippt. Das Ziel ist nicht, jeden Cloud-Dienst zu verbannen und alles auf eigene Server zu holen. Für die meisten mittelständischen Unternehmen wäre das teurer, langsamer und riskanter als die Abhängigkeit, die es vermeiden soll. Software als Dienst hat gute Gründe: weniger Betrieb, schnellere Updates, planbare Kosten. Der nützliche Maßstab ist ein anderer. Er fragt nicht "eigen oder fremd", sondern "Was kostet uns der Ausstieg, und wie schnell ginge er?". Ein Dienst, aus dem ihr in zwei Wochen mit euren Daten wieder heraus seid, ist eine kalkulierbare Abhängigkeit. Ein Dienst, der eure Daten in einem geschlossenen Format hält und ohne den ihr keine Woche arbeiten könnt, ist ein Klumpenrisiko, ganz gleich wie gut er heute läuft. ## Hebel 1: Exit-Strategie vor dem Einstieg Die wirksamste Maßnahme kostet vor Vertragsabschluss am wenigsten und später am meisten, wenn man sie versäumt hat. Klärt für jeden kritischen Dienst, bevor ihr ihn einführt, drei Dinge: Bekommen wir unsere Daten vollständig wieder heraus, in welchem Format, und haben wir den Export einmal echt getestet? Der letzte Punkt ist der, an dem es scheitert. Viele Anbieter versprechen einen Export, und der liefert dann eine unbrauchbare Datei, der die Verknüpfungen fehlen, oder ein Format, das kein anderes System lesen kann. Ein Export, den ihr nicht einmal in ein Zielsystem zurückgespielt habt, ist ein Versprechen, keine Exit-Strategie. Testet ihn im ersten Betriebsjahr einmal, solange der Druck klein ist. Haltet das Ergebnis fest. Diese eine Übung verschiebt das Machtverhältnis bei der nächsten Preisrunde spürbar. ## Hebel 2: Datenhoheit klären Bei jedem Dienst, der eure Daten verarbeitet, sollten drei Antworten schriftlich vorliegen. Wo liegen die Daten geografisch? Wer kann technisch darauf zugreifen, auch beim Anbieter? Und sind sie so verschlüsselt, dass ein Zugriff ohne euren Schlüssel ins Leere läuft? Das ist keine reine Compliance-Übung für den Datenschutzbeauftragten. Datenhoheit entscheidet im Ernstfall, ob ihr wechseln könnt und ob ein Anbieterwechsel oder eine Insolvenz euch kalt erwischt. Daten, die in der EU liegen, deren Zugriff geregelt ist und die ihr verschlüsselt vorhaltet, sind nicht nur datenschutzfreundlicher. Sie sind auch leichter zu retten, wenn ein Anbieter ausfällt. Wo besonders sensible Daten verarbeitet werden, lohnt der Blick auf den Speicherort als eigenes Kriterium der Wahl, wie ihn unser Wissen-Artikel zum [Hosting wählen](https://www.arocom.de/wissen/drupal/hosting-waehlen) für die technische Seite durchgeht. ## Hebel 3: Open Source dort, wo Wechselkosten sonst explodieren Open Source ist kein Selbstzweck und keine Gesinnungsfrage. Es ist ein Werkzeug gegen genau eine Gefahr: dass die Wechselkosten so hoch werden, dass ein Wechsel praktisch unmöglich wird. Bei quelloffener Software gehört euch im Zweifel der Code und das Datenmodell. Ihr könnt den Anbieter wechseln, ohne das System zu wechseln, oder den Betrieb selbst übernehmen. Das lohnt sich nicht überall. Für eine Standard-Office-Suite ist die proprietäre Lösung oft die vernünftige Wahl. Für die Systeme aber, die euer Geschäft ausmachen und eure wertvollsten Daten halten, also Website, Kundenverwaltung oder eine zunehmend auch KI-gestützte Wissensbasis, ist die Frage nach dem offenen Fundament berechtigt. Hier entscheidet sie über eure Verhandlungsposition für die nächsten zehn Jahre. Auch bei KI gilt das: Die wirtschaftlich wichtige Frage ist, wem die Integrationsschicht zwischen Modell und euren Systemen gehört, ein Punkt, den unser Beitrag [Make or Buy bei KI-Lösungen](https://www.arocom.de/blog/make-or-buy-ki-loesungen) vertieft. ## Hebel 4: EU-Hosting für die sensiblen Fälle Der vierte Hebel ist der gezielteste. Nicht alles muss in der EU liegen, aber das Sensible sollte. Personenbezogene Daten, Geschäftsgeheimnisse und alles, was unter besondere Aufsicht fällt, gehören auf Infrastruktur, die einem klaren und euch bekannten Rechtsrahmen unterliegt. Das ist heute kein Komfortverzicht mehr: Europäische Anbieter und EU-Regionen großer Cloud-Plattformen sind ausgereift und für die meisten Anwendungsfälle wettbewerbsfähig. Wichtig ist die juristisch saubere Einordnung, damit hier niemand falsche Sicherheit verkauft. Ein Serverstandort in der EU ist eine notwendige, aber keine hinreichende Bedingung. Entscheidend ist zusätzlich, welchem Recht der Anbieter als Unternehmen unterliegt und wer auf die Daten zugreifen kann. Diese Frage gehört in den Vertrag und zu eurem Datenschutzbeauftragten, nicht in eine Marketingfolie. ## Die vier Hebel im Überblick | Hebel | Kernfrage | Erster Schritt | | --- | --- | --- | | Exit-Strategie | Bekommen wir unsere Daten vollständig und brauchbar wieder heraus? | Export im ersten Betriebsjahr einmal echt testen und Ergebnis festhalten | | Datenhoheit | Wo liegen die Daten, wer kann zugreifen, sind sie verschlüsselt? | Drei Antworten pro Dienst schriftlich einholen | | Open Source | Gehören uns Code und Datenmodell der geschäftskritischen Systeme? | Frage beim nächsten Auswahlprozess als Kriterium setzen | | EU-Hosting | Unterliegt das Sensible einem klaren, bekannten Rechtsrahmen? | Sensible Daten identifizieren und Speicherort vertraglich klären | ## Der erste Schritt für diese Woche Souveränität entsteht nicht aus einem Grundsatzbeschluss, sondern aus einer Liste. Schreibt eure drei kritischsten Dienste auf, also jene, ohne die ihr keine Woche arbeiten könntet. Notiert pro Dienst eine einzige Zahl: Wie viele Wochen bräuchtet ihr, um mit euren Daten zu einem anderen Anbieter zu wechseln? Schon das Schätzen dieser Zahl zeigt, wo euer größtes Klumpenrisiko liegt. Wenn ihr diese Liste in eine belastbare Reihenfolge bringen und für den kritischsten Dienst eine echte Exit-Strategie aufsetzen wollt, ordnen wir das in einem [Zukunfts-Check](https://www.arocom.de/zukunfts-check) gemeinsam ein. Lieber direkt sprechen? Ihr erreicht uns über die [Kontaktseite](https://www.arocom.de/kontakt).