Exit strategy and digital sovereignty

Digital sovereignty is about control: knowing which legal system your software and data fall under and being able to switch without your processes coming to a halt. That control stands or falls with a workable exit strategy. On this page: what an exit strategy is, why escrow makes it workable and the question that is often skipped: how sovereign is the safety net itself?

What is an exit strategy?

An exit strategy establishes in advance how your processes and data keep running if a supplier fails or discontinues its services. It is not a stand-alone emergency procedure. Nor is it a topic that only comes up once digital sovereignty is on the agenda. An exit strategy belongs to the architecture of a solution, just like security: a foundation you include in design and procurement. Which dependencies arise? How do you migrate away? And what do you need in terms of source code, data, documentation and knowledge?

Regulators now ask for it explicitly. DORA obliges financial entities to have exit strategies for critical ICT services (Article 28). NIS2 requires continuity measures for critical dependencies. ISO 22301 identifies software dependencies as a business continuity risk.

Escrow and compliance: per framework →

Without a deposit, an exit strategy remains paper

The hardest moment to execute an exit is exactly the moment you wrote it for: a supplier that is bankrupt or has discontinued its services. Without access to source code, data and a description of the environment, you have a plan but no means. The source code is the supplier’s intellectual property and falls into the bankruptcy estate; arranging something yourself with former employees infringes that property.

Escrow solves this in advance, in terms of availability. The supplier deposits source code and data with an independent escrow agent. Under the agreed release conditions a deposit becomes directly available to the beneficiary, with the accompanying right of use. Because a deposit automatically passes into safekeeping upon bankruptcy, it is immediately clear to the receiver that it falls outside the estate.

• Software Escrow: source code and documentation, kept current through periodic full deposits
• SaaS Escrow: source code and data, kept current via incremental snapshots
• CloudSecure®: continuity of the entire cloud service through legal ring-fencing

The transferability of knowledge, often the weakest point of an exit plan, can be arranged as well. The deposit specification describes the contents of a deposit. A step-by-step compilation guide accompanies the delivery. In a verification investigation the supplier builds a working environment from the deposit under the supervision of an independent NOREA Register IT auditor. The report of findings indicates whether a working application can be compiled from the deposit.

Compare the three services → Verification investigation →

An application is increasingly a collection of cloud services

Vendor lock-in plays out at several levels. The best known is the application level: the dependency on the supplier itself, its licences and data formats. Escrow is the classic answer to that. Beneath the application lies the platform it is built on. Below that, the operating system, with its own licences and binding. And those who host themselves also know the virtualisation layer; the recent licensing changes in the hypervisor market showed how deep that binding can run. Each layer has its own choices that bind, down to the hardware.

In practice we increasingly see that a software solution is no longer a self-contained package, but a collection of cloud services tied together. Suppliers build their application from ready-made building blocks of a single cloud platform, for example Microsoft Azure. They combine PaaS services (the supplier only supplies code and data) with IaaS components for networking and storage.

That works excellently as long as all goes well. But the solution can then no longer be separated from the platform it runs on. The source code alone is insufficient to continue the service. Without the accompanying cloud services, configuration and identity provision, that code is no more than a semi-finished product. In the event of bankruptcy or the loss of the supplier, the question is not whether you have the code, but whether you can reconstruct the environment in which that code can run.

Two questions therefore play a role in an inventory. Which platform-specific services are in use? And which of those have a realistic alternative outside that platform? By way of illustration, a selection of the most popular Azure components:

The heaviest dependencies typically sit with Cosmos DB, Logic Apps, Entra ID and Bicep/ARM. These have no practical equivalent elsewhere, or transferring them amounts to rebuilding rather than moving. The same pattern applies to AWS and Google Cloud. The full tables for all three platforms are on the reference page:

Platform dependencies: Azure, AWS and Google Cloud →

Vendor lock-in is therefore not bad by definition. Proprietary services exist because they offer something: speed, functionality, less management of your own. Choosing a heavy platform binding can be a perfectly sound trade-off. The difference lies in awareness. A lock-in you know about, with a safety net underneath it, is a design choice. A lock-in that only becomes visible the moment a supplier fails is a risk.

The table works both ways, incidentally. Some organisations deliberately choose the comfort of a single platform, but within it only select components with a realistic alternative outside that platform. Think of an application on Azure built from App Service, Azure SQL and Blob Storage: each of those components has a common alternative, and if need be the entire solution runs on a Linux VM at any hosting provider. Interoperability as a design choice. That way the exit strategy is built into the architecture before anything goes wrong.

For platform-bound solutions like these, a source code deposit alone is not enough. A deposit is only complete when, alongside the code, the infrastructure definitions, the configuration and a description of the platform services used are recorded as well, in the deposit and the deposit specification. Stronger still is an automated build: configuration management (for example Ansible or similar scripting) that can construct the environment within the platform. That is a runbook that executes itself, rather than a description someone has to re-enact. For the entire running cloud service, including hosting contracts and user licences, there is CloudSecure.

Cloud escrow or CloudSecure? →

Export-first: the sales argument for the supplier

The same design question applies to suppliers, but through your customer’s lens. Many SaaS applications are not built export-first: data can get in, but cannot be usefully extracted at any moment. For your customer that is a dependency that is increasingly weighed explicitly during procurement.

Those who do build their application export-first give customers part of their exit strategy as a gift. That need not be a threat to a business model; it can just as well be a sales argument: competing on trust instead of on lock-in. It is the same principle we apply to our own safety net, without vendor lock-in: a deposit can be opened with standard tooling upon release.

One caveat: an export function lives and dies with the service itself. In the event of bankruptcy or discontinuation of the service, the export button is gone. Export-first and escrow therefore complement each other: export-first covers the period the service is running, a deposit covers the moment the service stops.

SaaS Escrow →

The forgotten question: how sovereign is the safety net itself?

Anyone who takes digital sovereignty seriously assesses suppliers on jurisdiction, ownership structure and the ability to leave. Remarkably often, that assessment is skipped in one place: the safety net itself. An escrow deposit contains an organisation’s most critical assets: source code, data and configurations. If the escrow agent’s storage falls under the US CLOUD Act or USA PATRIOT Act, the exit strategy has a hole at precisely the critical point. The deposit that is supposed to safeguard your sovereignty is then itself reachable through a foreign legal system.

Four questions to ask any escrow provider:

• Jurisdiction of the storage: is a deposit, including its back-ups, stored entirely within the EU or with a US provider or one of its European subsidiaries?
• Ownership structure of the provider: is there a US parent company or incorporation through which a foreign order could be passed?
• Access to the contents: can the provider itself access the contents of a deposit? Or is the storage zero-knowledge, with the encryption key never reaching the provider?
• Continuity of the provider itself: what happens to a deposit if the escrow provider fails?

How Softcrow addresses this

• Sovereign storage: SecureStorage, the storage infrastructure underneath all our services, is 100% EU-hosted and falls outside US jurisdiction: free from the CLOUD and USA PATRIOT Act
• Zero-knowledge: the supplier encrypts client-side and Softcrow never receives the encryption key; the contents of a deposit are not accessible to any party in between
• Independent Dutch company: escrow provider since 1991, without a foreign parent company or incorporation
• Own continuity safeguarded: through an independent foundation, deposits remain available even if Softcrow itself were to fail

Security by design → Contact Softcrow →