Datensouveränität

Datensouveränität beginnt nicht bei der Technologie.
Sondern bei Entscheidungen.

• Wir haben unsere Daten unter Kontrolle, wir nutzen Power BI.
• Wir sind maximal souverän, eigenes Rechenzentrum.
• Die nutzen doch AWS, das kann gar nicht souverän sein.

In Gesprächen mit Kunden hören wir solche und ähnliche Sätze oft. Wir haben uns mit ihnen auseinandergesetzt.

Das Ergebnis: Souveränität entscheidet sich nicht beim Anbieter-Logo, sondern Schicht für Schicht bei Architektur, Exit-Strategie und echten Abhängigkeiten.

Genau hier setzt diese Checkliste an. Sie schafft Klarheit darüber, wo Sie heute stehen, und läuft dabei konsequent auf eine Frage zu, die am Ende über alles entscheidet: Kann ich morgen noch frei ent- scheiden?

Die Checkliste beleuchtet die entscheidenden Faktoren:

• Verständnis und Definition
• Regulatorischer Rahmen
• Architektur Schicht für Schicht
• Kann ich morgen noch frei entscheiden?

Dieser Selbst-Check hilft Ihnen dabei, Ihren Stand übersichtlich einzuschätzen und daraus direkt kon- krete nächste Schritte abzuleiten.

100 % Souveränität ist dabei kein realistisches Ziel. Bewusste Kontrolle schon!

So nutzen Sie unseren Selbst-Check:

Lesen Sie jede Frage. Kreuzen Sie nur an, wenn die Aussage heute zutrifft. Zählen Sie am Ende Ihre Kreuze. Abschnitte, in denen Sie wenige oder keine Kreuze gesetzt haben, verlangen besondere Aufmerksamkeit!

Hinweis: Dieser Selbst-Check ersetzt keine Rechtsberatung, sondern gibt eine praktische Standortbestimmung.

01 Definition & Verständnis

• Es gibt eine gemeinsame Definition von Datensouveränität im Unternehmen: Kontrolle über Speicherort, Zugriff und Technologie, unabhängig von einzelnen Anbietern.
• Fachbereich und IT sprechen die gleiche Sprache beim Thema Souveränität: Gibt es einen Konsens zwischen Geschwindigkeit und Governance?
• AI Governance: Sie kennen Ihre Abhängigkeiten zu AI-Agenten, Sprachmodellen oder AI-Integrationen und habt diese dokumentiert sowie reguliert.
• Souveränität wird als Haltung verstanden, nicht als einmaliges Projekt.

02 Regulatorischer Rahmen

• US Cloud Act (2018): Ihnen ist bekannt, dass US-Behörden auf Daten zugreifen können, auch wenn sie in der EU liegen.
• NIS-2 (Okt. 2024): Cybersicherheits- und Meldepflichten für kritische Infrastrukturen/Lieferketten sind für Sie eingeordnet.
• EU Data Act (2024): Wechselhindernisse sind laut Gesetz verboten, das Recht auf Datenweitergabe ist in Ihren Verträgen berücksichtigt.
• DORA (Jan. 2025): ICT-Risikomanagement, Drittparteiensteuerung, Resilienz & Exit sowie Nachweispflichten sind, falls für Sie relevant, umgesetzt.
• EU Tech Sovereignty (2025): Sie verfolgen die Initiative (europäische Cloud fördern, US-Abhängigkeiten reduzieren, offene Standards) und ihre Wirkung auf Ihre Anbieterwahl.

03 Schicht für Schicht: Ihre Architektur

• Sichtbarkeit: Sie wissen, welches Tool und welche Oberfläche Ihre Nutzer tatsächlich sehen (z. B. Power BI, eigenes Rechenzentrum, Cloud-Konsole).
• Architektur: Die darunterliegenden Abhängigkeiten (Tenant-Verwaltung, Identity Provider, Lizenzmodell) sind dokumentiert.
• Exit-Strategie: Sie wissen, ob ein Wechsel technisch und vertraglich überhaupt möglich ist. Nutzen Sie offene Datei-Formate, Infrastructure-as-Code, getestete Migrationen und standardisierten Code?
• Abhängigkeit: Preise, Tenant-Regeln, Lizenzen und rechtliche Rahmenbedingungen liegen nicht komplett außerhalb Ihres Einflusses oder sind gut dokumentiert.

04 Kann ich morgen noch frei entscheiden?

• Kritikalität: Wie stark wäre Ihr Betrieb betroffen, wenn die Daten nicht verfügbar oder fehlerhaft wären? Sind die Auswirkungen gering (= wenig kritisch) oder hätte das spürbare betriebliche oder regulatorische Folgen (= kritisch)?
• Kontrollverlust: Ist es für Sie akzeptabel, bei kritischen Daten die Kontrolle zu verlieren, oder müssen Sie jederzeit selbst handlungsfähig bleiben?
• Exit-Fähigkeit: Ist ein Wechsel des Anbieters nicht nur geplant und dokumentiert, sondern technisch möglich und mindestens einmal praktisch getestet?
• Wechselkosten: Wissen Sie, welche Kosten bei einem Wechsel tatsächlich entstehen, statt sich auf grobe Schätzungen zu verlassen?

1. Abhängigkeiten bewusst machen
• Welche Prozesse hängen an welchem Tool?
• Wo sind heute schon Flaschenhälse?
• Welche Komponenten sind stark gebündelt?
2. Risiko realistisch einschätzen
• Kritikalität der Daten bestimmen.
• Regulatorische Anforderungen prüfen.
• Wechselkosten ehrlich berechnen.
3. Klein starten, dranbleiben
• Einen Prozess wählen, der Mehrwert zeigt.
• 100 % Souveränität ist kein realistisches Ziel.
• Architektur regelmäßig evaluieren.

Auf Wunsch interpretieren wir Ihr Ergebnis gemeinsam, priorisieren Maßnahmen und leiten konkrete nächste Schritte ab. Schreiben Sie uns an: team@qunis.de