EU Data Act – Focus on Cloud Services: what is “functional equivalence” … and is it necessary?


In the second Law-Now in our cloud services series on the proposed EU Data Act (the “Act”), we focus on the concept of functional equivalence. One of the aims of the Act is to remove barriers to access to data for both consumers and businesses. In pursuance of this in the context of cloud services, the Act introduces new rules to facilitate switching between providers of cloud services and other data processing services.

The requirements relating to functional equivalence are a key component of the cloud switching obligations and, as currently drafted, have the potential to significantly impact cloud service providers and their customers. In this Law-Now, we discuss the concept of functional equivalence, how it is used in the Act and the impact it could have on cloud service providers and their customers.

This article references the latest available draft, the Czech Presidency third compromise text, published 8th December 2022 as its reference point. The amendments proposed by members of the European Parliament adopt a different approach in certain respects.

What is switching?

Recital 72 indicates that switching between data processing services encompasses all conditions and actions that are necessary for a customer to terminate a contractual agreement relating to a data processing service (which is understood to apply to cloud services), to conclude one or multiple new contracts with different providers of data processing services, to port all its digital assets, including data, to the concerned other services providers and to continue to use them in the new environment (which could include the customer’s own on-premise environment and/or one or more other cloud service environments) while benefitting from functional equivalence. In this context the term ‘digital assets’ is used to refer to ‘elements in digital format’ that the customer has the right to use, ‘including data, applications, virtual machines and other manifestations of virtualisation technologies, such as containers.

Article 23 (Removing obstacles to effective switching between providers of data processing services) infers that the customer will retain control of and drive the switching activity.  Rather than requiring its original cloud service provider (“CSP”) to port digital assets it requires CSPs not to pose obstacles which inhibit customers doing so or from “maintaining functional equivalence of the service in the IT environment of the different provider or providers of data processing services covering the same service type”.

What is functional equivalence, and how is the term used?

Recital 72 defines functional equivalence as:

the maintenance of a minimum level of functionality in the environment of a new data processing service after the switching process, to such an extent that, in response to an input action by the user on core elements of the service, the destination service will deliver the same output at the same performance and with the same level of security, operational resilience and quality of service as the originating service at the time of termination of the contract’.

In essence this appears to be a requirement that the same performance level, standards and functional features of a solution will work in a different cloud environment. The Recital helpfully clarifies that services can only be expected to facilitate functional equivalence for the functionalities that both the originating and destination services offer. 

The Act also requires data processing service providers to remove existing obstacles (hurdles of a commercial, technical, contractual or organisational nature) and not impose new ones for customers wishing to switch to an on-premise system.  The newly proposed Article 28a appears to be aimed at extending these requirements to interoperability for the purposes of in-parallel use of data processing services.

While application of the concept of functional equivalence is intended to break down barriers and allow customers to switch more easily, the broad nature and some of the specific uses of the concept in the Act (as discussed below) have the potential to lead to unintended consequences for customers and cloud service providers alike. This has been recognised by some in the EU, with different definitions proposed, such as those which formed part of the amendments proposed by the European Parliament Committee on Internal Market and Consumer Protection, one of which read:

functional equivalence’ means a definition as agreed upon by a customer and provider of data processing services, or the maintenance of a minimum level of pre-defined functionality during the switching process, to such an extent that the service will deliver comparable minimum level functionality, such as the same output at the same performance and with the same level of security, operational resilience and quality of service as agreed at the time of termination of the contract, where both the original and destination service providers independently offer the same core functionality.’

This proposed change, justified as an attempt to clarify the concept while recognising it is unreasonable to make the originating CSP legally responsible for services outside their control, demonstrates a desire to improve the scope and application of the concept, and that thought has already begun as to how this might be possible.


Article 26 (Technical aspects of switching) imposes obligations on providers of data processing services before, during and after a customer decides to switch to another provider. The obligations to facilitate achievement of functional equivalence are, arguably, quite strong and have been the focus of a significant number of the debates, negotiations and proposed drafting changes during the legislative process. The most recent draft of Article 26 (1) states (strikeout and bold reflecting the most recent amendments):

Providers of data processing services that concern scalable and elastic computing resources limited to infrastructural elements such as servers, networks and the virtual resources necessary for operating the infrastructure, but that do not provide access to the operating services, software and applications that are stored, otherwise processed, or deployed on those infrastructural elements, shall ensure take all measures in their power, including in cooperation with the data processing service provider of the destination service, to facilitate that the customer, after switching to a service covering the same service type offered by a different provider of data processing services, enjoys functional equivalence in the use of the new destination service.

Similarly, Recital 74 indicates that data processing service providers should offer ‘all assistance and support that is required to make the switching process to a service of a different data processing service provider successful, effective and secure including in cooperation with the data processing service provider of the destination service’. It goes on to provides some further context in this regard, clarifying that the Act ‘does not require data processing service providers to develop new categories of services within or on the basis of the IT-infrastructure of different data processing service providers to guarantee functional equivalence in an environment other than their own systems’.

Functional equivalence and its associated obligations

The broad nature of the language relating to functional equivalence (whether amended or not from the original draft), is a key driver of the debate around the concept.  While the idea of helping customers to switch and maintain the same levels of service is a positive one, how that is best achieved, and the extent to which it can reasonably be achieved, merits further scrutiny.

Cloud services are an enabling technology, and an alternative to an on-premise solution. Customers select the service they want, based on its functionality and the other services and tools the CSP offers that can be leveraged. Each customer designs its own solution, choosing the features and functionality it wants when leveraging the cloud service to build its desired IT environment functionality. The built environment will inevitably evolve and may grow in capacity and complexity over time. The complexity and efficiency of the customer’s solution is a key determining factor in how easy and cost effective it is to switch to an alternative solution, or interface multiple solutions.  Arguably that is no different to the scenario where the originating environment is on-premise.

CSPs should not knowingly design their services in a way that blocks or impedes switching – e.g. by making it unnecessarily complicated, time-consuming or expensive. Depending on the nature of a particular service it may also be reasonable to require the supplying CSP to provide tools and a reasonable degree of information and guidance to facilitate switching. The provisions in relation to ensuring functional equivalence extend the Article 23 obligations, but their extent as drafted remains uncertain.

The proposed language could be interpreted as going far beyond merely requiring CSPs not to deliberately hamper (or to remove obstacles to) switching, or even to have due regard to the need for switching in the design of their services. As drafted it requires them to “take all measures in their power … to facilitate that the customer … enjoys functional equivalence in the use of the destination service …”.  The term “all measures in their power” is not defined, nor is it a term of art.  This could be interpreted as requiring CSPs to incur significant expenditure (both financially and in terms of human and other resources) in order to facilitate the move of a customer to another provider. Following on from this, if a CSP’s service design was subsequently found deficient in this regard the CSP could be exposed to material claims the risk of which was not reflected in the pricing of its services.  Presumably such an onerous outcome or interpretation is not the intention of the legislature, in which case changes are needed to clarify the extent of these obligations to make the position clear and give CSPs and their customers certainty.

What are the “measures” that the CSP is expected to take, what is the extent of the required assistance and support?  If this is simply intended to be a requirement that the CSP should provide tools, information and explanations as to how porting can be achieved, the language needs to be refined to make that clear and to avoid a possible construction that more is required. If more is required, its nature and extent need to be explained to avoid an uncertain potentially open-ended obligation requiring the provision of an unknown amount of professional services or changes to the original CSP’s service/infrastructure. As each customer choses/designs its originating service/on-premise IT environment, and has discretion in choosing each replacement or additional one, there’s clearly a strong argument that customers should have responsibility for ensuring their choices are appropriate. 

It is inevitable that work will be required to map the transfer process for data and other digital assets from the originating environment into the destination one(s).  The customer can elect to do that itself, or to engage a third party to do it – but given the complexity and effort inherent in that task are all driven by the customer’s design and choice of its services and environments, and the effort required will vary from customer solution to customer solution – it is logical that the customer should retain responsibility for that work.  If there is to be a transfer of any of that responsibility – and the consequential cost and risk – to the CSPs, they will need to reflect that in their pricing.  Given the above, there’s clearly an argument that the Act needs to more clearly define the scope of the required measures.

Similarly, the extent of the cooperation requirement would benefit from further clarification. It is usually the incoming service provider who offers switching support (e.g. a degree of consultancy support) as an incentive to move. The customer should have all the necessary details of the nature and volume of its digital assets and how they are stored and configured – so it can provide that information to any new CSP.  If, for example, digital asset formats need to be converted/reformatted or a new non-standard API needs to be created, where that is a consequence of the customer’s solution decisions it is logical that the work should be customer-led (and paid for), rather than this falling within the CSP’s cooperation requirement.

It is important – to encourage innovation and competition, among other reasons – that market participants are permitted to appropriately protect the value of the intellectual property they have spent significant resources developing.  Sharing proprietary data, intellectual property and trade secrets in this way could result in the recipient CSP or customer getting a windfall benefit – i.e. access to a work product a provider has invested significant resources in developing and protecting, without having to pay for that access.

If this is not the legislature’s intention, the cooperation language needs to be refined to makes it clear that CSPs will not be expected to exchange commercially sensitive information relating to systems architecture, security or intellectual property (whether know-how, trade secrets or otherwise) with the customer or each other.  If any such sharing is the intention, its extent needs to be clarified so CSPs can take this into consideration when designing their services, and it is clear what information customers and competitor CSPs are entitled to access.

The draft does recognise that for non-infrastructure services, functional equivalence may not be attainable. In this event, CSPs would be required to comply with mandated interoperability standards in order to allow the transfer of data between such services. Such standards will be instigated by the Commission, either by drafting them internally or mandating the adoption of an external draft. The standards must follow the overarching themes as drafted in Article 29 (Interoperability for data processing services). These include being performance oriented towards achieving interoperability in a secure manner, enhancing portability of digital assets between different data processing services that cover the same type and ensuring, where technically feasible, functional equivalence. Therefore, even where a service provider is not directly obligated to maintain functional equivalence by the Act, the inclusion of the requirement to follow mandated standards could mean (where technically feasible) that the entity is required to maintain functional equivalence regardless.

Impact on the cloud services industry (and its customers)

The concept of functional equivalence as currently drafted arguably oversimplifies the cloud service industry, envisaging a significant proportion of services (or core elements of them) as being neatly categorised and highly similar between different providers and failing to sufficiently recognise the impact the customer’s solution design and choices can have. In reality, a customer’s current CSP will not necessarily have an understanding of whether the service supplied by the customer’s proposed new provider(s), and the customer’s own solution design, are compatible with the achievement of a ‘functionally equivalent’ service (with all that the definitions and Articles require) and gaining this understanding could, as noted above, require the sharing of commercially sensitive information. Requiring such sharing could also adversely impact competition in the industry by reducing the ability of CSPs to, or their financial incentive to, differentiate their offerings based on resilience, security, functionality or other factors. That in turn risks driving a homogenisation of services in the market, potentially leading to a “race to the bottom” in which CSPs are not incentivised to innovate or develop their services or infrastructure in a truly open market environment for fear of not being able to achieve a reasonable return on their investment in their intellectual property and / or if the services are significantly differentiated, not being able to guarantee functional equivalence.   

Functional diversity, and availability of additional tools and services, are key differentiators and drivers of competition and hence innovation in the cloud service industry.  This in turn leads to increased customer choice.  With the above in mind it is critical that the Act does not:

  1. in practice prevent, inhibit or discourage CSPs from innovating or investing in and bringing to market new and differentiated cloud services and functionalities; or
  2. have the effect of over-reaching the levels of mandated standardisation and conformity of services that are strictly necessary to drive the desired behaviours; or
  3. leave uncertainty as to the extent of the required additional work or changes a CSP may need to undertake, or the resources it may need to retain or commit, as that would lead to CSP’s having to price that risk, leading to price increases.  This is particularly relevant where the customer may be better placed to undertake some or all of the required work (and may be able do so at a comparatively better price). 

What can be done?  

One suggestion, made by the European Parliament’s rapporteur for the internal market and consumer protection committee scrutinising the Act, Adam Bielan MEP, is to delete the concept entirely. His draft opinion published on 10 October 2022 highlights the issues with functional equivalence in his justification for its deletion:

While the Commission’s proposal highlights the right principles, its implementation seems quite challenging: the proposal does not recognise that the use of cloud services differs between market participants. How these services are deployed within the network of customer’s other services, applications and dependencies is rarely identical. Similarly, the concept of functional equivalence can be problematic, as it places obligations on the source providers that are impossible to comply with, unless they have access to the infrastructure of the provider of destination cloud services. Even if that was possible, functional equivalence would disturb the balance between what can be reasonably expected from two providers of cloud services participating in the switching process, either when it comes to the sharing of sensitive know-how or forcing responsibility for performance of competitor service.

Alternatively, if the concept is to be retained, the final version of the Act needs to provide significantly more certainty as to the extent of the functional equivalence obligations:

  1. to enable CSPs to appropriately price their services to reflect any additional work they may have to do, resources they need to maintain or functionality they need or may need to build and support now or in the future (noting that pricing these aspects will not be easy if it will have any dependency on the customer’s solution or the new CSP’s service design);
  2. so that the division of responsibility for design elements between the cloud service and customer solution, and provision and of any associated professional services, is clear; and
  3. to clarify the extent and nature of the required cooperation, intellectual property and information sharing between the original CSP and the customer and any new or additional CSP. Arguably the CSP’s cooperation / information requirement should simply be limited to making standard APIs and switching-related tools and information available.

As it stands, functional equivalence has remained in largely unamended form, despite the reservations of Bielan and others. As the draft Act moves into the trialogue phase, we expect negotiations on functional equivalence and either its removal or if retained, its scope, to continue to be a central feature of the discussions.

In our next Law-Now, we will focus on proposed measures to reduce and remove switching charges and better facilitate customers use of multiple cloud service providers.

For more information on the Act or if you have any questions on how it could affect your business, please reach out to your usual CMS contact.