Operational Resilience Is Only as Strong as Your Third-Party Risk Management

Key Takeaways

• DORA has applied to EU financial entities since January 17, 2025, and treats ICT third-party risk as core to operational resilience, not a procurement checkpoint. (Regulation (EU) 2022/2554)
• The FCA’s operational resilience transition period closed March 31, 2025, but PS21/3 and the Bank of England’s SS1/21 require the underlying discipline to continue with no fixed end date. (FCA; Bank of England)
• NIS2 extends the same expectation to supply chain security and incident handling for organizations in or adjacent to critical sectors. (Directive (EU) 2022/2555)
• Third-party involvement in confirmed data breaches doubled from 15% to 30% in a single year. (Verizon, 2025 Data Breach Investigations Report)
• Only 18% of third-party risk programs are fully integrated with enterprise risk management, and just 53% call themselves mostly integrated. (KPMG, 2026 Global Third-Party Risk Management Survey)

Regulators across Europe and the UK are increasingly focused on exactly that gap in third-party risk oversight. They call it operational resilience.

A payroll processor stalls mid-cycle. A cloud host has a bad week. A logistics partner misses a delivery window during a live product recall. None of these events happen inside the company that ultimately answers for them, and none of them wait for the next scheduled vendor review. Third-party involvement in confirmed security breaches doubled in a single year, from 15% to 30%, according to Verizon’s 2025 Data Breach Investigations Report. Each of those incidents interrupted a service the affected company was accountable for keeping running.

Organizations have spent years strengthening their own continuity plans, cyber controls, and incident response, and many have made real progress. But the operating model has moved outward faster than most resilience programs have, and critical services now depend on third parties, fourth parties, and a handful of concentrated technology providers outside direct management control. Boards and regulators are already treating this as the resilience question that matters. Compliance functions are the ones still catching up.

This piece looks at what DORA, the UK’s operational resilience regime, and NIS2 now expect organizations to prove about their third-party dependencies, where the evidence gap actually sits, and what a mature program needs to demonstrate.

Where Third-Party Risk Meets Operational Resilience

Operational resilience depends on third-party risk because the systems, platforms, and processes a company relies on to keep running are frequently owned and operated by vendors. A recovery plan that does not account for those vendors is testing a scenario that will not match the one the company actually faces.

The question has moved from whether an organization can recover from disruption on its own terms to whether it understands the external dependencies that decide if recovery is possible at all.

Third-party risk management and business continuity have long been treated as adjacent disciplines rather than one connected job. Third-party risk teams assess suppliers. Business continuity teams build plans. Resilience teams map important services. Procurement manages contracts. Information security reviews cyber controls.

Each function carries out serious professional work, but disruption does not respect the organizational chart that separates them. When a critical provider fails, the organization needs a single view of dependency, impact, continuity options, contractual obligations, communication paths, and recovery evidence. Where those records live in separate systems, the response depends on manual coordination exactly when time, trust, and clarity are under the most pressure.

Operational resilience has traditionally meant an internal capability: whether the organization can continue operating during disruption, recover systems, facilities, people, and processes, and communicate effectively with customers, employees, regulators, and counterparties. Those questions remain necessary, but they are no longer enough on their own, because the resilience of a service increasingly depends on entities the organization does not own.

Cloud providers host critical systems. Third-party administrators process customer activity. Specialist vendors maintain workflow platforms. Outsourced partners handle sensitive operational processes. Data processors hold information required for recovery. In some sectors, a handful of providers support most of the market at once, which turns individual vendor risk into concentration risk for the sector as a whole.

Regulatory compliance and cyber risk are now the top two drivers of third-party risk strategy worldwide, cited by 48% and 37% of organizations respectively, according to KPMG’s 2026 Global Third-Party Risk Management Survey. That ranking did not exist a decade ago, when third-party oversight sat mostly inside procurement and internal audit.

Regulators are now paying attention to exactly that convergence. An organization can map an important business service internally and still miss the external dependency that would prevent that service from being delivered during disruption. It can test a recovery plan while assuming, without evidence, that a third party will be available, responsive, contractually aligned, and operationally capable when needed. Few resilience programs give that assumption the scrutiny it deserves.

The practical question for leadership is direct: which third parties are essential to the services the organization must continue delivering, and what evidence exists that they can withstand disruption? When the answer lives in a spreadsheet, three teams working independently, and one person who understands how the pieces fit together, the program is more fragile than the org chart suggests.

What Does DORA Require for Third-Party ICT Risk?

DORA, the EU’s Digital Operational Resilience Act, has applied to financial entities since January 17, 2025, and treats ICT third-party risk as part of operational resilience itself. Financial entities must manage vendor risk continuously, not only at onboarding, because DORA assumes resilience is impossible if critical ICT dependencies are poorly understood.

The EU Digital Operational Resilience Act, Regulation (EU) 2022/2554, made this relationship explicit for financial entities. DORA has applied since January 17, 2025, and sets uniform requirements for ICT risk management, incident reporting, digital operational resilience testing, and ICT third-party risk management across the EU financial sector.

The date matters less than the model behind it: DORA treats third-party ICT risk as integral to operational resilience rather than as a procurement administration task, on the basis that financial entities cannot be resilient if their critical ICT dependencies are poorly understood, weakly governed, or assessed only at onboarding.

This expectation is spreading well beyond DORA’s strict legal scope. Organizations outside EU financial services are encountering the same expectations in customer questionnaires, board reporting, cyber insurance reviews, audit requirements, and sector-specific guidance. Critical third parties are no longer peripheral to resilience; they sit inside the resilience perimeter now. The relevant knowledge, unfortunately, sits scattered across functions.

Third-party risk teams know which vendors carry the highest risk, business continuity teams know which processes are time-sensitive, and technology teams know which systems support essential operations. Few organizations connect all three into a single view. A vendor list, a service map, and a continuity plan each stand on their own. Connecting them is the part most programs still haven’t done.

The UK Deadline Has Passed but the Obligation Has Not

The FCA’s operational resilience transition period under PS21/3 ended on March 31, 2025, after firms spent three years mapping important business services, setting impact tolerances, and testing recovery. The deadline closed a transition window. It did not close the underlying obligation, which continues as vendors, technology, and customer expectations keep changing.

In the UK, the FCA’s operational resilience regime, set out in Policy Statement PS21/3 and reflected in the Bank of England’s Supervisory Statement SS1/21, required firms to identify important business services, set impact tolerances, map dependencies, and test their ability to remain within those tolerances.

The transition period ended on March 31, 2025. That milestone is history now. The obligation behind it is not. Business services change, vendors change, technology architectures change, customer expectations change, and outsourcing models change; new incidents keep exposing dependencies that looked immaterial during a desktop exercise.

Most programs weaken right after the initial compliance push. A firm may complete service mapping, define tolerances, and conduct scenario testing, then treat the output as a finished project, when the more mature approach treats operational resilience as a continuously governed management discipline that requires current evidence, not a project with an end date.

If an important business service depends on a third-party technology provider, the organization needs to know whether that dependency has been assessed, whether recovery assumptions have been tested, whether contractual terms support operational requirements, whether alternative arrangements exist, and whether incident communication paths remain understood and current. Those answers rarely live in one place unless a program is built to keep them there.

How Does NIS2 Extend Third-Party Risk to the Supply Chain?

NIS2, the EU’s revised cybersecurity directive, sets risk management and incident reporting obligations with specific attention to supply chain security. For organizations in or adjacent to critical sectors, NIS2 means a supplier’s cyber weakness can become the organization’s operational disruption, and a vendor’s incident can trigger the organization’s own reporting obligation.

The EU NIS2 Directive, Directive (EU) 2022/2555, reinforces the same link between cyber risk, operational resilience, and supply chain security. NIS2 sets out cybersecurity risk management and reporting obligations for entities within its scope, with particular attention to supply chain security and incident handling.

For organizations in or adjacent to critical sectors, that gives one more reason to examine third-party dependencies through a resilience lens. A supplier’s cyber weakness becomes the organization’s operational disruption. A technology provider’s incident triggers the organization’s reporting obligation. A managed service provider’s failure interrupts customer-facing services. A gap in supplier governance becomes a board-level issue the moment the organization cannot explain how the risk was assessed and monitored.

DORA, the UK regime, and NIS2 are not three separate compliance exercises. They state the same expectation three times: third parties belong inside the control environment now, not beside it.

What Evidence Do Regulators Expect for Operational Resilience?

Regulators increasingly expect organizations to produce, on demand, a defensible view connecting an important service to the third parties behind it, the risk assessment of each one, the recovery assumptions made, and when those assumptions were last tested. Most programs cannot produce that view without days of manual reconstruction, which is itself the gap regulators are now testing for.

Most organizations hold more resilience activity than they can evidence coherently, and that is a different, less visible problem than holding no controls at all. A third-party risk team may have completed its assessments. A business continuity team may have maintained recovery plans. A cyber team may have reviewed security questionnaires. A legal team may have negotiated contractual protections. Procurement may have mapped supplier categories. Internal audit may have tested elements of the program.

Each function can show its own work. The open question is whether the organization can assemble that work into one defensible view of operational dependency.

Breaches that span multiple environments, the kind third-party dependencies routinely create, take an average of 276 days to identify and contain, 59 days longer than incidents contained within a single environment, according to IBM’s 2025 Cost of a Data Breach Report. Regulators are, in effect, asking organizations to close a gap the data shows is already wide.

When disruption occurs, the organization needs to answer a set of practical questions quickly: which services are affected, which third parties support those services, which internal owners are responsible, what recovery assumptions were made, when those assumptions were last tested, what contractual obligations apply, which alternative providers or manual workarounds exist, who needs to be notified, and what evidence the board, regulator, auditor, or customer will expect to see.

If those answers require manual reconstruction, the evidence gap is real, whatever the program looks like on paper. The bigger risk is quieter: leadership believes the program is more mature than the evidence supports, and finds out otherwise during an incident, not before one.

Mitratech’s 2025 Annual TPRM Study found compliance team involvement in third-party risk programs grew from 42% in 2023 to 88% in 2025. More people are now accountable for this work. The coordination problem underneath it remains unsolved.

How Do You Measure Concentration Risk in Your Supplier Base?

Concentration risk means multiple organizations, sectors, or even entire markets rely on the same small set of cloud providers, payment processors, or specialist vendors. Measuring it requires looking across services, entities, and functions together, since a single contract can look acceptable in isolation while the aggregate exposure across the business stays invisible.

Third-party risk is not confined to individual supplier failure; it is also about concentration. Many organizations rely on the same cloud providers, software vendors, payment processors, outsourced administrators, data centres, and specialist service providers as their peers, so a disruption at one provider can affect multiple firms, sectors, or jurisdictions at once. An organization’s own readiness, in that world, depends partly on how well it understands the dependencies it shares with everyone else in its market.

Concentration risk is difficult to see because it can appear acceptable at the level of an individual contract. Each business unit may have a rational reason for using a particular provider, each provider may pass due diligence, and each contract may be manageable on its own terms. The aggregate exposure only shows up when someone looks across services, entities, and functions together, and few programs are built to do that by default.

A business continuity plan that does not reflect supplier concentration may overstate recoverability. A third-party risk register that is not connected to important business services may understate operational impact. A board report that keeps vendor risk and resilience in separate slides hides the relationship between them. The board does not need every operational detail, but it needs to know whether one dependency could take down an important service, whether that has been tested, and what management is doing about it.

What Should Resilience Testing Expose?

Resilience testing delivers the most value when it exposes assumptions the organization has not questioned, rather than confirming a plan already believed to work. A test that only checks whether roles are assigned and recovery times are documented validates paperwork. A test that asks what happens if a critical vendor is unavailable during the internal incident validates the plan itself.

Resilience testing earns its budget when it exposes uncomfortable assumptions rather than confirming existing confidence. Scenario exercises too often reinforce what the organization already believes: the plan exists, roles are assigned, communications are drafted, recovery time objectives are recorded, and participants leave with a sense that the program has been validated. A tougher test looks for where the plan quietly depends on someone else.

• What happens if the critical provider is unavailable at the same time as the internal incident team?
• What happens if the supplier’s recovery time exceeds the organization’s impact tolerance?
• What happens if the contract does not require the reporting cadence the business assumes?
• What happens if the vendor’s own subcontractor is the actual point of failure?
• What happens if customer communication depends on data held by the disrupted provider?
• What happens if the alternative provider has never been operationally tested?

A tougher test surfaces what is actually true, before an incident surfaces it instead. The strongest programs use testing to revise the operating model itself: updating dependency maps, revising supplier classifications, strengthening contract terms, changing recovery assumptions, assigning remediation owners, retesting, and reporting to the board what has changed. That cycle turns resilience from a document into governance.

What a Mature Operational Resilience Program Needs to Demonstrate

A mature operational resilience program does not stop at holding a vendor list and a continuity plan. It can show, on request, which third parties are essential to each critical service, how those third parties were assessed, when recovery assumptions were last tested, and how all of that connects into one piece of evidence.

The more useful test of maturity is whether five specific questions get a fast, confident answer.

• Which third parties are essential to each important business service, and when was that mapping last validated?
  • Start with the services the organization cannot afford to lose, then trace which vendors sit behind each one. A mapping older than a year, or one never checked against a current vendor list, is not evidence. It is a guess with a date on it.
• What recovery assumptions depend on a third party, and has that assumption actually been tested, with evidence?
  • Most recovery plans assume a vendor will be available, responsive, and capable when needed. That assumption becomes evidence only once it has been tested against a real scenario and the result recorded, not simply written into the plan.

• Where does concentration risk exist across the supplier base, and how does it change what recovery actually looks like?
  • Look across business units, not within a single contract, for the small number of providers that multiple services quietly depend on. If one of them fails, recovery time expands well beyond what any single team’s plan accounts for.

• What contractual obligations apply if a critical provider fails, and are those terms still current?
  • The relevant terms are the notice periods, service credits, and reporting cadence a contract actually requires, not what the business assumes it requires. Contracts negotiated years ago rarely match today’s recovery expectations without a direct check.

• What evidence can the organization produce, without days of manual reconstruction, for a regulator, auditor, or board asking after the fact?
  • The honest test is time. If assembling the vendor, the assessment, the recovery assumption, and the contract terms for one service takes longer than a single afternoon, the evidence does not yet exist in a form anyone can defend.

KPMG’s 2026 Global Third-Party Risk Management Survey found only 18% of third-party risk programs are fully integrated with enterprise risk management, and just 53% call themselves even mostly integrated. Those five questions are, in effect, what that missing integration is supposed to produce.

A practical starting point is one critical service, not the whole portfolio. Map its external dependencies, test the assumptions behind its recovery plan, and use what that reveals to strengthen the next service. Programs that improve fastest build this way, one service at a time, which stops the common mistake of running third-party risk and business continuity as two separate assurance exercises that never compare notes, rather than waiting for a portfolio-wide initiative that never quite starts.

Technology alone does not make an organization resilient, but it can make resilience governable, when it connects the work already underway rather than duplicating it. A connected view of third-party risk and business continuity, one that keeps supplier records current, monitors emerging risk, and preserves recovery evidence in one place, is increasingly what boards expect and what regulators, auditors, and insurers ask to see once disruption moves from a hypothetical scenario to a real one.

Operational resilience is turning into a test of dependency governance, and that test rarely waits for a convenient audit cycle. The organizations making real progress can explain, under pressure, how their important services depend on third parties, how those third parties were assessed, and how continuity assumptions were tested and by whom. Organizations that leave that evidence for later tend to build it during the incident that proves they needed it sooner.

How Mitratech Can Help

Mitratech Prevalent gives risk and compliance teams continuous visibility into third-party risk, from onboarding assessment through ongoing monitoring. Mitratech Preparis keeps business continuity plans, emergency alerts, and incident response current and testable. Used together, they connect the vendor side of resilience to the continuity side, so the evidence a board or regulator asks for already exists in one place. Explore Mitratech Prevalent and Mitratech Preparis.