ES³ Self Assessment

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 working definition of sovereignty

ES³ defines digital sovereignty as the ability to walk away from the table at any time — the ability to terminate or migrate a service without unacceptable legal, technical, operational, or supply-chain dependencies. Sovereignty is not a compliance obligation; it is the ability to act.

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.

Swipe sideways to see the whole table

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

Swipe sideways to see the whole table

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.

The minimum principle

The overall SML of a service always corresponds to the lowest level across all nine dimensions. A single weakness — contractual, procedural, or technical — immediately caps the overall result. Strengths in one area cannot compensate for an unfulfilled mandatory control in another, and individual controls are never weighted or scored numerically. Sovereignty is only as strong as its weakest link.

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:

Swipe sideways to see the whole table

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

Approved Jurisdictions List (AJL)

Several controls reference the AJL, maintained on the basis of STACKIT’s legal assessment for third countries outside the EU. It distinguishes a Core Jurisdiction (EU/EEA and Switzerland) from an Extended Jurisdiction (UK, Canada, Israel, Andorra, and Japan). The list is subject to future updates.

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

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, 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

Versioning and validity

The criteria catalogue and the SML mapping are revised on an annual cycle, versioned as [YEAR].[RELEASE].[PATCH]. Existing certifications remain valid until their individual expiration date, usually twelve months — plan your reassessment accordingly.

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.

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.