Every cloud architect, every financial services executive, and frankly every enterprise CTO should be paying attention to what is going on in the United Kingdom right now. Britain has formally designated Microsoft, Google, Amazon Web Services, and Oracle as “critical third parties” to the financial sector, meaning they are now subject to direct oversight by UK financial regulators rather than being treated as distant infrastructure suppliers outside the regulatory perimeter.

The designations took effect on July 13, 2026, and the oversight will be carried out by the Bank of England, the Prudential Regulation Authority, and the Financial Conduct Authority. The point is straightforward. If these platforms underpin critical banking and financial operations, then their resilience is no longer just a procurement issue. It is now a matter of financial stability.

This is a bigger deal than many people understand. For years, enterprises have treated cloud platforms as outsourced technology providers. Regulators are now making a different argument. They are saying that when enough banks, insurers, payment firms, and market infrastructures depend on the same small group of cloud providers, those providers become systemic infrastructure whether they like the label or not. Reuters reported that the UK’s framework will bring requirements such as resilience testing, self-assessments, and incident reporting directly to these providers. In other words, this is not just more policy language. It is operational oversight aimed at the platforms themselves.

The first thing to understand is that this move is not anti-cloud. It is the opposite. It is an acknowledgment that cloud has become too important to remain lightly touched when it comes to systemic risk. Regulators are not trying to unwind cloud adoption in financial services. They are accepting the reality that core financial operations now depend on a concentrated set of external platforms. When that happens, the conversation changes from vendor management to infrastructure resilience.

Systemic cloud concentration

The market has spent years talking about cloud concentration risk as if it were some vague future concern. It is no longer abstract. The UK is acting because concentration at this level means that a disruption at one major provider can ripple across multiple institutions simultaneously. That is the core issue. It is not whether Microsoft, Google, Amazon, or Oracle are competent operators. In many cases, they are exceptionally good at what they do. The problem is that too much critical activity depends on too few shared platforms.

This is a concept many business and technology leaders still struggle to internalize. A single bank can do a fine job managing its own vendor exposure and still be part of a broader systemic vulnerability if every other bank is relying on the same provider, the same region, the same identity layer, or the same operational dependencies. Regulators are stepping in because the risk is collective, not just institutional. That is why this matters well beyond the UK. It provides a framework for thinking about cloud not as outsourced capacity, but as part of the plumbing of the financial system itself.

Regulators expand their reach

Traditionally, regulators focused on the bank, insurer, or market institution and expected that entity to manage the risks created by outside suppliers. That approach still exists, and financial institutions remain accountable for their own resilience. However, the UK now says that, in some cases, this indirect model is not enough. If a third party becomes critical enough, regulators want direct line of sight into that provider’s resilience posture as well. This is probably the most important architectural and policy signal in the entire move.

That changes the relationship between the financial sector and the cloud providers in a meaningful way. Direct oversight means cloud providers are increasingly being treated less like optional technology partners and more like essential utilities that support national economic confidence. Once that happens, architecture decisions start to carry a different weight. Decisions about control planes, failover models, identity dependencies, regional design, observability, and incident response are no longer just internal engineering choices. They become part of a broader resilience conversation that may now include regulators.

A lot of enterprises have been behind the curve. They built architectures under the assumption that the cloud was simply a faster and cheaper hosting model. It is not. At scale, cloud is shared critical infrastructure. The UK has now made that point explicit.

More scrutiny isn’t more safety

It’s tempting to read this and assume the problem has now been solved. It has not. Direct oversight of hyperscalers does not remove the responsibility of banks or other enterprises to architect well. In fact, it should push them to architect better. A regulated provider can still be a concentration point. A resilient platform can still be used in a fragile way. And a well-run cloud service can still become part of a badly designed dependency chain.

If you are in a regulated or highly sensitive industry, you should take this as a warning that resilience can no longer be treated as a side topic. You need to know exactly which services are business-critical, which control planes are shared, which identity systems create cross-platform dependencies, and how your recovery assumptions actually work in the real world. Most organizations are much weaker here than they believe.

The UK’s move should also force a hard conversation about operational transparency. If regulators are requiring incident reporting and resilience evidence from major providers, enterprises should be demanding clearer dependency mapping and better architectural visibility inside their own environments. You cannot build true resilience on top of assumptions and vendor slide decks.

The start of a much larger shift

The deeper message is that cloud is crossing a line from enterprise technology choice into national and sector-level infrastructure policy. Once a few governments and central regulators start treating cloud this way, the rest of the world tends to follow in some form. We have already seen comparable concern in Europe, and now the UK has made its own move with direct designations and direct oversight.

Architects, CIOs, and boards need to mature their thinking quickly. The conversation is no longer limited to feature depth, discounts, migration speed, or which provider has the best AI story this quarter. The conversation is now about resilience, concentration, transparency, control, and systemic dependency. Those are bigger issues, and they are not going away.

The UK is telling the market something very clearly. Microsoft, Google, Amazon, and Oracle are not just selling cloud services into the financial sector. They are becoming part of the infrastructure on which that sector depends. Once you understand that, everything changes, including how we architect for the future.

A few years ago, I sat in a postmortem that I still think about. We’d had a production incident where a routine deploy had quietly shipped with the wrong configuration, and it took us longer to notice and roll back than anyone was comfortable admitting. But when we traced the root cause, almost none of it was the feature code. It was the scaffolding around it: a Kubernetes manifest no longer matched our cluster, a CI pipeline whose green checkmark didn’t actually verify the thing we assumed it did, and a secrets-management step that three different services each did three different ways. The code itself had been fine for a week. Everything around the code is what failed us.

I have seen some version of that retro at nearly every company I’ve worked at over the last 15 years across a large IT services firm, a medical-device maker, a healthcare-technology company, a cloud-migration startup, and now a large SaaS platform. The names and the tech stacks changed. The pattern didn’t. Smart engineers spending a startling share of their week not on the problem they were hired to solve, but on the accidental complexity of shipping it.

For a long time, I assumed the answer was better documentation, or a stricter DevOps culture, or just hiring people who were more comfortable with YAML. I was wrong on all three counts. What actually changed my mind was reframing the problem entirely: the friction wasn’t a knowledge gap or a discipline gap. It was a product gap. Nobody owned the developer’s experience of shipping software the way a product manager owns a customer’s experience of using an app. And the discipline that closes that gap now has a name: platform engineering, which Gartner describes as having “emerged in response to this increasing cognitive load resulting from the complexity of modern software tools and architectures.” Gartner isn’t shy about how fast it’s spreading, either: the firm predicts that “by 2026, 80% of large software engineering organizations will establish platform engineering teams,” up from 45% in 2022. If that number is even close to right, the interesting question is no longer whether to build a platform team but whether you’ll build a good one.

The moment “DevOps” quietly stopped scaling

I want to be careful here, because “DevOps is dead” is a lazy headline and I don’t believe it. The principles behind DevOps include shared ownership, automation, and tight feedback loops. These are as right today as they were when the movement started.

What broke, in my experience, was the operating model. The original promise was “you build it, you run it.” Every team owns its own deployment, its own observability, its own on call. That works beautifully when you have a handful of teams and a shared oral tradition. It falls apart when you have 50 teams, because now you have 50 slightly different ways of doing the same undifferentiated work. 50 ways to define a service. 50 subtly wrong Kubernetes configurations. 50 on-call rotations paging fifty engineers about the same class of problem at 3 a.m.

The cognitive load of “run it yourself” grew faster than most teams could absorb. That framing of cognitive load as the thing you’re actually optimizing for comes from “Team Topologies,” a book that reshaped how I think about org design more than any purely technical text I’ve read. Its fourth principle is blunt about the limit: “Teams can only handle so much complexity before breaking down,” and “competent teams become ineffective when leaders keep adding to their plate without taking anything away.” That last line described my own teams so precisely it stung. “Team Topologies” also gave me the vocabulary I’d been missing. It names four fundamental team types, and it defines a platform team as “a grouping of other team types that provide a compelling internal product to accelerate delivery by stream-aligned teams”. Read that definition again: a compelling internal product. Not a shared-services desk, not a Terraform repo with a wiki. A product. That single word is the whole argument.

Treating the platform as a product changes everything

Here’s the shift that took me embarrassingly long to internalize: if the platform is a product, then developers are its customers, and you don’t get to tell your customers they’re holding it wrong.

That one reframing has downstream consequences that surprised me.

The first is that adoption has to be earned, not mandated. Early in my time working on internal tooling, I helped build a platform capability that we were quite proud of, and then we did what infrastructure teams love to do: we announced it, and assumed people would come. They didn’t. Teams routed around it, because the golden path we’d paved was, frankly, gravel. The lesson landed hard. A platform that developers have to be forced onto is not a platform, it’s a tax. When we went back and rebuilt it so that the paved path was genuinely the easiest path. This is the same instinct behind Backstage, the developer portal that was built at Spotify and is now a CNCF project; its own pitch is that it “restores order to your microservices and infrastructure” so product teams can ship quickly. Order you have to opt into isn’t order. The tool wins when choosing it is the lazy option.

The second consequence is that “self-service” has to mean what it says. It’s an overused word, so I hold it to the CNCF’s definition from its platforms white paper: “A platform should be self-serviceable. Users must be able to request and receive capabilities autonomously and automatically.” Autonomously and automatically. If a developer has to file a ticket and wait on my team to provision a database, I haven’t built a platform instead I’ve built a slower version of the help desk. The same white paper states the north star plainly: “An essential goal of a platform is to reduce the cognitive load on product teams.” I’ve started using that sentence as a litmus test. For any capability we’re tempted to add, I ask whether it removes load from a product team or quietly adds some. A surprising number of well-meaning platform features fail that test.

The third consequence is that you have to measure the platform the way you’d measure any product and resist measuring the things that only flatter the platform team. “How many clusters are we running” is an output my team cares about and nobody else does. The metrics that matter describe the developer’s lived experience, and the most durable set I know of comes from DORA, the long-running research program into software delivery performance. Its metrics have evolved from the original “four keys” have grown to five. The core throughput measures still ask exactly the right questions: change lead time (“the amount of time it takes for a change to go from committed to version control to deployed in production”), deployment frequency, and failed deployment recovery time, balanced against a change fail rate. I’ve found those double as a remarkably honest scorecard for a platform team, precisely because they refuse to reward busywork. You cannot game your way to a good lead time by shipping more internal tools nobody uses.

The fourth consequence is the hardest culturally: a platform product needs a roadmap, user research, and the willingness to say no. I’ve watched platform efforts collapse into a junk drawer of one-off requests, each reasonable on its own, that together add up to an incoherent pile of tools nobody can hold in their head. Saying no to a well-intentioned request is a product-management skill, and platform teams that never develop it end up rebuilding the very sprawl they were created to eliminate. The best platform leads I’ve worked with spend as much time talking to their internal users as any consumer-facing PM does.

What I’d tell my younger self

If I could go back to that retro years ago, I’d say a few things to the version of me who thought this was a documentation problem.

Start with the paved road, not the platform. You don’t need to build an internal developer portal in quarter one. You need to find the single most painful, most repeated piece of undifferentiated work is the distance between “here is my container” and “it is running safely in production”. Earn the next piece of scope by delivering that one well. Platforms that begin as grand architectures tend to die as grand architectures; the ones that survive start as one genuinely useful paved road that people choose on their own.

Resist the urge to abstract away everything. The goal of a good platform is not to hide Kubernetes so completely that no one understands what’s happening beneath them; that just trades one kind of fragility for another. The goal is to remove the toil while leaving the understanding intact. When the abstraction leaks you want engineers who can reason about what’s underneath, not a room full of people who only ever knew the buttons. I’ve paid for both mistakes: platforms too thin to help, and platforms so thick that an incident turned into an archaeology dig.

And treat “developer experience” as a first-class business metric, not a morale nicety. Every hour an engineer spends fighting the delivery pipeline is an hour not spent on the thing your customers actually pay you for. When I frame platform investment that way to leadership as reclaiming a meaningful fraction of my most expensive people’s time that’s when the conversation stops being about cost and starts being about leverage. It is genuinely one of the highest-return investments an engineering organization can make, and it almost never shows up as a line item that looks like one.

The platform team is not the group that keeps the lights on. It’s the group that decides how fast everyone else can move. Once I started treating it as the most important product my organization ships internally, almost every other decision got easier. I just wish it hadn’t taken me a missed release and a room full of frustrated engineers to see it.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?