---
title: "Digital sovereignty: Cutting SaaS lock-in"
lang: en
type: blog
canonical: https://www.arocom.de/en/blog/digital-sovereignty-practical
alternate: https://www.arocom.de/blog/digitale-souveraenitaet-praktisch
author: "Axel Roth"
published: 2026-10-31
last_updated: 2026-10-31
---

# Digital sovereignty: Cutting SaaS lock-in

In mid-sized companies, digital sovereignty does not mean self-sufficiency but the ability to act when a vendor changes prices, terms or the service itself. It becomes practical through four levers: an exit strategy per critical service with a tested data export, clear data control over storage location and encryption, the targeted use of open source where switching costs would otherwise grow too high, and EU hosting for especially sensitive data. The right measure is not maximum independence from everything but deliberate dependency with a known way out. You should start with a short list of your three most critical services.

## Digital sovereignty in practice: Reducing SaaS dependencies

"Digital sovereignty" sounds like industrial policy and grand speeches.
In the engine room of a mid-sized company it is something very
down-to-earth: the ability to stay capable of acting when a software
vendor does something you do not like. They triple the price. They drop a
feature a process is built on. They sell the company, or they shut the
service down.

Exactly that has happened often enough in recent years that it is no
longer doom-mongering but a planning assumption. Sovereignty therefore
does not mean running everything yourself. It means entering every
dependency deliberately and knowing a way out for each one. This opinion
piece shows four levers that make this work in practice, without lapsing
into self-sufficiency romance.

## Not all or nothing

A clarification up front, because the debate often tips into the
fundamental. The goal is not to banish every cloud service and pull
everything onto your own servers. For most mid-sized companies that
would be more expensive, slower and riskier than the dependency it is
meant to avoid. Software as a service has good reasons: less operation,
faster updates, predictable costs.

The useful measure is a different one. It does not ask "own or
external" but "what does the exit cost us, and how quickly could it
happen?". A service you can get back out of within two weeks with your
data is a calculable dependency. A service that holds your data in a
closed format and without which you cannot work for a week is a
concentration risk, no matter how well it runs today.

## Lever 1: Exit strategy before the entry

The most effective measure costs the least before signing the contract
and the most later, when it has been neglected. For every critical
service, clarify three things before you introduce it: do we get all of
our data back out, in which format, and have we actually tested the
export once?

The last point is the one where it fails. Many vendors promise an
export, and it then delivers an unusable file missing the links, or a
format no other system can read. An export you have not once played
back into a target system is a promise, not an exit strategy. Test it
once in the first year of operation, while the pressure is low. Record
the result. This one exercise noticeably shifts the balance of power at
the next price round.

## Lever 2: Clarify data control

For every service that processes your data, three answers should exist
in writing. Where is the data located geographically? Who can access it
technically, including at the vendor? And is it encrypted so that access
without your key comes to nothing?

This is not a pure compliance exercise for the data protection officer.
In an emergency, data control decides whether you can switch and whether
a vendor change or an insolvency catches you off guard. Data that sits
in the EU, whose access is regulated and which you keep encrypted is not
only friendlier to data protection. It is also easier to rescue when a
vendor fails. Where especially sensitive data is processed, the storage
location is worth treating as its own selection criterion, as our
knowledge article on
[choosing hosting](https://www.arocom.de/en/knowledge/drupal/choosing-hosting) works through
for the technical side.

## Lever 3: Open source where switching costs would otherwise explode

Open source is not an end in itself and not a question of conviction. It
is a tool against exactly one danger: that switching costs become so
high that a switch is practically impossible. With open-source software
the code and the data model are yours in case of doubt. You can change
the vendor without changing the system, or take over operation yourself.

That does not pay off everywhere. For a standard office suite the
proprietary solution is often the sensible choice. But for the systems
that make up your business and hold your most valuable data, meaning
website, customer management or an increasingly AI-supported knowledge
base, the question of an open foundation is justified. Here it decides
your negotiating position for the next ten years. The same applies to
AI: the economically important question is who owns the integration
layer between the model and your systems, a point our article
[Make or buy for AI solutions](https://www.arocom.de/en/blog/make-or-buy-ai)
explores in depth.

## Lever 4: EU hosting for the sensitive cases

The fourth lever is the most targeted. Not everything has to sit in the
EU, but the sensitive part should. Personal data, trade secrets and
anything under special supervision belong on infrastructure subject to a
clear legal framework that is known to you. Today that is no longer a
sacrifice of comfort: European vendors and EU regions of the large cloud
platforms are mature and competitive for most use cases.

What matters is the legally clean framing, so that nobody sells false
security here. A server location in the EU is a necessary but not a
sufficient condition. What also matters is which law the vendor is
subject to as a company and who can access the data. This question
belongs in the contract and with your data protection officer, not in a
marketing slide.

## The four levers at a glance

| Lever | Core question | First step |
| --- | --- | --- |
| Exit strategy | Do we get our data back, complete and usable? | Test the export for real in the first year of operation and record the result |
| Data control | Where does the data live, who can access it, is it encrypted? | Get three written answers per service |
| Open source | Do we own the code and data model of our business-critical systems? | Make it a criterion in the next selection process |
| EU hosting | Is the sensitive data under a clear, known legal framework? | Identify sensitive data and settle the storage location contractually |

## The first step for this week

Sovereignty does not come from a decision of principle but from a list.
Write down your three most critical services, meaning the ones without
which you could not work for a week. Note a single number per service:
how many weeks would you need to switch to another vendor with your
data? Just estimating this number shows where your biggest concentration
risk sits.

If you want to put this list into a robust order and set up a real exit
strategy for the most critical service, we sort that out together in a
[Future Check](https://www.arocom.de/en/future-check). Prefer to talk directly? You can reach
us via the [contact page](https://www.arocom.de/en/contact).