--- title: "ES³ Self Assessment" description: "The European Sovereign Stack Standard (ES³) and its SML framework make digital sovereignty measurable across nine dimensions and four maturity levels — this is what an ISV is assessed against." sidebar: label: "ES3 Self Assessment" order: 7 attrs: data-icon: check source_url: "https://framework.stackit.cloud/isv/es3-self-assessment/" source_file: "docs/isv/es3-self-assessment.mdx" --- The **European Sovereign Stack Standard (ES³)** is STACKIT's digital sovereignty program. It makes the otherwise vague concept of digital sovereignty objectively measurable, in a market where "sovereignty washing" and vague marketing promises are common. Its operational engine is the **Sovereignty Maturity Level (SML) Framework**, an auditable assessment framework whose criteria have been verified by the independent auditing firm BDO. The framework follows three guiding principles: - **Auditability**: assessments must be evidence-based, comprehensible, and reproducible. - **SML classification**: maturity levels are assigned based on defined mandatory controls per level. - **Comparability**: results are comparable between services and providers, and over time. ## The Nine Sovereignty Dimensions The SML framework builds on the eight sovereignty objectives of the official **EU Cloud Sovereignty Framework (CSF)** and adds a ninth, future-critical dimension: Artificial Intelligence. | ID | Dimension | What it assesses | | ----- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | SML 1 | Strategic | Corporate governance architecture, ownership dependencies, transparency of ownership structures, and executive oversight of service substitution and exit readiness. | | SML 2 | Legal & Jurisdictional | Applicable legal frameworks, geographic processing boundaries, and legal protection against extraterritorial third-party claims or conflicting access requests. | | SML 3 | Data | Customer-controlled access management, cross-environment data portability, purpose-bound usage constraints, and long-term cryptographic resilience. | | SML 4 | Operational | Allocation of day-to-day operational responsibility, restriction and auditing of privileged access, autonomous incident response, and disaster recovery. | | SML 5 | Supply Chain | Transparency of subprocessors and software components (SBOM), vendor risk governance, critical dependency mitigation, and vendor substitution workflows. | | SML 6 | Technology | Deployment within approved geographic boundaries, adoption of open standards against vendor lock-in, architectural transparency, and component portability. | | SML 7 | Security & Compliance | Least-privilege identity and access control, lifecycle data encryption, customer visibility into security logs, and isolation of high-risk operational tasks. | | SML 8 | Environmental Sustainability | Infrastructure energy dependency profiles, hardware and cooling supply-chain exposure, environmental risk planning, and sustainability metric disclosure. | | SML 9 | AI | Corporate accountability models, system explainability, reliance on external software providers, and protection of training data and model components. | Each dimension is assessed on **three mandatory implementation levels**, so a requirement is never satisfied on paper alone: - **Level 1 — Contractual (Regulatory)**: contractual regulations and assurances, such as service agreements, SLAs, and legal arrangements. - **Level 2 — Governance & Operations (Organization)**: organizational responsibilities, policies, procedures, and operational processes. - **Level 3 — Technical (Technology)**: technical implementation and system configuration, such as security measures, configurations, and automation. ## The Four Sovereignty Maturity Levels | Level | Short form | Description | | ------------------ | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1 Initial** | Ad hoc, not standardized | Heavy reliance on external providers. Processes are reactive, digital dependencies are not managed and not embedded in risk management. | | **2 Managed** | Documented, rule-based | Digital dependencies are identified and documented in risk management. Initial contingency and restoration plans exist, but are not yet fully tested. | | **3 Advanced** | Structured, consistent | Sovereignty is anchored as a strategic objective. At least one alternative sourcing option or a documented migration path exists for every business-critical service. Data is predominantly processed within the EU/EEA. | | **4 Future-Proof** | Optimized, robust | Near-complete digital autonomy on self-operated or sovereign-controlled infrastructure, open standards, and European supply chains. Remaining dependencies are deliberate and substitutable at any time. | ## What Is Assessed — and Who Is Responsible The object of assessment is always the combination of a **client-facing service and its service provider**, including the underlying services it is built on. Before the assessment starts, the service is classified by Service Name, Service Provider, and Service Type (IaaS, PaaS, SaaS, Managed Service, AI Service). The Service Type determines only which controls are applicable — it has no influence on the resulting maturity level. Every control is assigned to exactly one **Control Scope**, which defines who is responsible for it: | Scope | Abbr. | Meaning for an ISV | | -------------------------- | ----- | ------------------------------------------------------------------------------------------ | | **Underlying Service** | US | The platform you build on — for a Marketplace ISV, typically STACKIT. | | **Service Provider** | SP | Your organization, which develops, operates, and is accountable for the service. | | **Client-facing Service** | CFS | The specific product you deliver to your customer. | This split exists to prevent duplicate audits and to make inherited capabilities auditable: - Controls at **SP** level are assessed once and inherited across all of your services. - Controls at **US** level are not implemented by you. They are covered by suitable evidence from the platform provider (certificates, audit reports) and are considered inherited — which means the sovereignty maturity of the platform you build on directly shapes the level your own service can reach. - Controls at **CFS** level apply to the specific product you deliver to your customer and must be assessed individually for each service — they are neither inherited from your SP-level controls nor from the underlying platform. ## Evidence Requirements The framework is hierarchical: **Dimension → Control Objective → Control → Question → Evidence**. You answer at the **Control** level, not the question level — the questions listed underneath each control in the catalogue are illustrative example questions that help you interpret its intent, not a separate checklist to work through. Each control is answered binary — "Yes", "No", or "N/A" — and backed by evidence; a control counts as fulfilled only when it is answered "Yes" and the evidence substantiates it. An "N/A" is accepted only where it is objectively not applicable and justified. Evidence must be specific, verifiable, and directly assignable to a control. Blanket statements such as "documentation available" or "process exists" are not sufficient; an independent third party must be able to fully comprehend the assessment. Permissible evidence types: - Contracts or legal agreements - Policies and procedural documentation - Technical configurations or system extracts - Audit reports or certifications - Architecture diagrams ## How to Approach the Assessment The entire assessment process chain — service classification, working through the control catalogue, uploading evidence, and tracking your target level — is mapped in the **ES³ Tool**: - **ES³ Tool**: es3.runs.onstackit.cloud {/* prettier-ignore */} 1. **Determine your starting point**: Use the **ES³ Lens**, the interactive presales assessment tool, to get an instant maturity scorecard for your infrastructure before committing to a target level. 2. **Study the framework and catalogue**: Read the SML Framework specification and the downloadable framework catalogue, in which every assessment question is listed with its dimension, control, service type, expected evidence type, and evidence example. 3. **Classify your service**: Fix Service Name, Service Provider, and Service Type. This classification is binding for the entire assessment and determines which controls apply. 4. **Collect evidence per control**: Work through the applicable controls along all three implementation levels, answer each one directly, and assign exactly one piece of specific, verifiable evidence to substantiate your answer. 5. **Agree your target level**: Discuss the maturity level your solution should carry with your STACKIT Partner Manager — it determines which controls are mandatory for you via the separate SML mapping table. 6. **Validation**: Your results are reviewed as part of the [Technical Quality Gate](/isv/technical-quality-gate-and-certification/), which is also where the sovereignty seal shown on your Marketplace listing is established. - **ES³ program overview**: stackit.com — ES³ - **SML Framework specification (PDF)**: Framework and Criteria Specification - **ES³ Tool**: es3.runs.onstackit.cloud - **STACKIT Partner Portal**: partner-portal.stackit.cloud ## Phase Completion Criteria - [ ] **Framework Reviewed**: SML framework specification and criteria catalogue reviewed by your security or technical lead. - [ ] **Service Classified**: Service Name, Service Provider, and Service Type fixed for the assessment. - [ ] **Assessment Completed**: All applicable controls answered across the contractual, organizational, and technical levels, each backed by specific evidence. - [ ] **Target Level Agreed**: The intended Sovereignty Maturity Level is aligned with your STACKIT Partner Manager. - [ ] **Results Submitted**: Assessment results handed over for validation in the [Technical Quality Gate](/isv/technical-quality-gate-and-certification/). ## Support & Contact For questions on specific controls, sovereignty criteria, or the assessment tooling, contact the ES³ Program team at `ES3@digits.schwarz`. For questions about how the assessment fits into your ISV onboarding, reach out to the ISV Factory team at `isv-sales@digits.schwarz`.