Sovereign, but for what?

Regulators already require parts of the business world to prepare for leaving important technology suppliers. In EU financial services, DORA requires exit strategies for ICT services supporting critical or important functions, with documented, sufficiently tested exit plans. Governments are also examining their own digital dependencies. Switzerland has made digital sovereignty a focus of its Digital Switzerland Strategy 2026, binding on the Federal Administration and a reference point for business. Boards have reason to consider how these developments should influence their supplier choices and long-term investment decisions.

The business question is where greater sovereignty would actually make a consequential difference. Which external decisions could prevent the company from fulfilling an important obligation, carrying out critical work or directing an activity it is responsible for? Answering that requires looking across the company, then deciding individually where greater control warrants the commitment. The breadth of the assessment should not predetermine how much of the business must change.

Even if sovereignty might become a requirement, the question of what exactly is in scope becomes vital.

Imagine a company agreeing that it needs to become more sovereign. Everyone acknowledges the dependence on Microsoft, and reducing it makes sense from a business continuity perspective. Then the individual decisions arrive. An alternative takes more effort to support, an internal process becomes slower, or exchanging information with a client becomes more difficult. The existing system keeps winning the comparisons, even though nobody has withdrawn their support for the strategy.

I can understand both decisions. A board may have good reasons to seek greater control, while the people running the business have equally understandable reasons to favour what lets them get the work done. A blanket “let's get sovereign” mandate leaves them to resolve questions the board has not yet answered. Which parts of the company should change, what should they gain, and which consequences is the organisation prepared to accept?

Everest Group's recent report on sovereign cloud triggered some thoughts. It already recommends assessing workloads individually and recognises the costs of stronger control. I would take that approach further, across the company. Much of the work will concern IT, but outsourced operations, supplier arrangements and access to essential expertise also belong in the assessment.

Finding the individual decisions

I would start with an inventory of the parts of the company where an external dependency could constrain its decisions or its ability to operate. Each node needs a boundary that makes sense in the work and someone responsible for it. It could be the handling of client information, a shared service or an outsourced process. Departments alone would be poor boundaries where services and knowledge are shared across them. Bear also in mind that data and the software used to view it are not necessarily the same thing. The sovereignty requirements for the data and the “data viewer” may differ.

The inventory has to lead to a decision for each node. For that, we need to establish what the company controls today, what another party can determine and why changing that arrangement would have the intended impact. Restricting access to information and continuing to operate when a service becomes unavailable are different purposes. A solution to one may leave the other largely untouched. A dependency can also be acceptable, and a deliberate decision to retain it belongs in the record.

I would give priority to nodes where an external constraint could seriously affect the business and where the proposed change would give the company meaningful control over that consequence. The importance of an activity alone does not establish that a sovereignty investment would help, and an easy migration does not establish that it would address an important dependency.

Take client documents. Moving the files to another location would still leave questions about who can open them, how their use is governed and whether clients can work with what we send. In Microsoft's environment, sensitivity labels can apply encryption and access restrictions, while retention settings govern preservation and deletion. The assessment needs to follow the information through the work and establish where those required behaviours are enforced. Otherwise, a change of storage could be credited with control it has not provided.

An outsourced process could expose a different problem. If the supplier holds the practical knowledge needed to run it and judge exceptions, changing the software may leave the decisive dependence intact. Greater control could require retaining expertise internally or changing who has authority over the work.

A viable choice, with consequences

An acknowledged dependency does not establish that there is a suitable destination. Rebuilding rules and integrations requires resources. The alternative must also provide essential functionality and have a credible future, including the capacity to maintain and develop what the business needs. Just because something is open source does not mean it is viable. Compatibility is part of that test. A business exchanges information with parties whose systems it cannot choose. Building its own solution may give it more control over the design while making those exchanges harder. Nor should we assume that the incumbent permits no interoperability: To keep with the previous example, Microsoft documents ways for third-party applications to read sensitivity labels and integrate protection. We have to establish whether the actual work can be done with the required controls in place.

Prices or operational restrictions can become unacceptable, and suppliers have commercial reasons to retain customers. The CMA's 2025 cloud investigation found technical and commercial switching barriers and adverse effects from licensing practices in the markets it examined. Those findings support scrutiny without establishing that every integration difficulty was deliberately created. They also do not make an unsuitable alternative viable.

Once we have a viable choice, its everyday consequences need the same attention as its technical requirements. People are measured on tasks completed and time spent. They are rarely rewarded for using a system that advances an infrastructure strategy. If the previous arrangement makes client communication easier, keeping productivity expectations unchanged gives them a reason to seek exceptions or workarounds. What leadership accepted as a strategic disadvantage has become a problem for someone trying to meet a delivery commitment.

A governance or regulatory requirement may compel a response. If that is the whole case presented to the business, I would expect it to seek the minimum acceptable implementation. A more substantial commitment needs a strategic purpose strong enough to survive comparisons. Some disadvantages may be permanent. We should be prepared to discuss them without assuming that the alternative will eventually win on immediate value for money.

That still leaves a limit. A less convenient process may be an accepted consequence. A missing function essential to serving clients may make the proposal unworkable. The assessment has to distinguish the two before the organisation commits.

What the board needs to decide

I would want a sovereignty proposal to say precisely what needs to change. “Client data” is too broad. Which records, including which copies and backups? Is the concern their location, who can read them, who controls the encryption keys, or whether the company can still use them if a supplier withdraws a service? Those questions can lead to different decisions about what must move, which controls must change and what can remain where it is.

Data and the software used to view it need separate consideration. We might seek stronger control over the records while retaining an existing application, provided its access, processing and support arrangements satisfy the intended boundary. That requires examining where it processes the information, whether it makes copies and which administrators can reach it. If the application can still expose the information we intended to protect, moving the storage has not achieved the proposed control. Conversely, replacing the whole application may add cost without addressing the specific concern any better.

I would apply the same discipline beyond IT. For an outsourced process, which decisions must the company retain, what knowledge must remain internally and which tasks can continue to be performed by the supplier? The answer might require a change in contract or staffing rather than a migration. The board does not need to design these arrangements itself, but it needs proposals detailed enough to judge whether the claimed control follows from them.

“The regulator requires us to” would not be a sufficient explanation. I would ask for the specific obligation, where it applies and the outcome it requires, followed by the implementation choices available to meet it. A binding requirement must be met. Where the organisation has discretion, the choice and its consequences still require judgement. In EU financial services, DORA explicitly leaves ultimate responsibility for ICT risk with the management body. Compliance does not relieve leadership of the need to understand the risks of its chosen response.

For each node, the decision record should connect the proposed action to the risk it addresses and the evidence that the control will work. I would want to see what remains dependent on the incumbent, what new dependencies are introduced and who accepts the residual risk. That includes risks during the transition as well as the eventual operating arrangement. Extra support capacity, compatibility limitations and slower work need an owner and provision in the budget or delivery expectations. Those consequences should be visible when the decision is approved.

Exit planning remains necessary wherever it is required. Where the company chooses greater sovereignty, I would make the selected approach its normal way of operating. A standby alternative creates another obligation to maintain skills and test whether it still works. The lift alarm comes to mind: using the lift each day tells us little about whether someone will answer. A board funding a lasting change needs a medium- to long-term horizon and tolerance for attempts that fail, together with clear reasons to revisit an approach that is not delivering the intended control.

The vision of a sovereign company is commendable, but it contains many different commitments. I would want the board to be able to point to the particular data, decisions, capabilities and relationships where it has chosen greater control, explain why each matters and acknowledge the dependencies it has retained. That gives it something concrete to oversee as the company and its suppliers change.