ARCEP vs HDS : discrepancy or convergence in reversibility requirements?

Context and challenges of comparing the ARCEP recommendation and the HDS framework

‍

ARCEP has just published a recommendation on the interoperability and portability of cloud computing services on September 25, 2025. It is an extension of the European Data Regulation (“Data Act”) and the SREN law.

‍

Recall that this regulation, applicable since September 12, 2025, aims to eliminate obstacles to the proper functioning of the internal data market. In particular, it requires data processing service providers to implement technical, organizational and contractual measures intended to facilitate the change of supplier or the simultaneous use of services from several suppliers.

‍

Some measures resulting from this regulation were introduced into French law by the SREN law promulgated on May 21, 2024. This law also aims to remove technical and pricing barriers to changing cloud service providers or to the use of multi-cloud.

‍

In this context, Arcep organized a public consultation from 14 October to 16 December 2024 on a document setting out its understanding of current practices and tools in terms of portability and interoperability, as well as on the needs for transparency and harmonization, and subsequently decided that it was appropriate to define best practices for all cloud service providers, since Arcep noted that the actors concerned will have to comply with possible binding rules that could be superimpose on possible implementing acts of the European Commission.

‍

This document could feed into future discussions by the European Commission, in particular concerning the drafting of common interoperability specifications in the context of the implementation of the data regulation.

‍

The recommendation adopted by Arcep on 25 September 2025 defines best practices in order to strengthen transparency on the degree of portability and interoperability of cloud computing services and to promote the provision of stable and documented APIs.

‍

It is worth recalling the definition of two essential technical concepts in order to understand Arcep's recommendation.

‍

According to the book “Digital law, a risk-based approach” by Arnaud Latil,” In terms of IT contracts, reversibility clauses aim to organize the methods of returning data to the client of an IT service provider ”.

‍

For the Programme Protection Agency, a reversibility clause is a contractual provision that organizes the return or transfer of data, software or critical infrastructure in the event of the end of the contract, the bankruptcy of the service provider or any other event ending the collaboration.

‍

This clause guarantees the customer the possibility of recovering their data or using tools essential to the continuity of their activities.

‍

In summary, reversibility allows a company or a customer to recover all its data when the contract with a service provider is transferred. Reversibility concerns the restoration of data; it can be seen as a component of portability which also involves the transfer of data to the new provider in a usable and usable format.

‍

Arcep uses the term portability in its recommendation rather than reversibility since its main objective is to facilitate the change of cloud service provider. The difference is slight: the right to portability as defined in article 20 of the RGPD implies a choice for the person concerned to recover the personal data provided to a platform, in order to keep them for personal use or to transmit them to a third party of their choice.

‍

In the context of the reversibility of hosted data, this operation often requires the use of APIs to ensure the effective management of the reversibility of the data. Indeed, APIs make it possible to transfer data in a structured and secure manner.

‍

According to Philippe Le Tourneau, in his book “Digital Contracts”, a programming interface (Programming Interface or Application Programming Interface — API)” allows two programs or software to interact with each other, by connecting to exchange data. A programming interface is in principle open and proposed by the owner of the program. It allows a software to use the services and functionalities of another software ”.

‍

The CNIL also defines an API (Application Programming Interface or “application programming interface”) as a software interface that makes it possible to “connect” a software or service to another software or service in order to exchange data and functionalities. It is therefore a set of definitions and protocols allowing two applications or computer systems to communicate with each other.

‍

In the following analysis, we put Arcep's recommendation into perspective with the Health Data Hosting Framework: the ARCEP recommendation in fact meets the objective of the Health Data Host (HDS) certification framework in terms of reversibility to guarantee the return of health data.

‍

The certification framework, in its latest and recent version of May 16, 2024, complements the requirements of article R.1111-11 of the Public Health Code in force concerning what the reversibility clause of any health data hosting contract must contain in order to facilitate the transition from one host to another.

‍

Thus, reversibility is included in requirement 27 and includes the following conditions:

‍

“In accordance with 12° to 14° of article R.1111-11 of the CSP, a clause relating to reversibility must present the terms and conditions at the end of the service or in the event of an early termination of the service regardless of the reason, with at least:

‍

• The commitment to return all the information provided in connection with the service;

‍

• The commitment to destroy any copy of this information at the end of the return;

‍

• The methods of calculating the costs and deadlines for returning copies;

‍

• The retrieval formats, which can be read and used for the purpose of portability of health data, and where applicable, the modalities allowing the movement of virtual machines/containers.”

Putting the two standards into perspective

‍

In order to put the certification framework for health data hosting providers into perspective with the Arcep recommendation, several approaches need to be implemented:

‍

The normative scope of standards.

‍

First, these two standards do not have the same normative scope. Indeed, the HDS certification framework must be respected even though Arcep's recommendation has no normative scope since it implements best practices for all cloud service providers.

‍

The objectives sought.

‍

Moreover, the objectives pursued are not the same since the HDS standard sets out the criteria to be met by the candidate for HDS certification, while the Arcep recommendation aims to facilitate the change of cloud service provider, to streamline the cloud services market and thus to strengthen users' ability to choose.

‍

The scope of application.

‍

The HDS framework is more precise in its scope of application by focusing only on personal health data. Arcep's recommendation involves a greater number of players since it is intended to concern all cloud services in France.

‍

The format.

‍

Then, it is possible to note a common link between these two standards since, on the one hand, the HDS framework provides that data must be restored in readable and usable retrieval formats for the purposes of health data portability. However, if necessary, the modalities must allow the movement of virtual machines/containers.

‍

On the other hand, Arcep's recommendation calls for the publication of the required information in a free and computer-readable format. For example, the information may be present on a web page or a PDF document and the file may correspond to a template that is included in the appendix.

‍

‍The costs.

‍

With regard to the methods of calculating costs, the HDS framework does not provide for an obligation to be free. For its part, Arcep recommends imposing the non-invoicing of migration fees.

‍

In fact, as part of a change of provider, Arcep sent the Government a proposal for a maximum pricing amount for data transfer fees, which would be fixed at €0. Work is continuing on the drafting of draft cost guidelines.

‍

Deadlines.

‍

These two standards also raise the issue of deadlines. The HDS standard is not very precise on this point since it only indicates that the reversibility clause must present the terms and conditions concerning the deadlines for returning copies.

‍

The Arcep recommendation does not also mention deadlines for changing suppliers, but states that it would be appropriate for providers to inform their users at least twelve months before carrying out updates without backwards compatibility of their APIs.

‍

Transparency requirements.

‍

Furthermore, Arcep's recommendation is very specific concerning transparency requirements, unlike the HDS standard, which only indicates that compliance with the requirements must be formalized in the contract between the host and its client.

‍

During the public consultation, contributors recognized that greater transparency on the degree of interoperability and portability of cloud services would be beneficial.

‍

In addition, most actors recognized the value of making comparable information available to enable potential customers to make an informed choice of their service provider, but a reservation arises if the harmonization is too strict concerning the format for distributing this information.

‍

Indeed, this is likely to generate excessive burdens, especially for small suppliers. Thus, to facilitate the comparison between cloud services, the authority considers it appropriate for this information to be accessible and presented in a uniform order.

‍

The Authority considers that the content of the SWIPO Code of Conduct could be a relevant reference for determining what information should be made available to customers and potential customers in order to enable them to exercise their freedom of choice.

‍

Indeed, this code of conduct is interesting since it provides a set of transparency recommendations intended to facilitate data portability and the change of supplier.

‍

Therefore, Arcep recommends that cloud service providers publish information along with their index. Providers are therefore invited to publish eleven categories of information concerning the methods of migration and interoperability of their service, in particular concerning their procedures, migration, supervision tools, formats, description, etc...

‍

The process.

‍

Finally, concerning the process, there are no details in the HDS certification framework. However, it is possible to use the recommendation published by Arcep, which wants stable and documented APIs to be made available.

‍

Arcep considers that it would be appropriate for providers to inform their users at least twelve months before carrying out updates without backward compatibility of their APIs, except when the applicable legal obligations or the supplier's requirements in terms of security and intellectual property protection exceptionally require a rapid update, customers should therefore be informed as soon as possible, and adopt the OpenAPI specification or equivalent specifications for the description or documentation of their APIs.

‍

It's an assumed desire to prevent providers from making migrations complicated on a voluntary basis since they won't be able to change their APIs unexpectedly.

Conclusion

‍

The recommendation published by Arcep recommends strong constraints concerning portability. However, this is only a recommendation, which has no normative scope.

‍

Also, the ARCEP recommendation could usefully be taken into account on the points not covered by article R1111-11 and requirement 27 of the certification framework in order to bring even more transparency and efficiency to reversibility without this being an obligation for health data hosts, as indeed for all hosts.