Your Supplier’s Resilience Is Still Your Problem

For years, organisations have been moving more of their critical technology to cloud and managed-service providers.

The benefits are well understood. The concentration risk is becoming harder to ignore.

That is why the UK’s new Critical Third Parties regime is interesting.

Since 13 July, the FCA, Bank of England and PRA have begun directly overseeing four major cloud and technology providers whose disruption could have consequences across the UK financial system.

But there is an important detail.

Regulatory oversight of the supplier does not transfer accountability away from the organisation using it.

The FCA is explicit that firms and their boards remain responsible for their own operational resilience and management of third-party suppliers.

From an architecture perspective, that changes the conversation.

A supplier being large, regulated or highly resilient does not automatically make the service you build on it resilient.

The questions architects need to ask are more specific.

Where are the real concentrations?

A diagram might show several applications and suppliers while hiding the fact that they ultimately depend on the same cloud region, identity service, network provider or underlying platform.

Supplier diversity is not necessarily dependency diversity.

Can the important service actually recover?

Resilience architecture sometimes becomes a collection of controls: availability zones, backups, replication and disaster recovery plans.

Those things matter.

But the real test is whether the business service can continue within an acceptable level of disruption.

The Bank of England is already asking whether some systems supporting important business services may require stronger recovery options, including isolated rebuild environments or stand-in facilities capable of providing a minimum service.

That is a much harder architectural question than asking whether a platform has a good SLA.

Do we understand the dependency chain?

Critical services increasingly depend on suppliers that themselves depend on other suppliers.

Cloud, SaaS, identity, telecoms, data feeds, managed security and software libraries can create several layers between an organisation and the technology actually supporting its service.

The regulatory framework recognises this explicitly through requirements around supply-chain and nth-party dependencies.

Architecture therefore needs to make those dependencies visible enough to manage.

And finally:

Have we tested the assumptions?

The new regime requires Critical Third Parties to conduct scenario testing against severe but plausible disruption.

Organisations should apply the same thinking internally.

• What happens if the supplier is unavailable for longer than expected?
• What if identity is working but the network isn’t?
• What if the platform recovers but data integrity is uncertain?
• What minimum service could we still provide?
• And who makes the decision to invoke it?

These are architecture, operating-model and governance questions as much as technology questions.

There is a broader lesson here for the public sector too.

Government increasingly depends on a relatively small number of major technology platforms. Regulation may be different, but the architectural problem is very similar.

Outsourcing technology does not outsource dependency.

And it certainly does not outsource accountability.

Resilience starts with understanding what your service actually depends on — including everything outside your control.