HOW DEPENDENT IS YOUR ORGANISATION ON ITS CLOUD AND TECHNOLOGY PROVIDERS?

Suppose a local authority relies on a major global cloud service provider to support its council tax and benefits services. Over time, applications, data and supporting technologies have become increasingly integrated with the provider's cloud environment.

For years, the arrangement works well. Services are reliable, teams are familiar with the technology, and the platform has become an established part of how the council operates.

Then, for whatever reason, access to the service is disrupted.

The immediate concern is restoring services for citizens. But that raises a more difficult question: how dependent is the council on its existing provider to do that?

The council may still own its data and have contractual rights to retrieve it. But can that data be recovered and made usable elsewhere? Can the applications operate without technologies specific to the existing environment? Do internal teams have the knowledge to restore the service independently? What happens to identity, security, monitoring and backup? And if another provider is available, how long would it actually take to make the service operational?

These are difficult questions to answer in the middle of a disruption. Yet that may be the first time an organisation discovers how dependent it has become.

CLOUD DEPENDENCY IS NOT NECESSARILY THE PROBLEM.

Public-sector organisations depend on external technology providers for good reasons. Cloud platforms provide scale and capability. Software providers offer services that would be costly to recreate internally. Specialist partners provide skills and expertise that organisations may neither need nor be able to maintain themselves.

The question for senior leaders is not how to eliminate those dependencies. It is whether the organisation understands which ones matter and retains credible choices if they are tested.

That distinction matters because dependency and excessive dependency are not the same thing.

An organisation could place substantial workloads with one cloud provider while understanding and managing the resulting dependency. Another could use several providers but still depend critically on one identity service, dataset, supplier team or operational capability.

THE NUMBER OF PROVIDERS DOES NOT, BY ITSELF, TELL YOU HOW DEPENDENT YOU ARE.

This is becoming increasingly relevant to government. A 2026 parliamentary response reported that around 55% of central government organisations surveyed had more than 60% of their estate in the cloud. Every survey participant used one of two leading cloud providers. The Government also said there was no centralised record showing what proportion of critical public services used US-owned cloud infrastructure.

Concentration is not evidence by itself that the resulting dependency is unacceptable. It is a reason to understand it.

HOW DOES VENDOR DEPENDENCY DEVELOP?

Significant dependency is rarely the result of one decision. More often, it accumulates.

A managed cloud service helps one programme deliver faster. Another team adopts capabilities from the same ecosystem. Applications start using provider-specific services. Data volumes grow. Monitoring, backup and security processes become integrated with the platform. Teams develop specialist skills. Commercial commitments make further consolidation attractive.

Each decision may make sense on its own.

But look at them collectively several years later and the position can be very different. Changing provider may remain technically possible, while doing so in practice requires application redesign, data migration, replacement tooling, new skills, contractual support and significant investment.

This is why cloud spend or supplier count can only tell leadership so much about dependency.

The question is what sits behind those numbers.

FIVE SIGNS YOUR PROVIDER DEPENDENCY DESERVES CLOSER ATTENTION.

There is no universal percentage of workloads, applications or expenditure at which an organisation suddenly becomes too dependent on one provider.

A better test is whether that dependency is beginning to restrict practical choices.

1. You cannot clearly identify what would be affected. If a major provider became unavailable or unsuitable, could you identify which critical services, data, processes and capabilities would be affected?
2. Your alternative exists on paper but has never been demonstrated. An architecture diagram may show that an application could run elsewhere. That does not establish that the complete service could be recovered and operated there.
3. Critical capability sits outside the organisation. A service may rely on specialist supplier knowledge, security capabilities, operational processes or technical expertise that would be difficult to replace quickly.
4. The real cost and timescale of changing are unclear. Licensing, committed expenditure, data transfer, redesign and transition costs can make a technically viable alternative commercially unrealistic.
5. You have a contractual exit, but not necessarily an executable one. A contract may give you the right to leave. Actually doing so could require data, documentation, specialist resources, supplier cooperation and transition support.

The Competition and Markets Authority's cloud market investigation illustrates why the wider environment matters. Its work examined switching and multi-cloud alongside areas including technical barriers, licensing, committed spend agreements and egress fees. In March 2026, the CMA said further steps were still required to help UK customers switch and use multiple cloud providers, while also recognising steps providers had taken on egress fees and interoperability.

The right to choose an alternative is not the same as the practical ability to exercise it.

WHAT RISKS DOES CLOUD DEPENDENCY CREATE?

For leadership, provider dependency matters when it starts affecting organisational outcomes.

• Service resilience. Could a critical service continue, recover or transition within an acceptable period if the existing arrangement changed?
• Financial control. Licensing, switching costs and committed expenditure can affect negotiating leverage and make alternatives expensive to exercise.
• Strategic flexibility. Technology decisions made today can influence which transformation, policy or service-delivery choices remain realistic tomorrow.
• Operational control. An organisation may own an application and its data while still relying on external people, tooling or processes to operate or recover the service.
• Security and supply chain. Identity, access, key management and other capabilities may themselves depend on third parties and wider technology supply chains.
• Jurisdiction and policy exposure. Technology services operate within legal, ownership and policy environments that an organisation cannot fully control.

None of these automatically makes the underlying dependency unacceptable.

What matters is the criticality of the service, how dependencies combine around it, the consequences if one of them is tested and whether the organisation has a credible alternative.

COULD YOU ACTUALLY MOVE A CRITICAL SERVICE?

This is where an important distinction emerges between moving technology and moving a service.

An application may technically be capable of running on another cloud platform. But what about its data? Identity services? Monitoring and backup? Security controls? Operational knowledge? Licensing and support arrangements?

A critical service depends on the ecosystem around its technology, not simply the infrastructure underneath it.

This is the difference between cloud portability and service portability.

Our recent article, Digital Sovereignty: The Eight Dimensions of Dependency, explores this in more depth across Technology, Data, Operations, Security, People, Commercial, Contracts and Jurisdiction.

For leadership teams, the question should therefore not simply be:

Could we migrate?

It should be:

Could we continue delivering the service if we had to exercise an alternative?

If an alternative cannot be exercised within the time, cost and level of disruption the organisation can tolerate, its practical value may be limited.

Where that alternative matters, it should be demonstrated rather than assumed.

FIVE QUESTIONS SENIOR LEADERS SHOULD ASK.

Understanding dependency does not need to begin with a large technology programme. Leadership teams can start with five questions:

1. Which of our critical services would be hardest to continue if we could no longer rely on their current technology providers?
2. Where is dependency concentrated around those services, beyond the technology itself?
3. Which dependencies have we consciously accepted, and which have accumulated over time?
4. What would exercising an alternative require in terms of time, cost, people and operational disruption?
5. Have we demonstrated that alternative, or are we assuming it exists because our architecture, contract or strategy says it does?

These questions move the discussion beyond whether an organisation is simply “locked in”. They establish whether it retains meaningful control over the services it is responsible for delivering.

UNDERSTAND DEPENDENCY BEFORE TRYING TO REDUCE IT.

Cloud and technology dependency is not something public-sector organisations can, or necessarily should, eliminate.

The objective is to make material dependencies visible.

Once leaders understand where critical services depend on particular technologies, providers, data, skills and operating models, they can decide deliberately which dependencies to accept, which to mitigate, where diversification is justified and where a credible alternative needs to be maintained.

The starting question is not:

How do we become independent?

It is:

Where are we dependent, and does that dependency leave us with enough choice?

To examine that question systematically, read Digital Sovereignty: The Eight Dimensions of Dependency, which explores Technology, Data, Operations, Security, People, Commercial, Contracts and Jurisdiction as interconnected dimensions of service dependency.