Third-Party Risk Management (TPRM) for Financial Institutions: DORA, UK and US Regimes Compared

How do you manage third-party risk when many institutions rely on the same few providers? Learn how DORA, the UK regime and US guidance compare, why concentration and fourth-party exposure need a sector-level view, and how to build the programme.
Risk Ledger
|
Company
October 13, 2026
|
8
mins read
Third-Party Risk Management (TPRM) for Financial Institutions: DORA, UK and US Regimes Compared

Published 30 April 2024. Last updated October 2026.

Rebuilt to add the EU and UK designations of critical providers, concentration and systemic risk, supplier fatigue, continuous monitoring, a comparison of DORA, UK, US and NIS2 rules with NIST CSF and ISO 27001, and named systemic risk vectors (SWIFT, central counterparties, CBDCs).

‍

Third-party risk management (TPRM) for financial institutions is the identification, assessment and monitoring of risk from suppliers and those suppliers’ own suppliers, carried out by each firm for its own supply chain, alongside direct regulatory oversight of the providers the whole sector relies on.
‍

Key Takeaways

  • Each firm manages risk from its own suppliers. Separately, authorities designate and directly oversee providers critical to the whole sector: 19 in the EU (November 2025) and four in the UK (July 2026) so far.
  • Under the EU's Digital Operational Resilience Act (DORA), applicable since 17 January 2025, financial entities must maintain a Register of Information covering all ICT third-party arrangements.
  • In the US, the Federal Reserve, FDIC and OCC's June 2023 interagency guidance treats third-party risk as a lifecycle from planning to termination, with the board accountable for outsourced activities.
  • The FCA reported that third-party related issues were the leading cause of operational incidents reported to it in 2022 and 2023.
  • Verizon's 2026 Data Breach Investigations Report found third-party involvement in confirmed breaches rose to 48%, up from 30% the previous year.
  • Concentration risk exist when several of one firm's critical functions rely on the same provider or when several critical suppliers all rely on the same fourth party. Systemic risk exists when many firms in the sector rely on the same provider, and it becomes visible only when data is combined across firms.
  • In a 2024 Risk Ledger pilot with a group of six banks, connecting them to 395 of their direct suppliers on the platform revealed an additional 877 connections across their nth parties, and 47 systemic concentration risks including 9 suppliers connected to at least half the cohort.
  • In the 2023 MOVEit breach, a shared provider's use of the software exposed 2.5 to 2.7 million Genworth Financial customers and agents and more than 2.3 million TIAA retirees and pension holders.
  • DORA requires a major incident to be notified within 4 hours of classification, and within 24 hours of awareness at the latest. UK rules from 18 March 2027 require an initial report within 24 hours of determining a threshold is met.
    ‍

Introduction

A financial institution's operations rely heavily on suppliers: payment processors, cloud platforms, core banking software, data providers, outsourced service teams. When one of them fails, its clients are also impacted.

The FCA reported that third-party related issues were the leading cause of operational incidents reported to it in 2022 and 2023. Verizon's 2026 Data Breach Investigations Report found third-party involvement in confirmed breaches had risen to 48%, up from 30% the year before.

Supply chain cyber security in financial services faces a particular conundrum: The same small group of providers serves many institutions at once, so a single failure can impact a large part of the sector. In 2023, a flaw in MOVEit file-transfer software reached Genworth Financial and TIAA through a shared provider, PBI Research Services. A firm's own supplier list only reveals its direct relationships. It does not show who else relies on the same providers, or who those providers rely on themselves.

Authorities have thus started to look at the sector as a whole. EU supervisors designated 19 Critical ICT Third-Party Providers in November 2025, and HM Treasury designated the first four UK Critical Third Parties in July 2026. Designated providers come under direct regulatory oversight, yet each firm remains responsible for its own suppliers.

This guide covers third-party risk management in financial services, from a firm’s own programme to the sector-level oversight now sitting above it. It starts with what the discipline involves, then looks at why it is harder for financial institutions than for many other sectors: the effort suppliers spend on near-identical assessments, and the providers that cannot realistically be replaced. It then takes a deep dive into fourth-party and concentration risk, the TPRM lifecycle and continuous monitoring, as well as looks at how the main regimes in the EU, UK and US compare, and finally provides examples of how financial institutions are mapping their supply chains in practice.
‍

What is third-party risk management in financial services?

Third-party risk management (TPRM) is the practice of identifying, assessing and monitoring the risk that an organisation's external suppliers, vendors and service providers introduce to its operations, data and customers. In financial services, the same discipline applies, but with one structural difference: a small number of critical providers, particularly in cloud, payments and core software, sit underneath a large share of the sector at once, so a failure at one of them rarely stays contained to a single institution.

That difference matters because oversight now works at two levels. At firm level, each institution tiers, assesses and monitors its own suppliers. At sector level, authorities designate certain providers as critical and oversee them directly. DORA’s designation of 19 Critical ICT Third-Party Providers in November 2025, and the UK’s designation of its first four Critical Third Parties in July 2026, are both examples. Designation does not change what firms must do about those providers. Under DORA, a firm remains responsible for its own obligations “at all times” (Article 28(1)(a)).

For a TPRM team, assessing your own suppliers well is still the core task. Regulators, however, also see the supply chain from a sector-wide vantage point, which shows concentration across institutions rather than exposure within a single firm. The rest of this guide covers both: what a strong programme looks like at firm level, and what oversight at sector level means for it.
‍

Why financial institutions face distinct TPRM pressures

Financial institutions carry a heavier TPRM burden than most sectors for two structural reasons: they share a small number of critical infrastructure providers across the whole industry, and they answer to overlapping regulatory regimes that each demand a different form of oversight over the same suppliers.

A firm operating across the EU, UK and US must satisfy DORA’s Register of Information and incident-reporting clocks, the UK’s operational resilience rules and Critical Third Parties regime, and the US interagency guidance on third-party relationships. That is three regimes with three sets of mechanics, applied to one supplier base that has to be documented three times.

The scale of the underlying threat is enormous. ENISA's first sector-specific analysis of the European finance sector recorded 488 publicly reported cyber incidents between January 2023 and June 2024, with banks the single most-targeted entity type at 46% of all incidents — see the full ENISA Threat Landscape: Finance Sector report. Third-party involvement in breaches more broadly increased year-on-year, from 30% to 48%, according to Verizon's 2026 Data Breach Investigations Report.

The UK’s own regulator makes the point most directly. Following the July 2024 CrowdStrike outage, the FCA stated that between 2022 and 2023, third-party related issues were the leading cause of operational incidents reported to it. That comes from a supervisor with direct visibility into what goes wrong inside firms.
‍

Supplier fatigue: Why bilateral TPRM doesn't scale

A supplier serving several financial-services clients is typically assessed by each one separately, answering largely the same questions about the same controls in different formats, on different schedules, with no shared record of what it has already told anyone else. The result is duplicated effort on both sides, without a proportional increase in genuine assurance.

Questionnaires remain a legitimate way to capture evidence a supplier can’t provide any other way. The difficulty lies in the one-to-one, repeated-from-scratch model behind them, and the regulatory direction of travel adds to it. DORA requires every in-scope entity to independently maintain a Register of Information covering its ICT third-party arrangements (Article 28(3)), and from 18 March 2027 the UK will require a comparable register of material third-party arrangements under the FCA and PRA’s joint framework. Every one of a supplier’s clients now has its own separate obligation to document essentially the same relationship.

The practical effect compounds over time: assessment volume rises for shared suppliers, but rising volume through the same bilateral channel doesn't automatically raise assurance quality, and it draws heavily on the same limited compliance and security resource on both sides of the relationship.
‍

Why financial Institutions can't just "switch vendors" easily: Tier 1 lock-in

Some suppliers can't realistically be replaced, and DORA now requires firms to say so explicitly. Article 29 obliges financial entities to assess concentration risk arising from contracting a provider that isn't easily substitutable, or from holding multiple critical arrangements with the same or closely connected provider — putting a regulatory label on a problem TPRM teams have lived with for years.

The clearest illustration of what happens when shared infrastructure fails isn't a cloud outage — it's the 2016 Bangladesh Bank heist. Attackers used compromised credentials to send fraudulent instructions over the SWIFT messaging network, attempting to move $951 million out of the bank's account at the Federal Reserve Bank of New York; $81 million was successfully diverted to accounts in the Philippines before a misspelled beneficiary name triggered a manual check that halted the rest, as Reuters reported at the time. Nobody's core systems at SWIFT were breached — the exposure sat entirely in how a shared, effectively irreplaceable messaging network could be exploited at the customer end. SWIFT’s response applied to the whole user community. Its Customer Security Programme requires every user to implement a common set of mandatory controls and to attest annually, with the attestation supported by an independent assessment.

Central clearing shows the same dynamic on the trading side. Per the Bank for International Settlements, more than half of outstanding over-the-counter interest rate derivatives are now centrally cleared, against around one fifth in 2009, which is a BIS estimate. That concentrates risk in a small number of central counterparties. The BIS has warned that this creates a “CCP-bank nexus”, in which stress at one can amplify stress at the other.

None of this means concentration risk should automatically trigger a search for an alternative provider. As later sections cover, the more realistic response is understanding the exposure clearly enough to manage it deliberately.
‍

Fourth-party (Nth-party) risk in financial supply chains

Fourth-party risk is the exposure created not by a financial institution's own supplier, but by that supplier's suppliers — a layer most TPRM programmes never formally assess, because the contractual relationship simply doesn't extend that far.

The 2023 MOVEit breach shows how this works in practice. Attackers exploited a zero-day vulnerability in Progress Software’s MOVEit file-transfer tool, and Cybersecurity Dive’s reporting at the time counted more than 600 affected organisations. Financial services firms were exposed through a shared service provider. PBI Research Services, a provider used by Genworth Financial and TIAA, ran MOVEit, and its compromise exposed data on between 2.5 and 2.7 million Genworth customers and agents, as disclosed in Genworth’s own SEC filing, and on more than 2.3 million TIAA retirees and pension holders, according to a lawsuit complaint reported by PLANSPONSOR. In both cases the exposure arrived through the provider’s use of the software.

Regulators are aware this layer matters but are also being careful not to over-correct. In July 2024, the European Supervisory Authorities submitted draft technical standards requiring firms to monitor their subcontracting chains; the European Commission formally rejected part of that draft in January 2025, ruling that a blanket subcontractor-monitoring obligation went beyond the mandate DORA had actually given the ESAs. The final, narrower standard — acknowledged by the ESAs in March 2025 — asks firms to assess subcontracting arrangements supporting critical functions, not to track every subcontractor indiscriminately. The direction of travel is real oversight of this layer, applied proportionately rather than as an unlimited obligation.

What this looks like in practice, at genuine depth, is covered in the evidence section later in this guide, where a tier-1 bank's own supply chain mapping surfaced dependencies four, five and six layers removed from its direct suppliers within 48 hours.
‍

Concentration risk and systemic risk: How regulators are mapping the hidden ecosystem

Concentration risk and systemic risk sound similar but describe two different problems. Concentration risk is when several of a firm's own critical functions depend on the same or closely connected provider — something the firm can see if it looks at its own arrangements — or when several of a firm's direct suppliers all depend on the same fourth party (this could also be the case beyond 4th parties). Systemic risk is when many firms across the sector depend on the same provider — something no single firm can see, because none of them can look at their competitors' supply chains.

That second problem is precisely what regulators are increasingly seeking to tackle. DORA requires every in-scope firm to submit its Register of Information; the ESAs then aggregate those registers across the entire EU financial sector, and used the resulting picture to designate the first 19 Critical ICT Third-Party Providers in November 2025 — a decision no individual firm's own risk assessment could have produced, because it depends on seeing everyone's dependencies at once. The UK's Critical Third Parties regime works on the same underlying logic through HM Treasury designation, covered earlier in this guide.

The Financial Stability Board has stated the concern plainly: systemic risk can arise when a large number of firms, or one systemically important firm, become dependent on one or a few hard-to-substitute providers, such that a major disruption at that provider creates a single point of failure with consequences for the financial system as a whole — not just for the firms directly affected.

This same logic is now being applied ahead of a risk that hasn't yet materialised. The Bank for International Settlements has examined the third-party and operational risks central banks will face when issuing Central Bank Digital Currencies, noting that central banks will likely need to partner with private-sector technology vendors to build CBDC infrastructure, and that due diligence over those vendors needs to be designed in from the start rather than added later. The BIS is careful to note there have been no known successful cyberattacks on live CBDC systems to date — this is a forward-looking design consideration, not a documented incident, and should be read that way.

What this looks like when it's actually tested is covered in the evidence section of this guide, where a six-institution pilot mapping exercise found systemic concentration risks that none of the participating institutions knew they shared.
‍

What a mature TPRM programme looks like in Finance

A mature TPRM programme keeps supplier evidence current rather than reviewing it once a year, prioritises the suppliers that genuinely matter to critical services rather than treating every relationship the same, and can answer "are we exposed?" within hours of an incident breaking elsewhere in the supply chain — not after a scramble to work out who's affected.

This isn't a claim that existing programmes are failing. Most financial institutions already run structured TPRM; the shift described here is about what "structured" needs to mean given the regulatory and threat environment covered earlier in this guide. Annual assessment cycles, DORA's Register of Information, the UK's incoming material third-party register, and faster incident-reporting clocks (4 hours, 24 hours, 72 hours, depending on the regime) all point the same way: static, once-a-year evidence is no longer enough on its own to demonstrate the oversight regulators expect.

There's a direct regulatory endorsement of why the mapping discipline specifically pays off operationally, not just for compliance. The same FCA review of the July 2024 CrowdStrike outage cited earlier in this guide found that firms which had already mapped their important business services, and the resources behind them, were better able to prioritise which services to restore first and reduce the overall impact of the disruption. Mapping wasn't a paperwork exercise for those firms — it was the thing that let them make faster, better decisions during a live incident.

The rest of this guide sets out what building toward that maturity actually involves: the practical lifecycle of assessing and monitoring a supplier, how to satisfy the regulatory frameworks now in force, and where a platform like Risk Ledger fits into that picture.
‍

The TPRM lifecycle: From vendor tiering to offboarding

The TPRM lifecycle runs from identifying which suppliers matter, through assessing and monitoring them, to formally ending the relationship — and offboarding is the stage most programmes underbuild, despite regulators now treating it as a distinct, documented requirement rather than an afterthought.

Supplier inventory and criticality tiering. This stage now has a regulatory floor, not just a best-practice rationale. DORA's Register of Information requires every in-scope firm to maintain a structured record of its ICT third-party arrangements, and the UK's incoming material third-party register imposes a comparable obligation — both covered earlier in this guide. Tiering should go beyond "is this a supplier" to identify which suppliers support important business services specifically, since that's the unit regulators actually assess against.

Risk assessment and evidence collection. The UK's operational resilience regime asks firms to map not just the supplier, but the people, processes, technology, facilities and information behind each important business service — set out in the PRA's SS1/21. A supplier assessment that stops at "what controls does this vendor have" misses what regulators expect firms to understand about their own dependency.

Remediation. Findings need to translate into tracked actions with owners and deadlines, not sit in an assessment report. This is also where concentration risk (covered earlier) should get flagged explicitly, since it changes the remediation conversation from "fix this control" to "understand this dependency."

Reassessment. Point-in-time review needs a defined cadence rather than an ad hoc one — covered in more depth in the next section on continuous monitoring.

Offboarding. DORA requires financial entities to have documented, tested exit plans for critical ICT arrangements, including identified alternative providers and a transition plan for removing data and services from the outgoing provider. This is a meaningfully different bar than "we could probably switch if we had to" — it requires the plan to exist and to have been tested before it's needed, not worked out under pressure during an actual exit.
‍

Continuous monitoring in financial services

Continuous monitoring, per NIST's official definition, means maintaining ongoing awareness of information security, vulnerabilities and threats to support risk management decisions — as distinct from a point-in-time assessment, which only tells you what was true on the day it was completed.

The distinction matters more in finance now than it did even two years ago, because of the reporting timelines covered earlier in this guide. DORA requires classifying and reporting a major incident within 4 hours, and no later than 24 hours from first becoming aware of it. The UK's incoming framework sets a comparable 24-hour initial notification requirement upon determining that a threshold is met. Both assume the firm already understands its exposure before an incident happens — there's no time built into either timeline to first work out which suppliers are affected. A supplier assessed once a year, with evidence that may already be stale by the time of review, can't support that speed of response.

This doesn't mean annual assessment has no value — the underlying evidence a supplier provides during a formal review still matters. What changes is the assumption that evidence stays accurate between reviews. Regulators increasingly expect firms to know whether a supplier's control environment has changed since the last assessment, not just what it looked like at the last assessment date.

This section deliberately stays brief — for the full breakdown of monitoring cadence, tooling approaches and their limitations, see Risk Ledger's dedicated guide to continuous monitoring in TPRM.
‍

Mapping TPRM controls to DORA, the UK regime, FFIEC, NIS2, NIST CSF and ISO 27001 

Financial institutions operating across the EU, UK and US now answer to genuinely different mechanics for the same underlying problem: DORA runs on a data-collection and direct-oversight model, the UK combines impact tolerances with material-third-party reporting, and the US relies on principles-based supervisory guidance rather than a comparable register.
‍

How the main regimes approach third-party risk

Regime Core third-party mechanism Reporting timeline Where concentration or systemic risk is addressed
EU: DORA Register of Information of all ICT third-party arrangements (Article 28). Direct ESA oversight of designated Critical ICT Third-Party Providers. Major incident: initial notification within 4 hours of classification and no later than 24 hours from awareness. Intermediate report within 72 hours of the initial notification. Final report within one month. Named explicitly in Article 29: substitutability and closely connected providers.
UK Impact tolerances for important business services (PRA SS1/21). Critical Third Parties regime, with providers designated by HM Treasury. Register of material third-party arrangements from 18 March 2027 (FCA PS26/2, PRA PS7/26). From 18 March 2027: initial incident report within 24 hours of determining that a threshold is met. Update on significant change. Final report within 30 working days of resolution. Payment services firms: 4 hours from detection. Addressed through Critical Third Parties designation, which applies where a provider's disruption could threaten financial stability.
US Interagency guidance from the Federal Reserve, FDIC and OCC (June 2023): lifecycle-based, principles rather than prescriptive rules, with the board accountable. FFIEC IT Examination Handbook booklets used by examiners. SEC Item 1.05 (public companies): disclose a material cybersecurity incident within four business days of determining it is material. Firms assess concentration and subcontractor risk themselves under the interagency guidance. The agencies also run a risk-based supervisory programme for technology service providers.
EU and UK: NIS2 and the Cyber Security and Resilience Bill Cross-sector regimes: NIS2 in the EU and the Cyber Security and Resilience Bill in the UK (introduced 12 November 2025), covering managed service providers and critical suppliers. Cross-sector incident notification duties. For EU financial entities, DORA applies to ICT incident reporting. Address supply chain risk in general, with no finance-specific concentration rules.

Sources: DORA (Regulation (EU) 2022/2554); PRA SS1/21; FCA PS26/2; Federal Reserve, FDIC and OCC interagency guidance (2023); SEC cybersecurity disclosure rules.

‍

DORA is the most prescriptive of the four on third-party specifically — it was the first with a live, published list of designated systemically critical providers. The UK's Critical Third Parties regime follows the same logic but is newer in practice, having only produced its first designations in July 2026. The US approach is deliberately less prescriptive: the interagency guidance sets expectations for how a firm manages third-party risk rather than designating specific providers for direct federal oversight, which means concentration risk in the US is currently something firms are expected to assess themselves rather than something regulators independently map.

For EU financial entities, DORA takes precedence over NIS2 for ICT incident reporting specifically, as DORA constitutes lex specialis. The UK's Cyber Security and Resilience Bill, introduced 12 November 2025, is cross-sector rather than finance-specific, but is directly relevant to financial institutions' technology suppliers where those suppliers qualify as large managed service providers or designated critical suppliers under the Bill.

A note on FFIEC. The Federal Financial Institutions Examination Council publishes the IT Examination Handbook that examiners use when assessing financial institutions' technology risk management. Two of its booklets address third parties directly: Outsourcing Technology Services, which covers establishing, managing and monitoring service provider relationships, and Supervision of Technology Service Providers, which describes the agencies' risk-based supervisory programme for those providers. The Handbook is examination guidance rather than a rule set, and it sits alongside the June 2023 interagency guidance issued by the Federal Reserve, FDIC and OCC. Check current expectations against the Handbook and the Federal Register text linked above, rather than a secondary summary.
‍

Where NIST CSF and ISO 27001 fit

NIST CSF and ISO/IEC 27001 are voluntary frameworks published by standards bodies. They are not regulations, which is why they sit outside the comparison table above. Both address supplier oversight directly, so they are useful reference points when a firm decides what ongoing monitoring of a supplier should cover.

NIST Cybersecurity Framework 2.0, released in 2024, added a Govern function and gave supply chain risk its own category within it: GV.SC, Cybersecurity Supply Chain Risk Management. NIST also published a quick-start guide for cybersecurity supply chain risk management (SP 1305), which explains how to use that category to set up a supply chain risk capability.

ISO/IEC 27001:2022 covers suppliers in a group of Annex A controls, A.5.19 to A.5.23. Control A.5.22 is titled "Monitoring, review and change management of supplier services", so the standard covers all three activities in a single control.

For a TPRM team, the value is practical. Supplier controls described against a recognised framework can be compared across suppliers, and read against whichever framework a given client uses. Neither framework replaces the regulatory requirements covered in this section. They give firms a common structure for the evidence those requirements depend on.
‍

Moving from qualitative to quantitative Risk scoring

Qualitative scoring is a reviewer's judgement about a supplier's controls, measured against a framework. Quantitative scoring assigns comparable numeric values across suppliers so they can be ranked, aggregated and reported consistently — including at portfolio or sector level, which qualitative review alone can't produce.

The European Central Bank's own supervisory analysis illustrates why the aggregated view matters. Drawing on outsourcing registers collected from significant banks, the ECB found that more than 30% of total outsourcing budgets is concentrated on just ten providers, and half of all spend on critical-function contracts goes to only 30 providers. No individual bank's own qualitative supplier reviews would surface that pattern — it only becomes visible once data is aggregated across many institutions and compared on common, quantitative terms.

This is precisely the gap a six-institution pilot mapping exercise (covered in full in the evidence section of this guide) was designed to test. Six financial institutions connected their supply chain data within a shared environment, and the resulting analysis found nine suppliers connected to at least half the cohort, three of which no participating institution knew they shared. Each institution's own qualitative review of its own suppliers had been perfectly reasonable — the finding only emerged once the data was made comparable and aggregated across institutions, which is a quantitative exercise by definition, not a qualitative one.

Neither approach replaces the other. Qualitative review still captures the judgement and context a numeric score can't — why a control gap matters for a specific relationship, not just that it exists. Quantitative scoring is what makes that judgement comparable at scale, reportable to a board, and able to reveal patterns no single review would catch.
‍

Best practices for scaling TPRM in a regulated environment

TPRM improvements land fastest when they're aimed at the constraint that's actually binding: limited people, limited time, and a growing list of regulatory obligations that don't scale down for smaller teams.

Align TPRM to enterprise risk strategy. Third-party risk shouldn't sit in its own silo, disconnected from operational resilience, threat intelligence and procurement. The regulatory frameworks covered throughout this guide increasingly expect exactly this integration — the UK’s impact tolerance rules and DORA’s register requirements, for instance, only work if risk, resilience and procurement teams are looking at the same data.

Secure cross-functional buy-in. Legal, procurement, security and commercial teams all touch supplier relationships at different points; a TPRM programme that only involves the security function will keep missing context the others hold.

Apply a risk-based approach. Not every supplier needs the same depth of assessment. Effort should concentrate on suppliers that support important business services or critical functions — the same units of analysis regulators are now asking firms to identify explicitly.

Integrate TPRM into procurement, early. Assessing substitutability before a contract is signed — the same question DORA's Article 29 asks firms to answer for existing arrangements — is far cheaper than discovering lock-in after the fact.

Invest in automation to sustain monitoring at scale. Given the reporting timelines covered earlier (DORA's 4-hour classification window, the UK's 24-hour initial notification), manual processes struggle to keep pace regardless of headcount.

Deloitte's DORA European Survey, conducted in early 2025 among 36 financial entities across 28 countries, shows how far the industry still had to go. Only 8% of participants reported full compliance with the ICT third-party risk management pillar, the same share as for digital operational resilience testing, against 48% for incident management. Half expected to reach full compliance by the end of 2025, and 38% in 2026. For 46% of entities, the register of information was the most challenging task.
‍

How Risk Ledger supports TPRM for financial institutions

Everything covered so far in this guide — regulatory pressure, concentration risk, fourth-party exposure, supplier fatigue, the shift toward continuous evidence — points toward the same operational gap: keeping supplier evidence current, understanding dependencies beyond the direct relationship, and responding quickly when something changes. This is where Risk Ledger fits.

Reusable supplier evidence. Suppliers maintain one profile, which they can share across every client relationship on the network, while each client applies its own policies and review requirements on top. The questions in that profile come from Risk Ledger’s standardised assessment framework, which is mapped against NIST CSF, ISO 27001 and the NCSC’s Cyber Assessment Framework, so a supplier’s answers can be compared against those frameworks. This answers the fatigue problem covered earlier in this guide. Suppliers still provide evidence, and they provide it once instead of separately to every client that asks.

Nth-party and concentration visibility. Because suppliers connect to their own suppliers on the same network, clients can see which suppliers and services depend on the same underlying providers — the mechanism behind the tier-1 bank case covered later in this guide, where a bank identified fourth, fifth, sixth and seventh-party dependencies, along with concentration risks, within 48 hours of connecting.

Emerging-threat response. When a new vulnerability or attack emerges, security teams can see which suppliers on their network are affected, rather than manually cross-referencing supplier lists against public advisories — the kind of scramble that incidents like CrowdStrike and MOVEit, both covered earlier, created for firms without that visibility.

None of this replaces the fundamentals covered in the lifecycle section of this guide — tiering, assessment, remediation, reassessment and offboarding still have to happen. What changes is how much of that work has to be repeated from scratch for every supplier, on every client relationship, every time.

See how Risk Ledger maps fourth-party and concentration risk
‍

Evidence: TPRM in practice at financial institutions

Three examples ground the concepts covered in this guide in what actually happens when financial institutions map their supply chains in practice, rather than assess suppliers one at a time in isolation.

A tier-1 bank mapping its extended supply chain in 48 hours. During a City of London/Microsoft Cyber Innovation Challenge, a tier-1 bank connected with 14 direct suppliers on Risk Ledger within 24 hours. Within a further 24 hours, the platform’s automatic mapping capabilities had identified 36 fourth-party suppliers, 175 fifth-party suppliers, 15 sixth-party suppliers and 27 seventh-party suppliers — alongside 7 concentration risks the bank had not previously identified. The bank used the findings to brief the Bank of England. This is the practical scale of the fourth-party and nth-party exposure covered earlier in this guide, made visible within days rather than remaining theoretical.

A six-institution pilot uncovering systemic concentration risk. Working with FS-ISAC, six financial institutions connected their supply chain data within a dedicated, closed environment on Risk Ledger. The cohort's combined list of 395 direct third-party suppliers extended, once mapped, to 1,272 suppliers reaching as far as the seventh party. The analysis identified 47 systemic concentration risks — suppliers connected to three or more participants — including 9 suppliers connected to at least half the cohort. Three of those nine were smaller suppliers that no participating institution had known they shared. This is the direct, first-party demonstration of the concentration-risk and systemic-risk distinction covered earlier in this guide: none of these findings were visible from any single institution's own supplier list.

Lloyds Wealth (formerly Schroders Personal Wealth): faster onboarding, broader visibility. Schroders Personal Wealth achieved supplier visibility across roughly 95% of its supply chain, against an industry norm closer to 10%, alongside faster supplier onboarding — supporting ongoing compliance monitoring across GDPR, FCA and ESG requirements.
‍

What security teams ask next about TPRM in financial services

  • What Is Third-Party Risk Management? → /resources/what-is-third-party-risk-management
  • DORA and Third-Party Suppliers: A Guide → /resources/dora-third-party-suppliers-guide
  • Continuous Monitoring in Third-Party Risk Management → /resources/continuous-monitoring-cyber-security-tprm
  • How a Fourth-Party Breach Can Affect Your Organisation → /resources/how-fourth-party-breach-affect-organisation
  • Concentration Risks in UK Supply Chains → /resources/concentration-risks-uk-supply-chains
  • Schroders Personal Wealth Case Study → /case-studies/schroders-personal-wealth
    ‍

FAQ

What is third-party risk management in financial services?
Third-party risk management (TPRM) is the practice of identifying, assessing and monitoring the risk that external suppliers and service providers introduce to an organisation. In financial services, a small number of critical providers — cloud, payments and core software — sit underneath a large share of the sector at once, so TPRM also has to account for risk that's shared across institutions, not just risk within one firm's own supply chain.

What is DORA, and does it apply to UK financial institutions?
DORA (the EU's Digital Operational Resilience Act) is a regulation requiring EU financial entities to manage ICT and third-party risk, report major incidents on a strict timeline, and maintain a Register of Information on all ICT third-party arrangements. It became directly applicable on 17 January 2025. DORA does not directly bind UK-only firms, but it does apply to UK firms' EU-authorised subsidiaries and branches, and UK suppliers serving EU-regulated clients are drawn into DORA's third-party requirements through their clients' own obligations. UK-only firms instead operate under the FCA's and PRA's own operational resilience and Critical Third Parties regime.

What is the Register of Information under DORA?
The Register of Information is a structured record every in-scope financial entity must maintain of all its ICT third-party contractual arrangements, submitted to its national regulator at least annually under Article 28(3). It's the data source the European Supervisory Authorities used to designate the first Critical ICT Third-Party Providers, since aggregating registers across many firms reveals concentration that no single firm's own register could show.

What are Critical ICT Third-Party Providers (CTPPs), and who has been designated?
CTPPs are ICT providers the European Supervisory Authorities have formally designated as critical to the EU financial sector's stability, bringing them under direct regulatory oversight rather than leaving oversight solely to their financial-sector clients. The first list of 19 CTPPs was published on 18 November 2025, including Amazon Web Services, Microsoft, Google Cloud, IBM and Oracle among others, spanning cloud, data-centre, infrastructure and financial-data/software providers. The UK runs a parallel regime, naming its first four Critical Third Parties — AWS, Google Cloud, Microsoft and Oracle — for joint Bank of England, PRA and FCA oversight from July 2026.

What's the difference between concentration risk and systemic risk?
Concentration risk is when several of a firm's own critical functions depend on the same or a closely connected provider — something the firm can see by looking at its own arrangements. Systemic risk is when many firms across the sector depend on the same provider, which no single firm can see on its own, since it requires visibility across institutions rather than within one. Both are within DORA's Article 29 concentration-risk assessment requirements.

What is fourth-party or nth-party risk?
Fourth-party risk is exposure created not by an organisation's own supplier, but by that supplier's suppliers — a layer most contracts and TPRM programmes don't directly reach. The 2023 MOVEit breach is a clear real-world example: several financial institutions were affected not because they used the compromised software themselves, but because a shared vendor, PBI Research Services, did.

Why can't financial institutions just switch a critical supplier like SWIFT or a major cloud provider?
Some providers have no realistic substitute at short notice, either because switching would be operationally disruptive or because no genuine alternative exists at the required scale. DORA's Article 29 requires firms to formally assess this substitutability, rather than assume an alternative provider would be available if needed. Identifying this kind of lock-in doesn't automatically mean switching supplier — it should inform how the relationship is managed and monitored, not force an unrealistic substitution.

How often should supplier risk assessments be refreshed?
Point-in-time assessment on a fixed annual cycle is no longer sufficient on its own, given regulatory incident-reporting timelines that assume firms already understand their exposure before an incident happens (DORA's 4-hour classification window; the UK's 24-hour initial notification requirement). The underlying evidence a supplier provides during a formal review still matters — what's changed is the expectation that firms know whether that evidence is still accurate between reviews, not just at the point of last assessment.

Does concentration risk mean we should switch away from a designated Critical Third-Party Provider?
Not automatically. Regulatory designation as a CTPP or Critical Third Party reflects a provider's importance to the sector, not a finding that the provider is poorly managed. The appropriate response is usually to understand the dependency clearly, document contingency plans, and factor it into risk appetite decisions — not to assume switching is either necessary or realistic.
‍

Sources

DORA full text (EUR-Lex): https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng

EBA — ESAs designate Critical ICT Third-Party Providers: https://www.eba.europa.eu/publications-and-media/press-releases/european-supervisory-authorities-designate-critical-ict-third-party-providers-under-digital

FCA — UK regulators to oversee Critical Third Parties: https://www.fca.org.uk/news/statements/uk-financial-regulators-overseeing-critical-third-parties-announced-treasury

FCA — CrowdStrike outage lessons for operational resilience: https://www.fca.org.uk/firms/operational-resilience/crowdstrike-outage-lessons-operational-resilience

FCA — PS26/2, Operational Incident and Third Party Reporting: https://www.fca.org.uk/publications/policy-statements/ps26-2-operational-incident-third-party-reporting

Bank of England / PRA — SS1/21, Impact Tolerances for Important Business Services: https://www.bankofengland.co.uk/prudential-regulation/publication/2021/march/operational-resilience-impact-tolerances-for-important-business-services-ss

EIOPA — ESAs acknowledge European Commission's amendments to DORA subcontracting RTS: https://www.eiopa.europa.eu/esas-acknowledge-european-commissions-amendments-technical-standard-subcontracting-under-digital-2025-03-07_en

European Central Bank — Supervision Newsletter, February 2025: https://www.bankingsupervision.europa.eu/press/supervisory-newsletters/newsletter/2025/html/ssm.nl250219_2.en.html

Federal Register — US Interagency Guidance on Third-Party Relationships: Risk Management: https://www.federalregister.gov/documents/2023/06/09/2023-12340/interagency-guidance-on-third-party-relationships-risk-management

SEC — Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure: https://www.sec.gov/resources-small-businesses/small-business-compliance-guides/cybersecurity-risk-management-strategy-governance-incident-disclosure

UK Government (gov.uk) — Cyber Security and Resilience Bill collection: https://www.gov.uk/government/collections/cyber-security-and-resilience-bill

Financial Stability Board — Final Report on Enhancing Third-Party Risk Management and Oversight: https://www.fsb.org/2023/12/final-report-on-enhancing-third-party-risk-management-and-oversight-a-toolkit-for-financial-institutions-and-financial-authorities/

Bank for International Settlements — Clearing risks in OTC derivatives markets: the CCP-bank nexus: https://www.bis.org/publ/qtrpdf/r_qt1812h.htm

Bank for International Settlements — CBDC information security and operational risks to central banks: https://www.bis.org/publ/othp81.htm

ENISA — Threat Landscape: Finance Sector: https://www.enisa.europa.eu/publications/enisa-threat-landscape-finance-sector

Verizon — 2026 Data Breach Investigations Report:
https://www.verizon.com/business/resources/reports/dbir/

NIST — Continuous Monitoring definition (CSRC Glossary): https://csrc.nist.gov/glossary/term/continuous_monitoring

Reuters, via NBC News — Bangladesh Bank might sue NY Fed after $1B hack-heist: https://www.nbcnews.com/tech/tech-news/bangladesh-bank-might-sue-ny-fed-after-1b-hack-heist-n544046

SWIFT — Customer Security Programme: https://www.swift.com/myswift/customer-security-programme

Cybersecurity Dive — Big names disclose MOVEit-related breaches, including Genworth Financial: https://www.cybersecuritydive.com/news/moveit-breaches-pwc-ey-genworth/653821/

PLANSPONSOR — TD Ameritrade, Charles Schwab, TIAA Latest Victims of MOVEit Breach Lawsuits: https://www.plansponsor.com/td-ameritrade-charles-schwab-tiaa-latest-victims-of-moveit-breach-lawsuits/

Blog

Download for free

Pattern Trapezoid Mesh

Get the security manager's briefing

Monthly research, case studies and practical guides you won't find anywhere else.

Join thousands of security managers turning their TPRM programmes into success stories.