TECHNOLOGY SUPPLIER DEPENDENCY: COULD YOUR CRITICAL SERVICE CONTINUE?

THE DAY YOUR CRITICAL SUPPLIER BECOMES UNAVAILABLE IS THE WRONG DAY TO DISCOVER YOUR DEPENDENCIES.

On 29 October 2025, a Microsoft Azure outage disrupted online UK government services across several departments. Services were restored within hours, and the Department for Science, Innovation and Technology said it was working with Microsoft to understand how similar events could be mitigated in future.

The incident does not show that those departments lacked resilience. Nor does it suggest that public bodies should plan on the assumption that major technology providers will routinely fail.

It does expose a harder question.

IF A SUPPLIER YOUR CRITICAL SERVICE DEPENDS ON BECAME UNAVAILABLE, HOW MUCH OF THAT SERVICE COULD YOU STILL OPERATE WITHOUT THEM?

For a critical public service, the answer depends on much more than the application or cloud platform. It may depend on who holds the operational knowledge, how identity and security are managed, where data can be recovered, what licences apply, what documentation exists and whether the organisation can act without waiting for the incumbent supplier.

Those are difficult questions to answer during an incident. They are much easier to answer beforehand.

SUPPLIER DEPENDENCY IS EASY TO UNDERESTIMATE WHILE EVERYTHING IS WORKING.

Public-sector organisations rely on external technology suppliers because those suppliers provide capability, scale and expertise that would often be expensive or impractical to recreate internally.

That reliance is not automatically a weakness.

The problem is that dependency can deepen gradually without looking significant at the time.

One programme adopts a managed service because it speeds up delivery. Another team starts using capabilities from the same ecosystem. Applications become tied to provider-specific services. Monitoring, backup and security processes evolve around the platform. Teams build specialist skills. Data volumes increase. Commercial commitments make further consolidation attractive.

Each decision can be sensible.

Taken together, they can leave a critical service far harder to operate without its current supplier than leadership expects.

A high level of dependency can be acceptable if it is visible, deliberate and proportionate to the service. The concern is discovering during disruption that the organisation has lost an option it assumed it still had.

A SUPPLIER DOES NOT NEED TO DISAPPEAR COMPLETELY TO BECOME UNAVAILABLE.

The most obvious scenario is supplier failure. In practice, there are several ways an organisation can lose practical access to a technology provider.

There may be a prolonged outage or cyber incident. A service could be withdrawn or materially changed. A provider could enter financial distress. Contractual access could break down. Jurisdictional or policy changes could affect continued use. An organisation may need to leave a supplier faster than planned because its own requirements have changed.

What would we need to keep the service running if the supplier could no longer support us in the way they do today?

This is not always the same problem that disaster recovery plans are designed to solve.

Backups may exist, but someone still needs to restore them and make the data usable. An application may run in another environment, while identity, monitoring or security still depend on the incumbent. An exit clause may provide a contractual right to leave, yet the organisation may still need documentation, specialist knowledge or direct cooperation from the supplier.

A resilience plan that assumes the supplier remains available is testing only part of the problem.

YOUR CRITICAL DEPENDENCY MAY NOT BE WHERE YOU THINK IT IS.

Consider a critical citizen-facing application. The organisation owns the data. The architecture is considered portable. An alternative cloud environment is available. From a distance, that can look reassuring.

Now follow the service one layer further. Can users authenticate in the alternative environment? Can historic data be restored in a usable form? Can security controls and keys be recreated? Can internal teams monitor and operate the service? Are key integrations, licences and transition arrangements transferable?

The application may be portable while the service around it is not.

That is the difference between cloud portability and service portability. Cloud portability asks whether workloads or data can move. Service portability asks whether the organisation can re-establish everything it needs to continue delivering the service.

For senior leaders, the second question is usually the more important one.

PUBLIC SERVICES ARE ALREADY SEEING WHY SUPPLIER DEPENDENCY MATTERS.

Supplier incidents are already creating practical problems for public bodies.

The Local Government Association's 2024/25 Strategic Market Insight and Relationship Programme review describes several supplier incidents affecting councils and residents, including incidents involving social care providers. It identified issues around incident-response planning, communication, contractual arrangements, confidence in suppliers and councils' ability to understand impacts on residents.

That matters because a supplier incident does not stay neatly inside the technology function. It can affect statutory responsibilities, frontline operations and people who may have no realistic alternative route to the service.

Central government is also highly dependent on cloud infrastructure. In a February 2026 parliamentary answer, the Government said around 55 per cent of surveyed central government organisations reported that more than 60 per cent of their estate was in the cloud. Every survey participant used one of two leading cloud providers.

Those figures do not prove that government is too dependent on those providers. They do show why dependency needs to be understood at service level. A concentrated market or a heavily used supplier only becomes a resilience problem when an organisation cannot continue, recover or switch within the time and disruption its services can tolerate.

Government policy is moving in the same direction. Updated proposals around critical suppliers recognise that disruption within technology supply chains can affect the continuity of essential and digital services where sectors rely heavily on particular suppliers.

HOW TO ASSESS TECHNOLOGY SUPPLIER DEPENDENCY: FIVE QUESTIONS FOR LEADERS.

Assessing supplier dependency starts with the service, not the supplier. The aim is to understand what would fail, what would be difficult to reproduce and whether an alternative could become operational quickly enough to protect service continuity.

Supplier registers, contract schedules and architecture diagrams all have value. None of them proves that a critical service can continue without its current supplier.

What service outcome would be affected?

Start with the service, not the supplier. If the supplier became unavailable, what would residents, staff or partner organisations no longer be able to do? Which statutory or operational responsibilities would be affected? How quickly would the consequences become serious?

What would actually stop working?

Look beyond the obvious technology. Consider identity, data, security, integrations, monitoring, backup, operational processes, specialist tooling and supporting suppliers. The most important dependency may be the component or capability needed to recover the service.

Which capabilities sit with the supplier rather than with us?

Who understands the configuration? Who holds the current documentation? Who knows how the service behaves under failure conditions? Which operational procedures depend on supplier personnel? Could internal teams diagnose and restore the service without them?

If knowledge or operational control sits predominantly with the supplier, leadership should know how difficult that capability would be to replace.

How long would it take to make an alternative usable?

An alternative supplier existing in the market does not mean the service can move quickly.

The Competition and Markets Authority has identified barriers affecting cloud switching and multi-cloud use, including interoperability, egress costs and software licensing. In March 2026, it said Microsoft and Amazon had taken material steps in some of these areas, while further work was still required to help UK customers switch and use multiple providers.

The relevant measure is not whether another provider exists. It is whether the organisation could establish a working alternative before disruption exceeds what the service, users or statutory obligations can tolerate. What committed spend, licence changes, transition costs or supplier support would that alternative require?

What have we actually demonstrated?

This is where assumptions become assurance. Has critical data been recovered and made usable elsewhere? Has deployment into an alternative environment been demonstrated? Can security and operational controls be recreated? Has the organisation rehearsed loss of supplier support? Are transition obligations understood well enough to exercise them?

Not every service requires the same level of proof. But where the consequences of supplier loss would be serious, an alternative that has never been tested should not automatically be treated as a dependable one.

NOT EVERY DEPENDENCY NEEDS TO BE REMOVED.

The answer is not to make every service supplier-neutral.

Provider-specific technologies and specialist managed services can deliver real benefits. They can reduce operational burden, provide capabilities that would otherwise be difficult to maintain and allow public-sector teams to focus scarce resources on service delivery.

Maximum portability carries costs too. It can increase architectural complexity, duplicate capability and force teams to maintain skills or systems they may rarely use.

The leadership task is to decide deliberately where those trade-offs are acceptable.

Some dependencies may be entirely reasonable. Others may need mitigation. For a critical service, the consequences of losing a supplier may justify investing in a tested alternative.

The important point is that those choices should be conscious rather than discovered after circumstances have already narrowed them.

UNDERSTAND THE DEPENDENCY BEFORE YOU HAVE TO TEST IT.

Preparing for supplier unavailability does not mean running two versions of every service or avoiding strategic technology providers.

It starts with knowing where the organisation is exposed.

For the most critical services, leaders need to understand which dependencies matter, what happens when they are removed, how long an alternative would take to establish and whether that alternative has ever been demonstrated.

That creates a much stronger basis for deciding which dependencies to accept, which to mitigate and where service portability warrants investment.

UBDS Digital's Digital Sovereignty & Service Portability service helps organisations examine those questions across the technology, data, operational, security, people and commercial dependencies surrounding critical services.

The purpose is not to eliminate reliance on suppliers. It is to understand where that reliance limits an option the organisation may one day need.

For our most critical services, do we know what we would do if the supplier was no longer there to help?

Explore our Digital Sovereignty & Service Portability services.