Hyperscaler risk assessment for financial institutions

In this article, you will read

• what risks are associated with using US hyperscalers,
• what kill-switch scenarios entail,
• and how a hyperscaler risk assessment helps mitigate cloud risks and vendor lock-in.

Banks play a central role in national economies and are therefore designated as part of critical infrastructure (KRITIS). As such, they are subject to strict regulations and must continuously evaluate a broad spectrum of risks. This extends beyond their core business—where risk managers assess, for example, credit default risks and determine the required level of financial reserves (e.g., under Basel II and III).

The same question applies to the IT systems they use. With DORA, BAIT, MaRisk, and the guidelines of the European Banking Authority (EBA), regulatory frameworks already set specific requirements for banks. In the “old days” of on-premises systems, often managed by in-house IT teams or specialized financial IT providers, these requirements were relatively easy to meet. But when IT comes from the cloud, the financial sector needs new control mechanisms and governance concepts. Ultimately, collaboration relies much more heavily on trust, as banks and insurers place themselves in a position of dependency on their cloud providers.

That trust is being shaken by current geopolitical developments. Increasingly, decision-makers in the financial sector recognize that by running financial processes in the cloud, they are putting themselves in a position of strong dependency on their providers (vendor lock-in). US-based cloud providers, for example, are subject to the Clarifying Lawful Overseas Use of Data (CLOUD) Act, which grants the US administration access to data, even if the data is stored in Europe. Another major risk is the sudden discontinuation of services. European banks could find themselves cut off from cloud services overnight and unable to continue parts of their business.

Experts refer to this as a “kill switch” scenario. A kill switch, or emergency shut-off, is traditionally a safety mechanism designed to protect against danger. But in the cloud, it is the provider that controls the switch.

How realistic is this scenario? Hyperscalers have no interest in triggering such situations and will do everything possible to avoid them. Still, a residual risk remains. In the end, US authorities hold the stronger position, and US hyperscalers must comply with their requirements. The fact that the kill switch is more than just a theoretical concept is demonstrated by several real-world examples.

After the storming of the Capitol on January 6, 2021, the social media platform Parler hosted numerous posts explicitly inciting violence, including threats against politicians, tech CEOs, and entire population groups. AWS determined that these posts violated its Acceptable Use Policy, particularly since Parler had failed to implement effective content moderation over a seven-week period. On January 9, AWS notified Parler that it would suspend services effective January 10 due to risks to public safety. Parler was entirely dependent on AWS. When AWS shut it down, the platform had no internal infrastructure and no viable way to migrate to another provider in the short term. As a result, Parler remained offline for six weeks before resuming operations.

AWS’s actions were well-founded, principled, and reasonable. Nonetheless, the case highlights the extraordinary power a cloud provider can exercise.

One can debate the business value of social media platforms, but a second case shows the kill switch hitting the financial sector: the European Amsterdam Trade Bank, a subsidiary of Russia’s Alfa-Bank. In 2022, it was targeted by international sanctions following the war in Ukraine. AWS and Microsoft revoked its access to data and services, including core banking systems, databases, and customer access. Just a few weeks later, the bank declared bankruptcy.

In this case, the cloud providers acted in line with international sanctions. Yet it still demonstrates how quickly the withdrawal of cloud services can destroy an otherwise financially sound institution.

Opinions in Europe about whether these two kill switch incidents were justified are unlikely to diverge significantly. The situation looks different, however, in the case of Karim Khan, Chief Prosecutor of the International Criminal Court (ICC). Microsoft, under instructions from the US administration, blocked his account access for political reasons. This raises a troubling question: has the bar for activating the kill switch now been lowered?

Hyperscaler risks can be broadly divided into four categories: legal, technical, strategic, and financial. Dependence on hyperscalers exposes banks and financial institutions to vulnerabilities in each of these areas.

The previously mentioned kill switch scenarios fall under the category of technical risks. Service downtime, which can make systems temporarily unavailable, must also be considered. Downtime risks can usually be mitigated through redundancy, ideally with multi-cloud strategies. In addition, cloud services are high-value targets for cyberattacks. This risk can be reduced through measures such as encryption. Data residency with global cloud providers also falls within this category.

The most prominent legal risk of using hyperscalers arises from the US CLOUD Act. By relying on hyperscalers, users create a European foothold that gives US authorities access to “European” data. Simply put, US authorities treat US-based hyperscalers as virtual US territory.

Beyond the US CLOUD Act, European regulations must also be considered. The most prominent is the EU GDPR, which protects the personal data of European citizens. European courts have ruled in the past that US services fail to meet EU data protection standards. Cloud users must therefore implement specific compliance solutions. Banks must also observe industry-specific regulations and BaFin requirements.

The strategic risks of hyperscaler dependence mainly involve vendor lock-in. This raises questions about whether the services being used will remain available in the long term and what happens if a provider is changed. Hyperscalers often test new services and discontinue them if adoption is insufficient. While this makes sense for the provider, it creates risk for users who may be forced to find replacements. Users also have very limited influence over how cloud platforms evolve, resulting in significant loss of control.

If switching providers becomes necessary, not only do cost issues arise, but also challenges with migrating data. Data pipelines, development environments, and IAM tools are not always easily transferable, creating substantial risks.

Although hyperscalers offer cost-tracking tools, truly cost-efficient operations require monitoring through FinOps. Banks must also assess the risks of price increases and the costs of migrating out of the cloud. The ongoing discussions around tariffs with the US show that these risks are far from hypothetical.

How high is the risk of a kill switch situation for a European financial institution? Most likely minimal. However, risk always consists of two components: the probability of the event occurring and the potential impact. Companies that make heavy use of cloud services should regularly assess cloud risks. The extreme scenario of a kill switch is not usually the main focus.

Vendor lock-in, however, creates a range of smaller but still significant risks, such as discontinued databases or APIs, price hikes, or the withdrawal of third-party support. These situations can also disrupt operations. For this reason, financial institutions should know these risks, assess them, and maintain a Plan B or even a cloud exit strategy—just in case.

Ideally, a hyperscaler risk assessment covers three dimensions. It evaluates vendor lock-in risks, compares them with the company’s cloud sovereignty requirements, and generates a cloud risk management strategy from these two components.

Heavy dependence on a provider, such as the use of native or proprietary services, makes workload migration difficult and can affect business continuity. Non-technical factors such as certifications and contract terms must also be considered when switching providers.

Limited control over data and services can result in compliance issues. It is critical to evaluate the sensitivity of the data and services in use. The level of trust in the provider plays a decisive role, and geopolitical shifts can affect this trust. The question is: what level of control (sovereignty) does the company want, and what mechanisms must be implemented to achieve it?

From these two dimensions, vendor lock-in and sovereignty, an assessment is created using a heatmap. This shows the degree of dependence for each team or service on its cloud provider. Based on the results, consultants recommend mitigation measures. These may include quick wins as well as longer-term improvements such as adopting a multi-cloud solution.

With the support of the consulting firm Detecon, a comprehensive evaluation of a bank’s cloud risks can be completed in about nine weeks, depending on the size of the infrastructure. The process begins with a two-week preparation phase, during which the business strategy, cloud operating model, and relevant KPIs are identified. Typically, data from roughly a dozen key projects are reviewed. This is followed by a four-week analysis and assessment phase, which produces a heatmap of risks along with mitigation recommendations. Finally, a three-week qualification phase delivers the completed assessment. This phase results in the final report, including a feasibility analysis and cost estimates for training as well as for the adoption of new technologies or platforms.

Detecon consultants often recommend multi-cloud strategies (“don’t put all your eggs in one basket”) to reduce existing risks. In particular, sovereign European cloud offerings can play a key role in these approaches. This is where Open Telekom Cloud comes in. According to independent analysts, it is one of the leading European cloud platforms. Built on open-source technologies, it provides strong interoperability.

Open Telekom Cloud therefore serves as a valuable complement to US hyperscalers, strengthening sovereignty and reducing dependence on individual providers.

At the application level, dependence on specific platforms should also be minimized. Wherever possible, proprietary services should be avoided, and the use of containers is recommended to further enhance independence from individual vendors.