What is digital sovereignty according to the article?

Digital sovereignty is not only about where a provider or data center is located. It is also about how much real control an organization has when a critical digital service fails.

Why is recovery time important for digital sovereignty?

Recovery time shows how quickly an organization can restore a critical service, including in situations where the provider is unable or unwilling to help.

Why is using a Norwegian provider or data center not necessarily enough?

The provider’s nationality and the location of its data centers do not necessarily show whether an organization can export its data, restore its systems, or continue operating without the provider’s assistance.

What is vendor dependency?

Vendor dependency occurs when an organization relies on a particular provider’s technology, expertise, data formats, or services to maintain or restore operations.

How can organizations test their vendor dependency?

They can test whether critical services can be restored without the provider, whether privileged access can be recovered, and whether data and configurations can be exported in a format that works in another environment.

Do organizations need to eliminate all vendor dependency?

No. The article argues that the goal is to understand which dependencies the organization has accepted and ensure that the measures taken are proportionate to how critical each service is.

What should a vendor exit plan include?

An organization should understand how data and configurations can be transferred, which expertise is required to take over operations, and how the dependency can be ended if the provider can no longer be used.

How can vendor lock-in affect costs?

A solution that is inexpensive to adopt can become costly if data, expertise, and workflows become tightly tied to one provider. A solution with better portability and recovery options may therefore provide greater long-term value.

Why is digital sovereignty relevant to AI services?

AI services can be quick and inexpensive to adopt, but once data, workflows, and decision logic become embedded in one platform, switching to another AI provider or platform can become expensive and difficult.

Digital sovereignty must be measured in recovery time, not by the flag on the vendor’s website

We recently worked with an organization that had done everything right on paper. It had a Norwegian vendor, a data center in Norway, and an agreement requiring that its data could be exported. When the organization tested the export, it received a file that none of its own systems could read. It was also told that the only person who could restore the environment was on vacation for two weeks. The flag was Norwegian, but the control was not there.

Digital sovereignty is often reduced to which country the vendor comes from and where the data center is located. That is relevant, but it says little about what an organization can do when a critical service goes down. NSM Director Arne Christian Haugstøyl advised in February against putting all your eggs in one basket, regardless of who owns the basket. It is about concentration risk, not nationality.

The outages at AWS and Azure in October 2025 brought Norwegian organizations to a standstill for hours, regardless of where their data was stored. The addresses of the data centers did not help. What did help was knowing what had stopped, who could do something about it, and how long it would take before the services were back up.

How to test your vendor dependency

A vendor can fail in two ways. It can be down, as AWS and Azure were. Or it can stop providing services to you because of sanctions, changed terms, bankruptcy, or an order from the authorities in the country where the vendor is based.

One metric covers both scenarios: How long does it take before the most important service is operational again without the vendor’s help? Most organizations have a backup plan. Fewer have tested whether they can actually restore the service.

The goal is not to eliminate all dependency, but to know which dependencies you have accepted and make sure the measures are proportionate to how critical the service is. Can you revoke and restore privileged access without the vendor? Have you tested recovery of the most critical service? Do you know how long it will take? Can data and configuration be exported in a format that can be used in another environment? Has this been tested in practice? Is the necessary expertise available to take over, and is there a plan to end the dependency on a vendor?

The board must know the critical dependencies

In April, the Storting asked the government to map Norway’s digital dependencies on an ongoing basis, with the first report due by the end of 2026. The proposals for a government cloud and an exit strategy from Microsoft 365 did not receive a majority. That is a sensible sequence: first understand the dependencies, then make a decision. Boards should do the same for their own organizations.

The board should not choose the technical architecture. But it should know which digital services the organization cannot operate without, who controls them, and how quickly operations can be restored. That leads to better investment decisions. A cheap solution becomes expensive if data, expertise, and workflows become locked into one vendor. A more expensive solution may be the right choice if it provides better visibility, easier recovery, and a credible plan for switching vendors.

The same logic applies to AI services, and things move faster there. They are quick to adopt and inexpensive at first. But once data, workflows, and decision logic are built into a platform, it can quickly become very expensive if you want to switch AI vendor or platform.