ES³ Self Assessment

Der European Sovereign Stack Standard (ES³) ist das digitale Souveränitätsprogramm von STACKIT. Er macht das sonst vage Konzept digitaler Souveränität objektiv messbar, in einem Markt, in dem “Sovereignty Washing” und vage Marketingversprechen verbreitet sind. Motor des Programms ist das Sovereignty Maturity Level (SML) Framework, ein auditierbares Bewertungsframework, dessen Kriterien von der unabhängigen Prüfgesellschaft BDO verifiziert wurden.

Die Arbeitsdefinition von Souveränität

ES³ definiert digitale Souveränität als die Fähigkeit, jederzeit aussteigen zu können — also einen Service zu beenden oder zu migrieren, ohne dabei an inakzeptablen rechtlichen, technischen, operativen oder Lieferketten-Abhängigkeiten zu scheitern. Souveränität ist keine Compliance-Pflicht, sondern Handlungsfähigkeit.

Das Framework folgt drei Leitprinzipien:

• Auditierbarkeit: Bewertungen müssen evidenzbasiert, nachvollziehbar und reproduzierbar sein.
• SML-Klassifizierung: Reifegrade werden anhand definierter Pflichtkontrollen je Stufe zugewiesen.
• Vergleichbarkeit: Ergebnisse sind zwischen Services und Anbietern sowie über die Zeit vergleichbar.

Die neun Souveränitätsdimensionen

Das SML-Framework baut auf den acht Souveränitätszielen des offiziellen EU Cloud Sovereignty Framework (CSF) auf und ergänzt eine neunte, zukunftskritische Dimension: Künstliche Intelligenz.

Seitlich wischen, um die ganze Tabelle zu sehen

ID	Dimension	Was bewertet wird
SML 1	Strategisch	Unternehmensführungsstruktur, Eigentümerabhängigkeiten, Transparenz der Eigentumsstrukturen und Aufsicht des Managements über Service-Substitution und Exit-Fähigkeit.
SML 2	Rechtlich & Jurisdiktion	Anwendbare Rechtsrahmen, geografische Verarbeitungsgrenzen und Rechtsschutz gegen extraterritoriale Ansprüche Dritter oder widersprüchliche Zugriffsanfragen.
SML 3	Daten	Kundengesteuerte Zugriffsverwaltung, Datenportabilität über Umgebungen hinweg, zweckgebundene Nutzungsbeschränkungen und langfristige kryptografische Resilienz.
SML 4	Operativ	Zuweisung der operativen Tagesverantwortung, Einschränkung und Auditierung privilegierter Zugriffe, autonome Incident Response und Disaster Recovery.
SML 5	Lieferkette	Transparenz von Subprozessoren und Softwarekomponenten (SBOM), Vendor-Risikomanagement, Minderung kritischer Abhängigkeiten und Vendor-Substitutions-Workflows.
SML 6	Technologie	Deployment innerhalb genehmigter geografischer Grenzen, Einsatz offener Standards gegen Vendor-Lock-in, Architekturtransparenz und Komponentenportabilität.
SML 7	Sicherheit & Compliance	Least-Privilege-Identitäts- und Zugriffskontrolle, Verschlüsselung über den gesamten Datenlebenszyklus, Kundeneinblick in Sicherheitslogs und Isolation risikoreicher operativer Aufgaben.
SML 8	Umweltverträglichkeit	Energieabhängigkeiten der Infrastruktur, Abhängigkeiten in der Lieferkette bei Hardware und Kühlung, Umweltrisikoplanung und Offenlegung von Nachhaltigkeitskennzahlen.
SML 9	KI	Unternehmerische Rechenschaftsmodelle, Erklärbarkeit von Systemen, Abhängigkeit von externen Softwareanbietern und Schutz von Trainingsdaten und Modellkomponenten.

Jede Dimension wird auf drei verpflichtenden Umsetzungsebenen bewertet, sodass eine Anforderung niemals allein auf dem Papier erfüllt ist:

• Ebene 1 — Vertraglich (Regulatorisch): vertragliche Regelungen und Zusicherungen, wie Service-Vereinbarungen, SLAs und rechtliche Vereinbarungen.
• Ebene 2 — Governance & Betrieb (Organisation): organisatorische Verantwortlichkeiten, Richtlinien, Verfahren und operative Prozesse.
• Ebene 3 — Technisch (Technologie): technische Umsetzung und Systemkonfiguration, wie Sicherheitsmaßnahmen, Konfigurationen und Automatisierung.

Die vier Sovereignty Maturity Levels

Seitlich wischen, um die ganze Tabelle zu sehen

Stufe	Kurzform	Beschreibung
1 Initial	Ad hoc, nicht standardisiert	Starke Abhängigkeit von externen Anbietern. Prozesse sind reaktiv, digitale Abhängigkeiten werden nicht gesteuert und sind nicht im Risikomanagement verankert.
2 Managed	Dokumentiert, regelbasiert	Digitale Abhängigkeiten sind identifiziert und im Risikomanagement dokumentiert. Erste Notfall- und Wiederherstellungspläne existieren, sind aber noch nicht vollständig getestet.
3 Advanced	Strukturiert, konsistent	Souveränität ist als strategisches Ziel verankert. Für jeden geschäftskritischen Service existiert mindestens eine alternative Bezugsoption oder ein dokumentierter Migrationspfad. Daten werden überwiegend innerhalb der EU/EWR verarbeitet.
4 Future-Proof	Optimiert, robust	Nahezu vollständige digitale Autonomie auf selbstbetriebener oder souverän kontrollierter Infrastruktur, offenen Standards und europäischen Lieferketten. Verbleibende Abhängigkeiten sind bewusst gewählt und jederzeit substituierbar.

Das Minimumprinzip

Der Gesamt-SML eines Service entspricht immer der niedrigsten Stufe über alle neun Dimensionen. Eine einzige Schwachstelle — vertraglich, prozessual oder technisch — begrenzt sofort das Gesamtergebnis. Stärken in einem Bereich können eine unerfüllte Pflichtkontrolle in einem anderen Bereich nicht ausgleichen, und einzelne Kontrollen werden niemals gewichtet oder numerisch bewertet. Souveränität ist immer nur so stark wie ihr schwächstes Glied.

Was bewertet wird — und wer verantwortlich ist

Bewertungsgegenstand ist immer die Kombination aus einem kundenseitigen Service und seinem Service-Anbieter, einschließlich der zugrunde liegenden Services, auf denen er aufbaut. Bevor die Bewertung beginnt, wird der Service anhand von Servicename, Service-Anbieter und Servicetyp (IaaS, PaaS, SaaS, Managed Service, KI-Service) klassifiziert. Der Servicetyp bestimmt nur, welche Kontrollen anwendbar sind — er hat keinen Einfluss auf den resultierenden Reifegrad.

Jede Kontrolle wird genau einem Control Scope zugeordnet, der festlegt, wer dafür verantwortlich ist:

Seitlich wischen, um die ganze Tabelle zu sehen

Scope	Abk.	Bedeutung für einen ISV
Underlying Service	US	Die Plattform, auf der du aufbaust — für einen Marketplace-ISV typischerweise STACKIT.
Service Provider	SP	Deine Organisation, die den Service entwickelt, betreibt und dafür verantwortlich ist.
Client-facing Service	CFS	Das konkrete Produkt, das du an deinen Kunden lieferst.

Diese Aufteilung vermeidet doppelte Audits und macht vererbte Nachweise prüfbar:

• Kontrollen auf SP-Ebene werden einmal bewertet und für alle deine Services übernommen.
• Kontrollen auf US-Ebene werden nicht von dir umgesetzt. Sie werden durch geeignete Nachweise des Plattformanbieters (Zertifikate, Audit-Berichte) abgedeckt und gelten als übernommen — das bedeutet, der Souveränitätsreifegrad der Plattform, auf der du aufbaust, prägt direkt, welche Stufe dein eigener Service erreichen kann.
• Kontrollen auf CFS-Ebene betreffen das konkrete Produkt, das du an deinen Kunden lieferst, und müssen für jeden Service einzeln bewertet werden — sie werden weder von deinen SP-Kontrollen noch von der zugrunde liegenden Plattform übernommen.

Anforderungen an Nachweise

Das Framework ist hierarchisch aufgebaut: Dimension → Kontrollziel → Kontrolle → Frage → Nachweis. Du antwortest auf der Kontroll-Ebene, nicht auf Fragenebene — die Fragen unter jeder Kontrolle im Katalog sind Beispiele, die die Absicht der Kontrolle verdeutlichen, keine Checkliste, die du separat abarbeiten musst. Jede Kontrolle wird binär beantwortet — “Ja”, “Nein” oder “N/A” — und mit einem Nachweis hinterlegt. Erfüllt ist eine Kontrolle nur, wenn sie mit “Ja” beantwortet ist und der Nachweis das auch stützt. Ein “N/A” wird nur akzeptiert, wo es objektiv nicht anwendbar und begründet ist.

Nachweise müssen spezifisch, überprüfbar und einer Kontrolle direkt zuordenbar sein. Pauschalaussagen wie “Dokumentation vorhanden” oder “Prozess existiert” reichen nicht aus; ein unabhängiger Dritter muss die Bewertung vollständig nachvollziehen können. Zulässige Nachweistypen:

• Verträge oder rechtliche Vereinbarungen
• Richtlinien und Verfahrensdokumentation
• Technische Konfigurationen oder Systemauszüge
• Audit-Berichte oder Zertifizierungen
• Architekturdiagramme

Approved Jurisdictions List (AJL)

Mehrere Kontrollen referenzieren die AJL, die auf Basis der rechtlichen Bewertung von STACKIT für Drittländer außerhalb der EU gepflegt wird. Sie unterscheidet eine Core Jurisdiction (EU/EWR und Schweiz) von einer Extended Jurisdiction (UK, Kanada, Israel, Andorra und Japan). Die Liste wird laufend aktualisiert.

Wie du bei der Bewertung vorgehst

Die gesamte Bewertungskette — Serviceklassifizierung, Bearbeitung des Kontrollkatalogs, Nachweis-Upload und Tracking deiner Zielstufe — ist im ES³ Tool abgebildet:

• ES³ Tool: es3.runs.onstackit.cloud

1. Bestimme deinen Ausgangspunkt: Nutze die ES³ Lens, das interaktive Presales-Bewertungstool, um vor der Festlegung auf eine Zielstufe eine sofortige Reifegrad-Scorecard für deine Infrastruktur zu erhalten.
2. Arbeite dich in Framework und Katalog ein: Lies die SML-Framework-Spezifikation und den herunterladbaren Framework-Katalog, in dem jede Bewertungsfrage mit ihrer Dimension, Kontrolle, Servicetyp, erwartetem Nachweistyp und Nachweisbeispiel aufgeführt ist.
3. Klassifiziere deinen Service: Lege Servicename, Service-Anbieter und Servicetyp fest. Diese Klassifizierung ist für die gesamte Bewertung bindend und bestimmt, welche Kontrollen gelten.
4. Sammle Nachweise je Kontrolle: Arbeite die anwendbaren Kontrollen entlang aller drei Umsetzungsebenen ab, beantworte jede direkt, und ordne genau einen spezifischen, überprüfbaren Nachweis zu, der deine Antwort belegt.
5. Stimme deine Zielstufe ab: Bespreche mit deinem STACKIT Partner Manager, welchen Reifegrad deine Lösung erreichen soll — er bestimmt über die separate SML-Mapping-Tabelle, welche Kontrollen für dich verpflichtend sind.
6. Validierung: Deine Ergebnisse werden im Rahmen des Technical Quality Gate überprüft — dort wird auch das Souveränitäts-Siegel für dein Marketplace-Listing vergeben.

• ES³-Programmübersicht: stackit.com — ES³
• SML-Framework-Spezifikation (PDF): Framework and Criteria Specification
• ES³ Tool: es3.runs.onstackit.cloud
• STACKIT Partner Portal: partner-portal.stackit.cloud

Versionierung und Gültigkeit

Der Kriterienkatalog und das SML-Mapping werden in einem jährlichen Zyklus überarbeitet, versioniert als [JAHR].[RELEASE].[PATCH]. Bestehende Zertifizierungen bleiben bis zu ihrem individuellen Ablaufdatum gültig, üblicherweise zwölf Monate — plane deine Neubewertung entsprechend.

Abschlusskriterien der Phase

• Framework geprüft: Dein Security- oder Technical Lead hat SML-Framework-Spezifikation und Kriterienkatalog durchgearbeitet.
• Service klassifiziert: Servicename, Service-Anbieter und Servicetyp für die Bewertung festgelegt.
• Bewertung abgeschlossen: Alle anwendbaren Kontrollen über die vertragliche, organisatorische und technische Ebene beantwortet, jeweils durch spezifische Nachweise belegt.
• Zielstufe abgestimmt: Der angestrebte Sovereignty Maturity Level ist mit deinem STACKIT Partner Manager festgelegt.
• Ergebnisse eingereicht: Bewertungsergebnisse zur Validierung im Technical Quality Gate übergeben.

Support & Kontakt

Für Fragen zu einzelnen Kontrollen, Souveränitätskriterien oder dem Bewertungstooling kontaktiere das ES³-Programmteam unter ES3@digits.schwarz. Für Fragen, wie die Bewertung in dein ISV-Onboarding passt, wende dich an das ISV-Factory-Team unter isv-sales@digits.schwarz.