--- title: "ES³ Self Assessment" description: "Der European Sovereign Stack Standard (ES³) und sein SML-Framework machen digitale Souveränität über neun Dimensionen und vier Reifegrade messbar — daran wird ein ISV bewertet." sidebar: label: "ES3 Self Assessment" order: 7 attrs: data-icon: check source_url: "https://framework.stackit.cloud/de/isv/es3-self-assessment/" source_file: "docs/de/isv/es3-self-assessment.mdx" --- 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. 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. | 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 | 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. | ## 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: | 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 ## 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 {/* prettier-ignore */} 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](/de/isv/technical-quality-gate-and-certification/) ü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 ## 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](/de/isv/technical-quality-gate-and-certification/) ü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`.