1. In welchem Betreibermodell läuft die Plattform?
„Wir nutzen Plattform X" ist keine Architekturaussage. Zwischen den Betriebsvarianten liegen Welten:
- SaaS beim Hersteller — schnell, gepflegt, aber Betrieb und Datenzugriff liegen beim Anbieter.
- Dedizierte EU-Instanz — vertraglich und technisch abgegrenzt, aber weiterhin unter Kontrolle des Herstellers.
- Eigenbetrieb / On-Premise — maximale Kontrolle, maximale eigene Betriebsverantwortung.
Die Frage ans Verfahren: Wurde das Betreibermodell ausgeschrieben — oder hat es sich aus dem Produkt ergeben? Der zweite Fall ist der häufige. Und der teure.
2. Unter wessen Rechtsraum steht der, der zugreifen kann?
Der Serverstandort beruhigt, entscheidet aber nicht allein. Solange ein Konzern unter US-Jurisdiktion den Betrieb kontrolliert, bleibt der Zugriff durch US-Behörden eine offene Flanke — unabhängig davon, ob das Rechenzentrum in Frankfurt oder Virginia steht. Auch „vom Internet getrennte" Varianten laufen auf dem Software-Stack des Herstellers: Lizenzen, Updates, Support. Getrennt vom Netz heißt nicht getrennt vom Hersteller.
Die Frage ans Verfahren: Ist der Rechtsraum des Betreiberpersonals und der Supportkette dokumentiert — nicht nur der der Server?
3. Welche Daten landen wirklich in der Plattform?
Bei Servicemanagement-Plattformen heißt es oft beruhigend: „Da laufen ja nur Tickets, keine Fachdaten." Das unterschätzt zwei Dinge.
Erstens enthalten Tickets Realität: Namen, Systeme, Störungsbilder, interne Abläufe. Zweitens — und gewichtiger — gehört zu modernem Servicemanagement eine Konfigurationsdatenbank (CMDB): die digitale Landkarte der gesamten IT. Welche Systeme existieren, wie sie verbunden sind, wo Änderungen wirken. Für einen Angreifer wie für einen fremden Staat ist diese Landkarte wertvoller als manches Fachverfahren. Betriebsdaten sind Kronjuwelen zweiter Ordnung — und gehören in die Datenklassifizierung wie alles andere.
Die Frage ans Verfahren: Wurde die CMDB als schutzbedürftiges Asset klassifiziert — mit Konsequenzen für Betreibermodell und Zugriffskonzept?
4. Wie sieht der Exit aus — konkret, nicht als Klausel?
Jeder Vertrag hat eine Ausstiegsklausel. Fast kein Projekt hat einen Ausstiegsplan. Der Unterschied zeigt sich erst, wenn es ernst wird: Sind Datenmodelle exportierbar? Sind Workflows dokumentiert oder nur konfiguriert? Was kostet die Migration in Monaten und Millionen — und wurde diese Zahl je aufgeschrieben?
Souveränität ist eine Exit-Option. Eine souveräne Cloud ist genau so souverän wie die Fähigkeit ihres Betreibers, den Plattformanbieter zu wechseln. Wenn diese Fähigkeit nicht existiert, ist das Label Marketing.
Die Frage ans Verfahren: Liegt ein bezifferter, geprüfter Exit-Plan vor — als Zuschlagskriterium, nicht als Anhang?
5. Wer entscheidet im Prozess — und wie wird das nachgewiesen?
Die letzte Frage verlässt die Plattformebene und betrifft jedes Verfahren, in dem Software Entscheidungen vorbereitet: Wo genau liegt die Grenze zwischen maschineller Vorbereitung und menschlicher Entscheidung? Wird jede Freigabe dokumentiert? Kann ein Bürger, ein Gericht, ein Prüfer den Entscheidungsweg nachvollziehen?
Diese Entscheidungsarchitektur — ich baue sie nach dem Ausbildungsprinzip — ist die einzige Souveränitätsebene, die keine Plattform der Welt mitliefert. Sie muss ausgeschrieben, designt und abgenommen werden wie ein Bauwerk.
Das Fazit für Vergabestellen
Keine dieser fünf Fragen verbietet eine US-Plattform. Alle fünf verhindern, dass „Souveränität" ein Etikett bleibt, das im Betrieb niemand einlösen kann.
Wer sie ins Verfahren schreibt — als Eignungs- und Zuschlagskriterien, mit Nachweispflicht — bekommt entweder belastbare Antworten oder ehrliche Absagen. Beides ist ein besseres Ergebnis als ein souverän etikettiertes Projekt, das die Fragen erst beantwortet, wenn der Wechsel unbezahlbar geworden ist.
Quellen und weiterführende Links
Alle Links geprüft am 4. August 2026. Externe Inhalte können sich ändern.