Technology has made it easier for businesses to build, launch and scale services. Cloud platforms provide infrastructure without the cost of owning it, APIs connect companies to capabilities they have not built themselves, and SaaS providers can take entire functions out of the internal technology stack. The result is a more flexible way of operating, but it also means businesses are increasingly dependent on systems they do not necessarily control.
This creates an important challenge for resilience. Adding technology can remove one point of failure while introducing another. A business may move away from a single physical datacentre, for example, only to become dependent on a cloud platform, several SaaS applications and a network of external APIs. The technology may be more scalable and efficient, but the overall environment is not automatically more resilient.
The cloud changes where dependencies sit
Moving infrastructure into the cloud can solve many problems associated with traditional IT. Businesses no longer need to manage every physical server themselves and can access additional capacity when required. Cloud platforms also make it easier to distribute workloads and adapt to changing demand.
But the cloud does not remove dependencies, it changes them. An application might run on one cloud platform while depending on a separate database, identity provider, security service, API gateway and several SaaS applications to deliver the experience a customer actually sees.
This matters because an individual component can be working perfectly while the overall service is unavailable. If an authentication provider goes down, for example, the application behind it may still be running normally. If an external API stops responding, the internal systems calling it may also be healthy. From an infrastructure perspective, there may be no obvious failure. From the customer's perspective, the service simply does not work.
The CrowdStrike outage in July 2024 provided a visible example of this interconnectedness. A software update affected an estimated 8.5 million Windows devices, according to Microsoft. Although this represented less than one percent of Windows devices, the impact was much wider because the software was used by organisations operating critical services.
The lesson is not that one particular technology is inherently unreliable. It is that resilience has to be considered across the connections between systems, not just within each individual system.
Financial infrastructure makes the problem particularly visible
Financial services provide a good example because customers rarely see the infrastructure behind a transaction. A payment may involve a company's own application, an identity service, a fraud provider, a payment processor, banking infrastructure and several other data or compliance services. To the customer, however, it remains one journey.
A service can therefore depend on several providers without that complexity being visible to the person using it. That is one of the advantages of modern technology, but it also means that a failure further down the chain can have consequences much further up it.
The UK financial sector is increasingly recognising this issue. In July 2026, the FCA, Bank of England and PRA began jointly overseeing four designated critical third parties: Amazon Web Services, Google Cloud, Microsoft and Oracle. The rationale is that disruption to services provided by these companies could affect multiple financial firms and markets because so many organisations rely on common technology providers.
The question is no longer only whether an individual bank, payment provider or fintech can withstand disruption. It is also what happens when many organisations rely on the same underlying technology.
More redundancy does not always mean more resilience
There is an understandable temptation to solve this problem by adding more technology. If one cloud provider creates concentration risk, use two. If visibility is limited, add another monitoring platform. If integrations are difficult to manage, introduce another layer between the application and the services it connects to.
Sometimes that is the right approach. But every additional layer also has to be operated and understood. A second cloud provider does not automatically provide resilience if an organisation cannot move workloads between environments. Having multiple APIs does not help if there is no tested process for switching between them.
The same applies to SaaS. Outsourcing a function can make a business faster and more efficient, but it also means an important process now depends on another organisation. As more functions move into third-party platforms, technology leaders need to understand not just what each provider does, but how important it is to the wider business.
This is increasingly reflected in financial regulation. The FCA's new rules around material third-party arrangements, which come into force in 2027, recognise that businesses can be exposed to significant risks from third-party services. Firms will need to identify and report material arrangements where disruption could cause serious harm or affect the stability and resilience of the wider financial system.
The underlying issue is simple: the more connected the technology stack becomes, the harder it is to understand where the real points of failure are.
The important question is what happens when something fails
Resilience is sometimes treated as a question of whether a system has enough backup capacity. In practice, it is more useful to start with the business service itself.
If customers cannot make a payment, which systems need to be working for that payment to complete? Which are internal and which are provided by third parties? If one provider becomes unavailable, is there another route, and has it actually been tested?
Not every dependency carries the same level of risk. An internal reporting system being unavailable for a few hours is very different from customers being unable to access their accounts or make payments. Treating every component as equally critical can lead to more technology, cost and operational complexity without necessarily improving the services that matter most.
The FCA's approach to operational resilience is built around this idea. Firms are expected to understand and map the people, processes, technology, facilities, information and third parties necessary to deliver important business services.
That is a useful principle beyond financial services. Resilience should be considered from the perspective of what the business needs to continue doing, rather than simply which pieces of infrastructure it owns.
AI is adding another layer
The same question is now emerging with AI. Businesses are introducing AI models and services into workflows that already depend on cloud infrastructure, APIs and SaaS platforms. In some cases, AI will become part of a customer-facing process rather than simply an internal tool.
That creates another dependency. If a workflow relies on an external model or AI service, what happens when it becomes unavailable? Can the process continue without it? Is there another provider? Does switching require a different API, data format or security arrangement?
This does not mean businesses should avoid AI, cloud computing or SaaS. These technologies can make organisations more flexible and give smaller businesses access to capabilities that would previously have required significant investment.
The point is that every new capability needs to be considered in the context of the wider system. Adding AI may improve a process, but if that process becomes completely dependent on an external service, the organisation has also introduced a new point of failure.
Resilience is becoming an orchestration problem
As technology becomes more distributed, resilience increasingly depends on understanding how different parts of the infrastructure interact.
Businesses need to know which services depend on each other, which providers sit behind important customer journeys and what happens when one part of the chain stops working. They also need to test those assumptions, because a recovery plan that worked two years ago may no longer reflect the technology stack that exists today.
The most resilient organisation is therefore not necessarily the one with the most technology. It is the one that understands the technology it depends on and has thought carefully about what happens when part of it becomes unavailable.
More technology can create more options. It can make businesses faster, more flexible and more capable. But if every new capability introduces another dependency that nobody has mapped or tested, it can also create a more complicated route to failure.
The goal is not to build an environment where nothing ever goes wrong. That is unrealistic. The goal is to build an organisation that understands where failure can happen, knows which failures matter most and can continue operating when they do.
As technology stacks become more fragmented, the ability to orchestrate them may become just as important as the technology itself.
Philipp is a serial entrepreneur with extensive experience of working in Challenger Banking, Financial Services, IT and Energy across the world. He took one of his businesses public - Ignis Petroleum was publicly listed in the US and Germany.
Having started as a developer in Financial Services, Philipp has first-hand experience of the banking revolution from both a technology and financial perspective. His interest in behavioural economics helped inspire AAZZUR’s revolutionary work on customer centricity in banking.
Philipp holds an MBA from the London Business School. He is passionate about entrepreneurship and loves exchanging ideas, insights and discussing FinTech's future. He has spoken at major Fintech events including Money 20/20, MoneyLive, Finovate, Fintech Matters, and the Future of Retail Banking.