Third-Party Vendor Risk Management for Financial Institutions: DORA, UK and US Guide

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

Which suppliers would hurt us most if they failed? Are we affected when a shared provider goes down? Can we show the regulator we understand our dependencies before they ask? For a security or risk team at a bank, insurer, building society or payments firm, third-party risk management has to answer all three.

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.

‍

How do DORA, UK and US third-party rules compare?

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 register submitted to supervisors.

• EU: DORA, reporting timeline cell. Add the later-classification case: “Major incident: initial notification within 4 hours of classification and no later than 24 hours from awareness. Where an incident is classified as major after that 24-hour period, notification is due within 4 hours of classification. Intermediate report within 72 hours of the initial notification. Final report within one month.”
• UK, reporting timeline cell. “Payment services firms: 4 hours from detection” becomes “Payment services firms: a separate 4-hour requirement applies”. I couldn’t confirm that the clock runs from detection, so I’ve removed the trigger rather than guess it.

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.

How do the EBA guidelines and DORA apply to third-party risk in financial services?

The EBA guidelines and DORA split third-party risk between them. DORA sets binding requirements for ICT third-party risk across EU financial entities, including contractual terms and a Register of Information. The EBA’s final guidelines on non-ICT third-party risk (EBA/GL/2026/09), published on 18 September 2026, cover everything else and will replace the 2019 outsourcing guidelines once they apply.

The change is wider than a rename. The 2019 guidelines covered outsourcing. The new ones cover third-party arrangements for non-ICT services more broadly, with the heaviest requirements reserved for arrangements that support critical or important functions, using DORA’s definition. The EBA describes a holistic approach across ICT and non-ICT services, covering the full lifecycle from due diligence and contracting through subcontracting, monitoring and exit. In practice, a bank that has already built its DORA processes for ICT suppliers will be expected to apply a similar discipline to the rest of its supplier base. As of October 2026, the application date has not yet been confirmed, and the 2019 guidelines remain the reference until the new ones apply.

For a UK group, this matters only where it has EU-regulated entities. On the ICT side, DORA’s subcontracting standard is now final. Delegated Regulation (EU) 2025/532 has applied since 22 July 2025 to ICT services supporting critical or important functions.

UK: the PRA, the FCA and the Critical Third Parties regime

UK third-party oversight works in three separate layers, and they are easy to blur.

Firm-level outsourcing and third-party risk. PRA SS2/21 sets the PRA’s expectations for banks, building societies, PRA-designated investment firms and other PRA-regulated firms. The FCA’s SYSC 8 covers outsourcing for the firms it applies to. Watch the version you cite. The current SS2/21 has been effective since 31 December 2024, and an updated version published on 18 March 2026 takes effect on 18 March 2027.

Operational resilience. Firms identify their important business services, set impact tolerances and map the people, processes, technology and suppliers behind each one (PRA SS1/21).

Sector-level provider oversight. HM Treasury designates Critical Third Parties, which the Bank of England, PRA and FCA then oversee directly. The first four came under oversight in July 2026.

From 18 March 2027, the FCA and PRA’s joint reporting framework adds incident reporting and a register of material third-party arrangements. None of these layers moves responsibility away from the firm. A provider’s designation as a Critical Third Party changes what regulators can see and do, but a firm relying on that provider still owns the risk to its own services.

US: the Federal Reserve, FDIC and OCC interagency guidance

The June 2023 interagency guidance takes a risk-based approach across planning, due diligence and selection, contract negotiation, ongoing monitoring and termination. Banking organisations should apply more comprehensive oversight where a relationship supports higher-risk or critical activities. The board provides oversight, while management runs the programme. The guidance also points to a current inventory of third-party relationships as useful documentation, so the absence of a supervisory register is not the same as no inventory expectation.

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.

‍

What are the stages of the third-party risk management lifecycle?

The third-party risk management lifecycle has five stages: planning, due diligence, contracting, ongoing monitoring, and termination or exit. Financial institutions apply regulatory expectations at each stage, from deciding whether to use a supplier through to a tested exit plan. Assurance that stops at contract signature leaves ongoing monitoring unmanaged.

The five labels come from the US interagency guidance. DORA, the EBA guidelines and UK rules cover the same ground under their own headings, so the table maps each stage to the regimes that ask for it. Under the US guidance, the board oversees the programme and management runs it.

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

Planning

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. 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.

Due diligence

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, as 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.

Contracting

The contract decides what you will be able to monitor later. If a supplier has no obligation to tell you about an incident, a change to its service or a new subcontractor, you will find out late or not at all, and no monitoring tool fixes that afterwards. That makes contracting the stage where notification duties, subcontracting terms, audit and access rights and exit assistance are won or lost. DORA sets out the provisions contracts must include, with additional requirements where the service supports a critical or important function (Article 30). The weakness is timing. Most firms renegotiate only at renewal, so older contracts can lag years behind current expectations. The EBA’s new non-ICT guidelines reflect this by applying to arrangements entered into, reviewed or amended once the guidelines take effect, rather than to every existing contract at once.

Ongoing monitoring

Remediation: Findings need to translate into tracked actions with owners and deadlines, not sit in an assessment report. This is also where concentration risk 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, plus triggers for review between assessments.

Termination and exit

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.

For the full walkthrough of each stage outside the financial-services context, see our guide to the risk management lifecycle.

‍

Is annual due diligence enough, or do financial institutions need ongoing supplier monitoring?

Ongoing supplier monitoring is the part of third-party risk management that keeps assurance current between scheduled assessments, using defined triggers, sources and owners. For critical suppliers, annual due diligence is not enough on its own. A point-in-time assessment records a supplier’s position on one date, then goes stale. Monitoring shows what has changed since, in time to intervene earlier or respond faster.

Can we trust last year’s assessment? For a low-risk supplier with little access, often yes. For a supplier behind an important business service, the honest answer is that nobody knows until they check.

Continuous monitoring, per NIST’s official definition, means maintaining ongoing awareness of information security, vulnerabilities and threats to support risk management decisions. A point-in-time assessment, by contrast, 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 firms now work to. DORA requires a major incident to be notified within 4 hours of classification, 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.

Annual assessment still has value, because 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.

For monitoring cadence, tooling approaches and their limitations in more depth, see our guide to continuous monitoring in TPRM.

Is six-monthly reattestation continuous monitoring?

Not on its own. A six-monthly reattestation is periodic review. It shows where a supplier stood on two dates a year. Continuous monitoring adds defined events that trigger a review between those dates, each with an owner and an escalation route.

Periodic review is still legitimate. The US interagency guidance allows ongoing monitoring on a periodic or continuous basis, in proportion to risk. For many lower-tier suppliers, a scheduled reattestation is the right level of effort. The problem comes when it is the only mechanism for a supplier behind an important business service. Six months is a long time for a supplier you cannot do without.

Monitoring frequency, evidence freshness and response speed are three different settings. A supplier reassessed every six months can still hold a penetration test that is two years old, and a supplier with fresh evidence still needs someone to act within hours when it reports an incident. Treating them as one number is how gaps open between reviews.

When AI fills in the questionnaire on both sides, what evidence still counts? Suppliers increasingly use AI to draft questionnaire answers, and buyers use it to review them. That speeds both sides up without changing what the answer is. An AI-written answer is still an assertion by the supplier, and an AI-generated review is still a first pass. The evidence that counts is the same as before: what supports the answer, whether its scope covers the service you use, how current it is, and whether it agrees with what else you know about the supplier. AI review is genuinely useful for spotting gaps and inconsistencies across a long assessment, which is where human reviewers tire fastest. The decision about whether a remaining gap is acceptable should stay with a named person, recorded alongside the evidence they relied on.

‍

How do you identify which suppliers are critical or important to a financial institution?

A critical supplier is one whose failure would seriously disrupt an important business service or a critical or important function, or put the firm in breach of its regulatory obligations. Financial institutions identify them by mapping each supplier to the services it supports, then testing the impact of its failure against impact tolerances. Contract value alone is a poor proxy.

Regulators don’t share one label for this. DORA, the FCA, the PRA and the US agencies each use their own term and test. The working method underneath is the same in all of them: start from the service, not the supplier.

Which suppliers would hurt us most if compromised? Most supplier inventories answer that question badly, because they were built to track contracts. They rank by spend, by renewal date or by how much attention a supplier got at onboarding, and end up with most of the list marked high priority. A tiering test fixes the order of the questions, so the answer comes out the same whoever runs it.

Which suppliers would hurt us most? A tiering test

Keep three judgements separate, even if your register shows them side by side.

‍Criticality is what happens to your services if the supplier fails.

‍Inherent exposure is the risk the relationship creates before any controls, driven by data, access and dependency.

‍Residual risk is what remains once the supplier’s controls and your own mitigations are counted. Collapsing them into a single score hides the case that matters most.

A supplier with excellent controls can still be one of your most critical dependencies, because criticality is about what you lose when it fails, not how likely it is to fail. That supplier needs a tested exit plan and close monitoring even though its assessment comes back clean. A weak supplier behind a minor service, by contrast, may need remediation but little else. Keeping the three apart tells you which kind of effort each supplier needs.

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 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.

Can we defend these decisions?

A number on a scale doesn’t make a judgement defensible. What makes it defensible is being able to show how you reached it, months later, to someone who wasn’t in the room. For each top-tier supplier, record:

• the service and the legal entity assessed
• the criteria applied and the evidence behind each rating
• the reasoning for the rating, in a sentence or two
• what you didn’t know, and what you assumed instead
• control gaps found and the mitigations agreed
• who owns the relationship and who approved the decision
• when any exception expires, or what would trigger the next review

The record matters most when a supplier fails. An auditor or regulator will ask why the supplier sat in its tier, and “the score said so” is not an answer.

‍

How do you map supplier dependencies to important business services?

Mapping dependencies means tracing each important business service to the people, processes, technology and suppliers it relies on, including suppliers further down the chain. The result shows which supplier failures would breach impact tolerances and where single points of failure sit. Financial institutions use it to prioritise assessment, exit planning and resilience testing.

Which services depend on which suppliers, and what happens if one fails? Most teams can answer the first half for their direct suppliers. The second half usually sits a layer down, where several suppliers that look independent on a contract list turn out to share the same provider.

A map is only as useful as the confidence behind each link. A supplier using a cloud provider somewhere in its business does not prove that your service runs on the same region, product or failure domain. So for every dependency, record four things: the service it relates to, where the information came from, when it was confirmed and how confident you are in it. Sources differ in weight. A relationship the supplier has declared for your specific service is stronger than one inferred from external signals, and one notified under a contract clause is stronger than either. That provenance decides what you do next. A high-confidence shared dependency behind an important service justifies a resilience test or a conversation about the fallback. A low-confidence one justifies a targeted question to the supplier first, before anyone escalates.

There’s a direct regulatory endorsement of why the mapping discipline specifically pays off operationally, not just for compliance. The FCA’s review of the July 2024 CrowdStrike outage 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 same review found that some affected firms were themselves suppliers to other regulated firms’ important business services, which widened the disruption. A firm can be a link in someone else’s dependency map as well as the owner of its own.

What goes in a material third-party register, and where does the data come from?

A material third-party register is the regulatory record of which suppliers support your important services, and the data in it comes from your own operating process, not from the register template. The register is the reporting output. Contracts, service owners, supplier evidence and dependency mapping are what feed it.

UK: From 18 March 2027, firms in scope of the FCA and PRA’s joint framework must notify regulators of new or significantly changed material arrangements and keep an annual register. It covers material non-outsourcing arrangements as well as material outsourcing. The FCA expects to open a submission window after the implementation period, with 90 calendar days to submit, so 18 March 2027 is when the rules start, not the first filing deadline. Fields set out in FCA guidance FG26/4 include:

• the firm’s identity and FRN
• a contractual-arrangement reference
• the provider’s LEI, where one exists
• whether the arrangement is outsourcing or non-outsourcing
• the type of service
• whether it supports an important business service

EU: DORA’s Register of Information, specified in Implementing Regulation (EU) 2024/2956, links records for entities and providers, contractual arrangements, ICT services and the functions they support, relevant ICT supply chains, and assessments of services supporting critical or important functions.

‍

What are fourth-party and concentration risk, and how can financial institutions see them?

Fourth-party risk is the exposure created by your suppliers’ own suppliers. Concentration risk arises when several of your suppliers, or services, depend on the same cloud, managed service or software provider. Financial institutions see both by mapping dependencies beyond direct suppliers, combining supplier disclosures, contract terms and network data.

Fourth-party risk is a layer most TPRM programmes never formally assess, because the contractual relationship simply doesn’t extend that far.

Breached through a supplier’s supplier: MOVEit

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.

Genworth’s own account makes the lesson sharper. PBI’s job was a routine compliance task: checking Social Security data to identify policyholders who had died, so benefits could be paid. Genworth says it did not run MOVEit on any company system, and its own systems and operations were unaffected. You can be exposed through software your organisation does not use, because a supplier uses it to handle your data. A supplier like PBI rarely looks top tier on technology grounds. The question that catches it is the one about what data it holds.

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 ESAs acknowledged the amendments in March 2025, and the final, narrower standard was published as Delegated Regulation (EU) 2025/532, in force since 22 July 2025. It asks firms to assess subcontracting arrangements supporting critical or important 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.

Concentration risk vs systemic risk

Where does concentration risk exist? 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. It also covers cases where several of a firm’s direct suppliers all depend on the same fourth party, or on a shared provider further down the chain. Systemic risk is when many firms across the sector depend on the same provider. No single firm can see that, 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. No individual firm’s own risk assessment could have produced that decision, 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.

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. A major disruption at that provider then 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. It notes 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 mapping revealed in practice

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 nth-party exposure, 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 potential 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 difference between concentration risk and systemic risk: none of these findings were visible from any single institution’s own supplier list.

‍

What happens if a critical supplier fails? Exit planning and incident response

An exit plan is the documented, tested route for moving a critical service away from a supplier, or keeping it running without them, whether you choose to leave or the supplier fails without warning. DORA requires exit strategies and tested exit plans for ICT services supporting critical or important functions (Article 28(8)), and PRA SS2/21 sets expectations for business continuity and exit planning.

What happens if this supplier fails? The question has two different answers depending on how the relationship ends. A planned exit, at renewal or after a strategic decision, gives you months to move the service, migrate data and run both providers in parallel. A stressed exit, where the supplier collapses, is breached or withdraws the service, gives you none of that. Most exit plans are written for the first case and quietly relied on for the second.

That gap matters because an exit plan is not a recovery plan. Moving a core service to a new provider takes months even when everything goes well. If the supplier fails on a Tuesday morning, what keeps the service running that afternoon is a continuity measure: a reduced service, a manual workaround, a standby arrangement. The exit plan describes how you get to a permanent replacement afterwards. A tested programme needs both, and needs to know which one it is reaching for at each point in an incident.

Are we affected? The first hours of a supplier incident

When a supplier, or a provider your suppliers share, reports an incident, the first question is whether it touches you, and how badly. Teams without a current dependency map answer it by ringing suppliers one by one, with no clear order of who to call first. The sequence below puts the work in an order that holds up under time pressure.

1. Establish the facts: Which provider, product, service and region are affected, and over what dates.
2. Trace your exposure: Check direct relationships first, then the deeper pathways your dependency map records.
3. Prioritise by business impact: Rank affected suppliers by the important services, customers and data behind them, not alphabetically.
4. Validate with suppliers: Send targeted questions to the suppliers that matter, and ask for evidence and a time for their next update.
5. Activate continuity measures: Don’t wait for perfect attribution before protecting a service that is at risk.
6. Assess your notification duties: Regulatory, privacy, contractual and customer obligations each run on their own clock.
7. Record decisions as you go: Note what you knew, what you didn’t, what you did, who owned it and when.

Two notification duties run in parallel during a supplier incident, and they are easy to confuse. The first is the supplier’s duty to tell you, which exists only if your contract creates it. The second is your duty to tell your regulator, which exists whether or not the supplier has told you anything. The second depends on the first. You cannot classify an incident or meet a reporting clock on information you haven’t received. The FCA’s review of the CrowdStrike outage found that firms with contracts clearly setting out third-party responsibilities received information from affected providers more effectively. It also found that the timing and completeness of firms’ own notifications varied widely. Writing incident notification, timing and update obligations into supplier contracts is therefore part of meeting your own reporting duty, not a separate procurement detail.

A dependency map narrows an investigation. It does not prove that a supplier was compromised or replace a technical impact assessment. What it changes is where the first hour goes: on the right handful of suppliers, rather than on a phone list.

For a step-by-step response plan, see our third-party incident response playbook.

‍

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.

Are questionnaires actually reducing risk? Why one-to-one assessments don’t scale

A supplier serving several financial-services clients is typically assessed by each one separately. It answers 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)). 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. It also draws heavily on the same limited compliance and security resource on both sides of the relationship.

A process that works for 20 suppliers rarely survives contact with 200. At 20, one analyst can chase every questionnaire, read every answer and remember which supplier said what. At 200, the same process turns into a queue: assessments go out late, reminders replace review, and the suppliers that matter most get the same attention as the ones that matter least. Nothing about the questionnaire itself has changed. What breaks is the assumption that each supplier relationship can be handled from scratch, by hand, every time. That is why tiering and evidence reuse are scaling decisions as much as risk decisions. They decide where a lean team’s hours go once the supplier list outgrows the people available to work through it.

Some suppliers won’t respond at all. Smaller firms may lack the people to complete a long assessment, and others refuse bespoke questionnaires outright. Suppliers reached through a managed service provider may not be contactable directly. A model that charges suppliers to take part adds one more reason to say no. When evidence doesn’t arrive, the decision still has to be made:

• look for evidence that already exists, such as certifications with a relevant scope, published assurance reports or external signals
• go through the business owner of the relationship, who often has more leverage than the TPRM team
• record the gap as a time-limited exception with a named owner, rather than leaving the assessment open
• revisit the supplier’s tier, because a critical supplier that won’t share evidence is itself a finding

Why can’t we just switch suppliers? Lock-in and substitutability

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. That puts 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.

Concentration risk shouldn’t automatically trigger a search for an alternative provider. The more realistic response is understanding the exposure clearly enough to manage it deliberately, with a tested exit and continuity plan for the dependencies you can’t replace.

‍

What a mature TPRM programme looks like in financial services

A mature TPRM programme keeps supplier evidence current rather than reviewing it once a year. It prioritises the suppliers that genuinely matter to critical services rather than treating every relationship the same. And it 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 in the current regulatory and threat environment. 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.

Three questions show where a programme stands. Each one can be answered in an afternoon, and none needs a new tool:

1. Can you name your top-tier suppliers and the important business services behind each one? If the list comes from contract value, the tiering hasn’t been done yet.
2. For each of those suppliers, can you say when its key evidence expires? If not, you know what was true at the last assessment, not what is true now.
3. If a widely used provider reported a breach this morning, could you say by lunchtime which of your services were exposed? If the honest answer involves ringing suppliers one by one, the gap is in dependency mapping, not in assessment.

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. Regulatory frameworks 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 is far cheaper than discovering lock-in after the fact. It’s the same question DORA’s Article 29 asks firms to answer for existing arrangements.

Invest in automation to sustain monitoring at scale: Given today’s reporting timelines (DORA’s 4 hours from classification, 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.

‍

What should financial services firms look for in third-party risk management tooling?

The right TPRM tool for a financial institution is one that cuts manual questionnaire work while keeping every decision explainable to a regulator. Useful criteria are:

• evidence that stays current between reviews
• visibility beyond direct suppliers
• consistent, explainable scoring
• supplier participation that doesn’t depend on charging suppliers
• human oversight of any AI

Most evaluations start because something has broken. An incumbent tool is up for renewal, a spreadsheet process has outgrown the team, or a new regulatory deadline needs evidence the current setup can’t produce. That trigger is worth naming at the start, because it tells you which constraint the tool actually has to remove. A team drowning in questionnaire admin needs something different from a team that can’t see past its direct suppliers.

Tool types solve different problems:

Many mature programmes combine more than one.

For a side-by-side view of the main options, see our comparison of TPRM solutions for financial services.

AI deserves its own test, because the claims run ahead of the evidence.‍

For any AI feature in a TPRM tool, ask three questions:

• What exactly does it do?
• What evidence does each output point back to?
• Who makes the decision once the AI has finished?

Good answers are specific. “It reviews a supplier’s assessment against a security domain, flags gaps with the answers that caused them, and suggests next steps for an analyst to accept or reject” is a feature you can evaluate. “It scores your suppliers’ risk automatically” is not, unless the vendor can show what went into the score and what a reviewer can change. An AI that produces a number with no traceable evidence doesn’t remove the black box from third-party risk. It moves the box somewhere harder to audit. For regulated firms the test is practical, not philosophical. If you can’t explain a decision to your regulator, it doesn’t matter how the decision was produced.

‍

How Risk Ledger supports third-party risk management at financial institutions

Regulatory pressure, concentration risk, fourth-party exposure, supplier fatigue and the shift toward continuous evidence all point toward the same operational gap. Teams need to keep supplier evidence current, understand dependencies beyond the direct relationship, and respond quickly when something changes. Risk Ledger is built around those three jobs.

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 our 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. 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. How far you can see depends on which of your suppliers, and theirs, are connected, so it’s worth checking how much of your supplier base is already on the network.

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. That is the kind of scramble that incidents like CrowdStrike and MOVEit created for firms without that visibility. We publish Emerging Threats as they break.

AI-assisted review, with people making the decision

‍Domain Review Agent helps teams spot gaps in supplier assessments, understand why they matter and choose next steps. Your team makes the final decision, which keeps every review explainable to an auditor or regulator.

Lloyds Wealth (formerly Schroders Personal Wealth)

‍With around 200 suppliers, some critical to its infrastructure, the team moved from manual questionnaires and annual reviews to supplier profiles built on a standard framework. It gained visibility into 95% of its suppliers, and work that once needed several FTEs now needs one. It also wrote a clause into its supplier contracts requiring suppliers to maintain the controls they declare on Risk Ledger. That clause turns the profile into a working security schedule rather than a once-a-year snapshot. The programme supports ongoing compliance monitoring across GDPR, FCA and ESG requirements.

See how Risk Ledger maps fourth-party and concentration risk

‍

What security teams ask next about TPRM in financial services

• DORA and Third-Party Suppliers: A Guide
• Continuous Monitoring in Third-Party Risk Management
• How a Fourth-Party Breach Can Affect Your Organisation
  ‍

_Sources

^{DORA full text (EUR-Lex)
EBA: ESAs designate Critical ICT Third-Party Providers
FCA: UK regulators to oversee Critical Third Parties
FCA: CrowdStrike outage lessons for operational resilience
FCA: PS26/2, Operational Incident and Third Party Reporting
Bank of England / PRA: SS1/21, Impact Tolerances for Important Business Services
EIOPA: ESAs acknowledge European Commission’s amendments to DORA subcontracting RTS
European Central Bank: Supervision Newsletter, February 2025
Federal Register: US Interagency Guidance on Third-Party Relationships: Risk Management
SEC: Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure
UK Government (gov.uk): Cyber Security and Resilience Bill collection
Financial Stability Board: Final Report on Enhancing Third-Party Risk Management and Oversight
Bank for International Settlements: Clearing risks in OTC derivatives markets: the CCP-bank nexus
Bank for International Settlements: CBDC information security and operational risks to central banks
ENISA: Threat Landscape: Finance Sector
Verizon: 2026 Data Breach Investigations Report
NIST: Continuous Monitoring definition (CSRC Glossary)
Reuters, via NBC News: Bangladesh Bank might sue NY Fed after $1B hack-heist
SWIFT: Customer Security Programme
Cybersecurity Dive: Big names disclose MOVEit-related breaches, including Genworth Financial
PLANSPONSOR: TD Ameritrade, Charles Schwab, TIAA Latest Victims of MOVEit Breach Lawsuits}