France’s SREN Law Regulates Cloud Lock-In
France’s SREN law treats cloud exit as a market rule: switching fees, portability, interoperability and contract transparency are no longer matters that customers can safely postpone until migration day.
Law 2024-449 on securing and regulating the digital space was published on 22 May 2024. Among its many subjects, the law created a national framework aimed at reducing technical and commercial lock-in in cloud computing. It anticipated parts of the EU Data Act and gave the French communications regulator, Arcep, a central role.
The result is not a right to a painless migration. It is a set of rules intended to make the cost and mechanics of leaving more visible, limited and technically possible.
Switching costs are regulated, not merely disclosed
The law distinguishes data-transfer fees from other switching fees. In a change of provider, charges cannot exceed costs borne by the cloud provider and directly connected to the change. Similar cost limits apply to data transfers in simultaneous multi-cloud use. Providers must explain the nature and amount of potential fees clearly to customers and prospective customers, including in contracts.
Subsequent regulatory work has made the direction even clearer. Arcep has developed recommendations and guidelines on portability, interoperability and eligible costs, while the government set a zero ceiling for data-transfer fees when changing provider.
For procurement teams, the practical lesson is not to settle for “egress fees may apply.” A contract should identify which datasets and digital assets can be exported, available formats, transfer mechanisms, assistance, timing, service continuity and any costs that remain chargeable.
Portability includes more than database rows
A usable cloud service contains configuration, metadata, identities, policies, logs, application artefacts and dependencies as well as customer content. Migrating only the obvious data may leave the customer unable to recreate the service elsewhere.
The SREN framework uses the concepts of exportable data and digital assets. That pushes exit planning toward a service-level inventory. Customers need to identify what they are entitled to recover and what remains dependent on proprietary features. Providers, in turn, need a stable description of export functions and interfaces.
This is where architecture choices become legal-operational evidence. A customer that deliberately uses a proprietary database feature may accept a transformation project at exit. A provider that does not document an available standard export route creates a different problem. The contract and design record should make that distinction visible.
Interoperability makes API governance a compliance issue
The law empowers Arcep to address technical requirements intended to facilitate switching and multi-cloud operation. Interfaces should not be treated as informal conveniences that can change without consequence.
Providers should maintain versioning, change notices, documentation and a reasonable path away from deprecated interfaces. Customers should know which integrations are based on public standards, which depend on a proprietary API and which can be tested outside production. An exit test that runs only at contract termination is too late.
An annual portability exercise can be modest: export a representative dataset, restore it in a neutral environment, confirm its integrity, test key configuration information and measure the time and cost. The point is not to migrate every year. It is to discover undocumented dependencies while both parties still have options.
Cloud credits can shape architecture
The SREN law also addresses cloud credits—commercial advantages that can attract a customer to a platform and then influence long-term dependency. Offers are subject to duration and renewal constraints designed to prevent indefinite lock-in through promotional arrangements.
Credits are not inherently harmful, but their governance should sit beside technical architecture. A discounted service can encourage a team to adopt provider-specific components whose migration cost persists after the credit disappears. Finance, procurement and engineering should therefore evaluate the post-credit operating cost and the exit complexity together.
Build an exit evidence pack
Customers using cloud services in France should maintain:
- a register of data, applications and digital assets by service;
- the contractual export and assistance commitments;
- current API and format documentation;
- a list of proprietary dependencies and accepted migration risks;
- measured results from portability tests; and
- a cost model for transfer, transformation and parallel operation.
Providers should be able to produce the corresponding service description and fee logic without a bespoke legal investigation for every request.
The most important shift is psychological. Cloud exit is no longer a clause to negotiate after the architecture has been chosen. Under SREN, switching capability becomes part of service design, commercial transparency and regulatory accountability from the beginning of the relationship.
Official sources
- Légifrance: Law 2024-449 on securing and regulating the digital space
- Arcep: Cloud regulation timeline and guidance
Continue the series
- Also in France: France Made Algorithmic Video Surveillance a Time-Limited Legal Experiment
- European National Cyber & Digital Law Series index
This article provides general information and is not legal advice.
