The Trust Supply Chain: How One ICT Provider can become four risks at once
How a single compromised ICT provider can be a cyber incident, a financial concentration risk, a geopolitical exposure, and a regulatory obligation simultaneously under NIS2 and DORA.
There is usually a very tidy separation in how organisations file the various types of risk it faces during its lifetime.
- Cyber risk goes to the CISO.
- Financial risk goes to the CFO.
- Geopolitical risk goes to whoever reads the news most attentively.
- Regulatory risk goes to compliance.
Four inboxes, four owners, four quarterly reports.
This separation of risk may be comfortable but it is also fundamentally wrong, and a single compromised ICT provider is the cleanest proof of why.
Consider the mechanics.
A managed service provider, or a cloud platform, or a payment-processing vendor is breached.
Within hours that one event is
- A cyber incident for the CISO
- A concentration-risk problem for the CFO
- A jurisdictional-exposure question for whoever owns geopolitics
- A reporting obligation under at least two EU regulations for compliance.
Same event. Four domains. One failure point that the org chart insists on treating as four problems.
This is the first piece in a Risk Letters habit we intend to keep: looking at a single point in the threat landscape and refusing to let it stay in one lane.
We will be analytical and we will be specific.
We will also occasionally point out that the emperor's risk register really has no clothes.
Why the financial sector's largest attack surface is its trust relationships
Let's start with what the 2026 threat landscape actually looks like, because it has shifted in a way that makes the cross-domain point unavoidable.
The useful framing came from a Darktrace analysis early in 2026.
Software supply-chain attacks now dominate the threat landscape, with adversaries exploiting trusted build systems, CI/CD pipelines, and management tools to reach target environments.
A separate sector analysis put it more bluntly still — financial institutions in 2026 are being attacked through the systems and relationships that make modern finance work:
- Digital identity
- Remote access
- SaaS platforms
- Payment workflows
- Cloud infrastructure
- Customer devices
- And last but certainly not least - third-party providers.
Read that list again.
Not one item on it is a thing the financial entity fully owns.
Every item is a relationship — a dependency on someone else's security, someone else's uptime, someone else's jurisdiction.
The modern financial entity's attack surface is not its perimeter. It is its supplier list.
CrowdStrike's 2026 Financial Services Threat Landscape Report, published on 14 May 2026, gives the trend a number.
Hands-on-keyboard intrusions against financial institutions rose 43% globally over two years, and the report attributes much of that to adversaries exploiting trusted identities and SaaS applications to evade legacy defences.
The same report describes a China-nexus actor it tracks as MURKY PANDA operating a network of more than 150 compromised endpoints across 36 countries, targeting 340 organisations across more than 30 sectors — with financial services among the most frequently hit.
The mechanism there is not a frontal assault on a bank. It is the quiet compromise of the things a bank trusts.
So when a single ICT provider goes down, it is not an edge case. It is the threat model.
Domain one: the cyber incident
The first domain is the obvious one, and it is obvious for a reason — it is the one with a SOC watching for it.
When an ICT provider supporting a financial entity is compromised, the entity inherits the incident whether or not its own systems were touched. If the provider runs a critical function — payment processing, core banking, identity — the entity now has a live availability, integrity, or confidentiality problem sourced from infrastructure it does not control and often cannot directly observe.
The honest difficulty here is detection latency. The entity's own EDR sees nothing, because nothing on the entity's estate is misbehaving. The signal lives in the provider's environment, and the entity learns about it through one of three channels: the provider tells them, a threat intelligence feed tells them, or the regulator tells them. The first is the contractual ideal. The second is what good intelligence is for. The third is the one nobody wants.
This is where the cyber domain stops being self-contained. The moment the entity becomes aware, a clock starts — and that clock belongs to the regulatory domain.
Domain two: the financial concentration risk
The second domain is the one most likely to be misfiled, because it does not look like a risk until it looks like a catastrophe.
Concentration risk is the quiet accumulation of dependency. A financial entity does not decide one morning to route 70% of its critical functions through three providers. It arrives there one rational procurement decision at a time — each contract sensible in isolation, the aggregate a structural fragility that no single decision created and no single owner monitors.
When one of those providers is compromised, concentration is what converts a vendor incident into a balance-sheet event. If the provider is not readily substitutable — and the providers underpinning payments, identity, and core banking rarely are — the entity cannot simply fail over. It absorbs the disruption for as long as the provider takes to recover. The financial impact is a function not of the breach's sophistication but of the entity's own dependency geometry.
DORA's drafters understood this precisely, which is why concentration risk is not a footnote in the regulation but an explicit obligation. Article 29 requires financial entities to assess the risk arising from contracting a provider that is not easily substitutable, and the risk of multiple arrangements with the same or closely connected providers. The regulation is, in effect, telling CFOs and CISOs to look at the same supplier list and see the same thing. The org chart resists; the regulation insists.
We covered the mechanics of this in the reference layer — see DORA Third-Party Oversight for how Articles 28 to 30 operationalise it. The point for this analysis is narrower: concentration risk is financial risk wearing a cyber incident's clothes, and it is invisible until someone deliberately maps it.
Domain three: the geopolitical exposure
The third domain is the one organisations are worst at, because it requires looking past the provider to the provider's provider — and to the map.
Every ICT provider sits somewhere. Its data centres sit somewhere. Its subprocessors sit somewhere. Its engineering staff sit somewhere. Each of those locations carries a jurisdictional risk profile: the legal regime governing data access, the sanctions exposure, the likelihood that a local government can compel, disrupt, or surveil. A provider that is technically excellent and contractually impeccable can still route a critical function through a subprocessor in a jurisdiction that turns a commercial dependency into a geopolitical one.
This is not a hypothetical concern bolted on for drama. ENISA's Threat Landscape 2025 documented state-aligned threat groups intensifying long-term cyberespionage campaigns against telecommunications, logistics, and manufacturing in the EU, using supply-chain compromise as a primary technique. The CrowdStrike report attributes its most significant intelligence-collection threat to China-nexus adversaries specifically. We will be careful with attribution here — these are the assessments of the named intelligence vendors and ENISA, stated as their analysis, and the responsible reader treats them as such. But the structural point does not depend on any single attribution: if a critical function depends on infrastructure that touches a high-risk jurisdiction, the entity has imported a geopolitical risk into its operations, and most entities have not noticed because nobody drew the map.
The convergence is now explicit in the threat landscape itself. A 2026 European analysis described threat groups in which financial, ideological, and strategic motivations increasingly collide in the same operational space — a hacktivist crew using dark-web leak data to prepare an operation that also serves a state's interest, financed by ransomware. The neat taxonomy of "criminal versus state versus activist" has dissolved. For the entity trying to assess a provider, that dissolution means the geopolitical question — where does this dependency physically and legally live — can no longer be deferred to whoever reads the news.
Domain four: the regulatory obligation
The fourth domain is the one that has, helpfully, stopped being optional.
A compromised ICT provider supporting an EU financial entity triggers obligations under both major regimes simultaneously. Under DORA, the entity faces ICT-related incident management and reporting obligations, and the provider relationship itself sits inside the Pillar 4 third-party regime — pre-contractual assessment, the mandatory Register of Information, the prescribed contractual provisions, the tested exit strategy. Under NIS2, where the entity also operates in scope, the supply chain obligation of Article 21(2)(d) applies, and a significant incident triggers the 24-72-30 reporting cadence.
The two regimes do not stack arbitrarily — DORA is lex specialis for financial entities, and we mapped exactly how the displacement works in NIS2 vs DORA: Key Differences. But the analytical point stands: the regulator has formally recognised what the org chart has not. DORA and NIS2 are, in effect, legislative admissions that a supplier incident is simultaneously a cyber, financial, and operational-resilience event, and that treating it as only one of those is itself the failure the regulation is designed to catch.
There is a quiet irony worth naming. Compliance teams often experience DORA's third-party pillar and the Register of Information as bureaucratic weight — see DORA Register of Information: Template and Requirements for just how much structured data it demands. But the Register, built properly, is precisely the cross-domain map this whole analysis argues for. It is the artefact that lists every ICT dependency, classifies it by criticality, and — if the entity bothers — records where it lives. The regulator did not ask for paperwork. It asked for the map. Most entities are filling it in without realising they have been handed the answer.
How you would actually watch this — a note on method
Analysis is cheap. The harder question is operational: how does an entity actually monitor a four-domain risk that no single team owns? A short, practical note on method, because this is the craft Risk Letters exists to do.
You watch it from three angles at once.
Leak-site and underground monitoring. The CrowdStrike data point that 423 financial services organisations appeared on dedicated leak sites in the reporting period — a 27% year-on-year rise — is not just a statistic. It is a monitorable signal. A provider appearing on a leak site is an early indicator that an entity's dependency is compromised, often before the provider's own disclosure. OSINT-grade monitoring of leak sites and underground forums, scoped to your actual supplier list, converts the regulator's worst channel — finding out from someone else — into your second channel.
Dependency mapping by identifier. You cannot monitor a supplier list you have not built. The DORA Register of Information forces the financial sector to assemble one keyed on the Legal Entity Identifier — and that LEI keying is quietly powerful. It lets you map not just your providers but your providers' corporate families and, with effort, their subprocessors. A dependency graph keyed on LEIs is the substrate on which both concentration risk (domain two) and jurisdictional risk (domain three) become queryable rather than anecdotal.
Jurisdictional flagging. Once the dependency graph exists, you overlay the map. Each node — provider, subprocessor, data centre region — carries a jurisdiction, and each jurisdiction carries a risk profile. The flagging does not need to be sophisticated to be useful: even a coarse traffic-light overlay surfaces the critical function whose "EU cloud provider" quietly runs support operations through a region nobody on the risk committee would have chosen deliberately.
Three angles, one graph, one map. None of it requires exotic tooling. It requires the decision to treat the four domains as one surface — which is, in the end, the entire argument.
The takeaway
The org chart is a filing system, not a risk model. It files a supplier incident into whichever inbox noticed it first, and the other three domains find out later — often from the regulator, occasionally from the leak site, ideally from intelligence done properly.
Three things follow for anyone carrying this risk:
- A supplier is not a procurement line. It is a four-domain exposure. Cyber, financial, geopolitical, regulatory — every critical ICT dependency is all four simultaneously, and the entity that assesses it as only one is exposed on the other three.
- The map already exists, or DORA is making you build it. The Register of Information, treated as intelligence rather than paperwork, is the cross-domain dependency map. Use it as one.
- Cross-domain risk is monitorable. Leak-site signals, LEI-keyed dependency graphs, and jurisdictional overlays turn a vague "everything is connected" into a queryable surface. That conversion is the work.
Risk Letters exists because the four inboxes do not talk to each other and the threat landscape does not care. We will keep taking single points in that landscape and following them across every domain they touch — because that is where the risk actually lives.
For the regulatory mechanics underneath this analysis, the reference layer is built out: DORA Third-Party Oversight, NIS2 Supply Chain Security, and DORA Register of Information.
Sources & further reading
- ENISA — Threat Landscape 2025 (October 2025)
- ENISA — Threat Landscape: Finance Sector
- CrowdStrike — 2026 Global Threat Report (Financial Services) (May 2026)
- Darktrace — Threat Research
- Regulation (EU) 2022/2554 — DORA — Articles 28, 29 (third-party and concentration risk)
- Directive (EU) 2022/2555 — NIS2 — Article 21(2)(d) (supply chain), Article 23 (incident reporting)