Operational resilience in the Nordics: Reducing third-party and cloud concentration risk

Nordic financial institutions run on cloud infrastructure, SaaS platforms, shared payments rails, cross-border data flows, and outsourced technology services to a degree few other markets can match. While advantageous from an efficiency perspective, Alex Viall, Global Relay’s Chief Strategy Officer, explains that recent cloud outages have reminded financial institutions of a hard truth: single points of failure can bring critical systems to a halt.

What do 3,000+ ICT incidents tell Nordic financial firms?

The short answer is that disruption is common, often external, and frequently crosses borders, highlighting that system failures can be as significant as cybersecurity attacks.  Operational resilience in financial services cannot be managed purely within the parameter of the organization, because of ICT third-party risk and cloud concentration risk.

The ESA’s first annual DORA incident report found that system failures accounted for 51% of major incidents, and 27% of external events, while roughly a third of major incidents originated from failures attributable to third-party providers. Cybersecurity breaches, despite dominating headlines, made up only 10% of cross-border incidents.

That’s more than double the total number of financial sector cyber events the International Monetary Fund recorded across the entire 2014–2023 period — in a single year. Operational incidents are, to some extent, unavoidable in a sector this digitized and interconnected. What matters is how quickly firms identify, contain, and recover from them.

What does the Nordic ICT incident picture look like?

Over the last few years, the region has been hit by a mix of massive third-party infrastructure failures, prolonged cyberattacks, and critical system glitches.

Finland

A prolonged cyberattack hit Finland’s financial sector in autumn 2024, resulting in a wave of sustained denial-of-service attacks. FIN-FSA described it as causing more prolonged customer disruption than any previous campaign. One of the notable incidents, which took place on October 25, 2024, disrupted Nordea’s online and mobile banking not just in Finland but simultaneously across Sweden, Norway, and Denmark. 

Sweden

The March 2025 Swish outage disrupted Sweden’s real-time mobile payment service for about an hour. Swish, used daily by millions of Swedes, relies on Sveriges Riksbank’s RIX-INST system, which in turn connects to TIPS, a shared instant-payment platform run by the European Central Bank. This event perfectly illustrates that concentration risk isn’t just a U.S.-hyperscaler-specific problem, but a shared-infrastructure problem.

Norway

BankID’s longest-ever outage (September 3–4, 2026) lasted over 30 hours, cutting off 4.2 million users. It was traced to a single technical supplier, DXC Technology, operating through national issuer Stø AS, and was caused by an internal infrastructure collapse. Notably, DXC’s infrastructure caused a comparable multi-day failure once before, in December 2021, making it a good illustration of unaddressed concentration risk over time.

Denmark

A spate of incidents in November 2024 caused widespread disruption across Denmark. A TDC core network crash causing widespread telephone failures nationwide coupled with Banedanmark’s digital signaling system failure was followed just a day later by an MitID outage, which blocked consumers from authenticating online card transactions. These examples present a striking illustration of how unrelated third-party and system failures can cluster and compound.

Why is third-party risk becoming operational risk?

Technology dependencies extend far beyond the vendor a firm signs a contract with. A financial institution’s chosen technology partner typically runs on a cloud provider, which in turn depends on its own network and infrastructure providers underneath — each link adding a dependency, which can be hard to see. Managing DORA third-party risk properly means identifying every ICT provider in your firm’s chain.

The September 2026 BankID outage in Norway demonstrates how fourth-party technology concentration creates systemic vulnerabilities when critical financial infrastructure relies on a single underlying vendor. While financial institutions can outsource service delivery, accountability for managing operational and ICT risk remains with the primary contracting entity.

Are Nordic financial firms too dependent on global hyperscalers?

This is the question at the heart of cloud concentration risk — and it isn’t as simple as finding alternatives to AWS, Microsoft Azure, or Google Cloud.

Cloud concentration risk, defined as how concentrated the sector’s collective dependencies have become on a single provider’s platform, is amplified when:

• Multiple critical services depend on the same underlying provider
• Several ‘independent’ vendors turn out to run on the same infrastructure
• Backup environments share the primary environment’s dependencies
• Switching providers would take significant time and cost
• A single regional outage can affect multiple services at once
• Exit strategies exist on paper but have never actually been tested

The scale of this exposure is now formally documented. In November 2025, EU supervisors designated the first 19 Critical ICT Third-Party Providers (CTPPs) and they now sit under DORA’s third-party oversight framework. The list includes AWS, Microsoft Azure, and Google Cloud alongside firms like IBM, Bloomberg, and the London Stock Exchange Group.

Regulators have observed that a majority of EU financial entities already rely on at least two of the three major hyperscalers for critical functions triggering key regulatory developments to help manage financial services cloud risk:

Country	Regulator	Key development	Focus areas
Sweden	Finansinspektionen (FI)	In-depth review of 50 financial companies, launched June 2025	Assessing DORA supply-chain implementation, run alongside Sweden’s adaptation of the EU NIS2 Directive (Cybersecurity Act)
Norway	Finanstilsynet	2026 Risk and Vulnerability Report; 2025 supervisory inspections	Judged infrastructure “robust” but flagged rising digital threat; expects scenario-planning for prolonged, simultaneous cloud outages; named BankID a single point of failure; found firms not taking sufficient ownership of vendor chains
Finland	Finanssivalvonta (FIN-FSA)	Confirmed its 2026 supervisory priorities	Operational reliability of digital financial services and payment infrastructure; requires formal ICT concentration risk assessment for every vendor relationship
Denmark	Finanstilsynet	Application of EBA outsourcing guidelines and its own Executive Order on outsourcing	Subcontracting, contingency planning, and exit strategy requirements; increasing scrutiny of non-EU cloud/technology dependence via the DORA Register of Information

What can major technology outages teach Nordic firms?

Failure type	Example	Question firms should ask
Cloud outage	AWS, October 2025 — 15+ hours from a US-EAST-1 region failure	Can critical systems continue without the primary provider?
Software failure	CrowdStrike, July 2024 — a faulty update grounded flights and disrupted banks globally	Could one supplier disrupt multiple, seemingly unrelated services?
Regional/CDN outage	Microsoft Azure, October 2025 — a configuration error in Azure Front Door	Is failover genuinely geographically independent?
Shared infrastructure failure	Cloudflare, November 2025 — an internal configuration change disrupted a meaningful share of global web traffic	Do supposedly separate vendors actually rely on the same infrastructure underneath?

What should Nordic firms ask their technology vendors?

Assessing technology vendor risk properly means pressing vendors on:

• What infrastructure delivers the service, and which cloud providers or subcontractors are involved
• Where infrastructure and customer data are hosted
• Whether the service can survive a provider or regional outage
• Whether backup infrastructure is genuinely independent, not nominally separate
• How often disaster recovery is tested, and what the recovery time and recovery point objectives are
• What happens operationally during failover
• What the vendor’s exit strategy is, and how quickly services could realistically be migrated

These key questions and more are covered in our article about how to choose an operationally resilient technology vendor.

What does a more resilient technology architecture look like?

If concentration risk is the problem, the fix starts with reducing single points of failure. The more vendors sitting in your supply chain, the more places an outage can originate. Building or choosing independent infrastructure gives firms greater control over their technology stack and fewer external dependencies to account for.

This is the logic behind Global Relay’s approach, which has spent over 25 years building technology for compliance, data storage, and communications monitoring. Our platform is designed to protect customer data and strengthen security and resilience for regulated industries — including some of Europe’s largest banks.

“At Global Relay, we take data security very seriously,” said Alex Viall, Chief Strategy Officer at Global Relay, in an interview with Nordic Fintech Magazine. “We believe a private cloud, end-to-end platform is the most secure solution.”

Because Global Relay builds its technology from scratch, its products are interlinked by design rather than stitched together across third-party systems. And as a privately owned company, it isn’t subject to mergers or acquisitions that can suddenly change a vendor’s ownership, priorities, or infrastructure. Global Relay’s tested redundancy and failover, a Continuous Integrity Checking process, and 24/7 operational support round out that resilience.

Final thoughts

DORA has shifted the conversation well beyond basic disaster recovery documentation and emphasizes the need for firms to know their technology infrastructure supply chains inside out.

Nordic financial markets’ high degree of digital interconnection is an advantage — but it also puts shared technology dependencies at the center of operational resilience in the Nordics.

The question every Nordic financial institution should be able to answer is this: do you understand every critical dependency underneath your technology services, and could you keep operating if one of them disappeared? Resilience is proven through tested failover, recovery, and exit capabilities, not through policy documents alone.

FAQs

What is operational resilience in financial services?
It’s an institution’s ability to keep delivering critical operations through disruption — covering internal governance, outsourcing, business continuity, and the broader technology ecosystem a firm depends on, not just its own systems.

What does DORA require for ICT third-party risk?
Financial entities must maintain a Register of Information covering all ICT third-party arrangements, assess concentration risk in those relationships, and build exit strategies. Providers designated as Critical ICT Third-Party Providers also face direct oversight from EU supervisors.

What is cloud concentration risk?
The risk that arises when multiple critical services — sometimes through supposedly independent vendors — ultimately depend on the same underlying cloud provider, so a single outage can disrupt many parts of the financial system at once.

What is fourth-party ICT risk?
The risk created by a vendor’s own subcontractors and suppliers. A financial institution may contract Vendor A but still depend operationally on Provider B further down that vendor’s supply chain.

How should firms assess the resilience of a technology vendor?
By looking past the contract to the underlying infrastructure: where services and data are actually hosted, whether backup environments are truly independent, how often failover and disaster recovery are tested, and how quickly the vendor could realistically be replaced.