Rethinking Service Level Agreements (SLAs) Across Europe’s Cloud-Edge Continuum
Inside the expert dialogue on creating cross-provider SLAs for Europe’s digital infrastructure
Setting up a smoothly running, secure network of cloud service providers across Europe needs binding regulations and a common understanding that everyone can build upon. In this interview, Yannick Heß, TUM-affiliated researcher and PhD candidate at TUM Campus Heilbronn, and Melanie Ludolph, Senior Associate at the European law firm Fieldfisher, share their visions of secure, cross-border Service Level Management between service customer uns cloud-edge-provider and explain how they are addressing these challenges within FACIS.
How are contracts – known as Service Level Agreements – typically structured in such multi-provider settings to ensure that the requirements of the main user are met?
Yannick Heß: In multi-provider environments, SLAs are often set up bilaterally between each service customer and provider. However, this fragmented approach makes it difficult for the main customer to oversee performance holistically or to enforce service expectations consistently. These challenges become even more pressing considering the currently prevalent entangled cloud service supply chains consisting of opaque and intertwined provider-subprovider relationships. These circumstances limit service customers’ oversight over sub-providers and, for example, data processing locations. In case service commitments are not met, this bears the risk of blame chains.
FACIS addresses this by providing an SLA Governance Framework for aligning SLAs across multiple providers. Instead of isolated individual contracts using unique terminology and service commitments, providers may adhere to a commonly defined taxonomy logic, enabling the alignment of service expectations at the ecosystem level. This helps the main user to notice dependencies and define clear escalation paths for the entire service chain – a key requirement for mission-critical applications.
Let’s dive deeper: What legal challenges arise in terms of responsibilities, liability, and guaranteeing service quality across such interconnected systems?
Melanie Ludolph: In multi-provider cloud environments, the main legal challenge is to allocate responsibilities. Generally speaking, a provider only commits to the performance of its own services performances and excludes any responsibility for performance issues caused by external factors. But in interconnected systems – which are becoming increasingly important – the services are closely intertwined and if one service fails, the dominating question becomes: Who is accountable, and to what extent?
What would an ideal SLA process look like – from negotiation to incident resolution – in a legally sound and operationally efficient way?
Melanie Ludolph: In an ideal world, the whole SLA process would be highly automated without the need for lengthy negotiations or human resource-intensive dispute resolution. This will not be achieved solely through digital contracting or smart contracts. Instead, standardization of definitions within SLAs and transparent, reliable monitoring and reporting mechanisms are key as well. The less ambiguity in relation to what has been agreed and how the service actually performed, the less the parties will need to argue.
FACIS develops both an SLA Governance Framework and an SLA Taxonomy. Why are these two components needed, and what exactly do we mean by them in practical terms?
Yannick Heß: The SLA Governance Framework and the SLA Taxonomy form the core of our approach to enable SLA alignment by providing the common ground for SLAs within a federated ecosystem.
The SLA Taxonomy provides a joint, structured vocabulary and logic for describing SLAs. Among other things, common service level commitments made by the providers are described. The taxonomy standardizes and harmonizes the components relevant to SLAs in multi-provider settings. It enables providers to align their individual notions of service level objectives, such as availability, latency, or resilience, and the corresponding service level indicators and metrics used for measurement.
The SLA Governance Framework, in turn, defines the rules of interaction. For example, who is responsible for specific tasks, who can escalate to whom in case of non-adherence to service commitments, how can remedies be claimed, and how can non-adherence be proven fairly?
Together, they form a common contractual foundation. This makes it possible to align providers around a shared understanding of service commitments from the outset. It enables subsequent machine-readability and automation of SLAs and their negotiation and orchestration for composed or cooperative services.
How does an SLA Governance Framework help define responsibilities and escalation paths more clearly, especially in the event of disruptions or incidents?
Melanie Ludolph: An SLA Governance Framework serves as the operational backbone of the contractual arrangement. While the SLA specifies the service and its quality that must be delivered, the Governance Framework explains exactly how delivery and problem resolution are managed across all parties – like the standards and rules for a secure service delivery.
In practice, this means that responsibilities are mapped to specific roles rather than to vague organizational entities. Escalation timelines are defined and binding, and all providers work with the same incident classification and prioritization system. This alignment ensures that, when disruptions occur, there is no debate about who should respond, in what order, or according to which standards. Legally, it also reduces disputes by creating an enforceable and common operational language that each party has committed to in advance.
In federated environments or data spaces, trust between parties is key. How can a jointly agreed SLA Framework support trust-building between otherwise autonomous actors?
Yannick Heß: Trust in federated environments depends on predictability, accountability, and transparency. A jointly agreed SLA Framework supports all three by introducing a shared conceptual understanding and operational contract that complements the technical interoperability – provided by Federation Architecture Patterns (FAPs) as collaboration blueprints.
The Taxonomy, for instance, provides information about key content that should be contained in an SLA to increase transparency. By aligning on how, for example, service latency commitments are measured and remedies are enforced in case of non-adherence to given commitments, participants can collaborate without relinquishing autonomy.
An SLA also clarifies who is (not) accountable for what and which responsibilities all involved actors have. Many SLAs that we analyzed, for instance, exclude service disruptions caused by natural disasters or other forms of force majeure. Deviations from agreed-upon service levels can then be handled more predictably and fairly.
A well-defined and transparent SLA fosters trust-building and enables scalable ecosystems where new providers and services can be onboarded swiftly, and customers can engage with these services trustfully, knowing that they operate under a known governance regime. In this way, the SLA Framework becomes an enabler for trust within a federated ecosystem, particularly in complex, cross-border, or sector-spanning collaborations.
How far have you progressed in the development of the SLA Governance Framework and Taxonomy? Are there early prototypes, test cases, or reference implementations? .
Yannick Heß: We have defined the core building blocks of the SLA Governance Framework, informed by workshops and roundtables with stakeholders from industry. The SLA Taxonomy is being iteratively developed in parallel, drawing on insights from the workshops and roundtables, industry SLAs, and the latest academic research related to SLAs in the Cloud-Edge Continuum. We focus on a clear taxonomic structure and semantic clarity, aligned with existing standards and best practices in SLA management (e.g., ISO/IEC). The first versions of the SLA Taxonomy and SLA Governance Framework will be presented to the public on 24 November 2025.
FACIS also explores machine-readable SLAs that computers can interpret and act on automatically. What role does automation play in SLA monitoring, enforcement, and even negotiation – and which technologies are involved?
Yannick Heß: Automation is essential to scale SLA Management in federated, real-time cloud-to-edge environments. Machine-readable SLAs enable the continuous monitoring of service levels to detect deviations and trigger predefined response workflows that automatically initiate troubleshooting, without requiring human intervention.
Automating the essential phases of SLA Management includes the following steps:
- Negotiation: Matching service offerings and customer requirements based on structured SLA descriptions. SLAs need to be defined and established, and the contract needs to be negotiated and (electronically) signed.
- Monitoring: Real-time surveillance and evaluation of agreed-upon metrics for key service level indicators for all service level objectives included in the negotiated SLAs.
- Enforcement: Execution of SLAs involves triggering the remediation or escalation mechanisms formulated for the case of non-adherence to service level commitments (e.g., failover, alerts, contractual renegotiation).
- Reporting: SLAs must be evaluated, potential penalties calculated, and billing must occur.
There are several key technologies involved in making SLAs machine-readable and allowing for automated SLA management, including but not limited to:
- Formal Languages to describe and specify agreements and commitments in a machine-readable way, such as Web Service Level Agreement (WSLA) language, Web Service Agreement Specification (WS-Agreement), or SLA languages such as SLAng, SLAC, RBSLA, CSLA, SLALOM.
- Ontologies for SLAs (e.g., SLA*, SSLA, Q-SLA, OTRA) that foster SLA automation by enabling automated reasoning and, thus, for example, the composition of SLAs for joint services from individual services’ SLAs.
- Monitoring Tools for automated monitoring of cloud service performance and metrics measurement. A variety of tools exist in the market, like Grafana.
Nevertheless, automation of SLA management is still more research-driven than actual practice. So far, we are not aware of many companies that have already automated their SLA management.
How do you ensure these automated SLAs remain interoperable across platforms and providers?
Yannick Heß: Interoperability is achieved through formalization, standardization, and harmonization. For instance, formal languages and ontologies provide a basic set of rules, terms, and tools that can be used to set up SLAs in various domains. The FACIS SLA Taxonomy similarly ensures that SLA descriptions follow a standard semantic model. At the same time, the SLA Governance Framework represents the legal framework for SLA contracts, defining the responsibilities of all involved actors and the rules of interaction.
Both deliverables are platform-agnostic. Additionally, as FACIS encourages free and open-source software (FOSS) principles, the SLA Taxonomy and the SLA Governance Framework will be made available to the public for usage and alignment in a FOSS manner.
You recently conducted workshops with cloud consumers and providers. What are the most common conflicts or mismatches between stakeholder expectations? And what are your key takeaways from these discussions?
Melanie Ludolph: One recurring challenge is that key contractual terms are interpreted differently by different stakeholders. For example, liability allocation is an area where assumptions diverge – customers may believe their main provider is accountable for the full service chain, while the provider’s contractual obligations extend only to its own segment. Transparency in performance reporting also varies, with some providers offering only periodic reports where customers expect near-real-time data. The main takeaway is that these mismatches are rarely the result of bad faith; they are usually a consequence of inconsistent definitions and a “lost in translation” phenomenon between various stakeholders. Establishing clear common terminology, agreed escalation paths, and binding coordination mechanisms would resolve many of these issues before they escalate.
How can companies adopt the FACIS’ SLA deliverables in practice? Can they gradually integrate it into their workflows, or would this require a complete contractual and procedural overhaul?
Yannick Heß: FACIS provides implementation guides, sample clauses, and blueprints to support this adoption. For example, the SLA Taxonomy is accompanied by recommendations regarding key aspects of SLAs and SLA Management in federated ecosystems and settings with multiple providers and services. Companies can use the Taxonomy and compare their SLAs with the key dimensions that we derived. The goal of the general FACIS project is to enable uptake without friction – especially for small and medium-sized enterprises (SMEs) and public sector actors with limited legal or technical capacity.
What is your long-term vision? If SLA Governance Frameworks become widely adopted, how might digital ecosystems evolve in the next 6- 10 years?
Yannick Heß: In the long term, the SLA Governance Framework can become an invisible infrastructure seamlessly embedded in how digital services are negotiated, monitored, and evolve in federated ecosystems and the Cloud-Edge Continuum. This would enable:
- Self-managed, resilient ecosystems, where services adapt dynamically to meet automatically negotiated and enforced SLAs and their requirements
- Cross-sector reuse of digital service modules, even for highly regulated sectors, from manufacturing to mobility to healthcare
- Lower transaction costs and faster time-to-market for innovative digital products
- Trust-by-design, reducing the need for extensive legal negotiations in multi-provider setups
Ultimately, digital ecosystems could operate trustworthily and reliably, governed by transparent SLAs. This lays the foundation for a truly sovereign European digital space, where innovation can be scaled without being constrained by trust or compliance barriers. Yet, there is still a long way to go, and FACIS will provide the first mechanisms to pave the way.
