Third-Party Operational Risk Management

Third-party operational risk used to sit near the bottom of most GRC agendas. A questionnaire sent annually. A box ticked. A spreadsheet updated when someone remembered.

That era is over.

Under DORA, NIS2, and FCA operational resilience rules, the risk your suppliers carry is now legally your risk. Boards are personally liable. Enforcement is active. And the gap between what most organisations have in place and what regulators now expect is significant.

This guide explains what third-party operational risk management actually requires, why the regulatory floor has risen, and what a programme fit for 2026 needs to include.

Third-party operational risk management (TPRM) is the discipline of identifying, assessing, monitoring, and controlling the risks that arise from an organisation's reliance on external parties — including suppliers, vendors, outsourced service providers, and technology partners — to deliver critical operations.

It differs from general vendor management in scope and intent. TPRM is focused specifically on operational exposure: what happens to your business continuity, regulatory compliance, data integrity, and service delivery if a third party fails, is compromised, or exits the relationship unexpectedly.

A mature TPRM programme covers the full lifecycle of third-party relationships — from initial due diligence before onboarding, through continuous monitoring during the relationship, to managed exit when it ends.

DORA: ICT Third-Party Risk in Financial Services

The Digital Operational Resilience Act (DORA) came into force across EU financial services in January 2025. It places binding obligations on firms to manage ICT third-party risk — not as a best practice, but as a legal requirement.

Under DORA, financial entities must maintain a complete Register of Information (ROI) documenting all ICT third-party service providers. ROI submissions to National Competent Authorities were due in March 2026, and NCAs are now deploying automated tools to cross-reference submissions. Inconsistencies trigger enforcement automatically.

DORA also introduces concentration risk obligations: firms must understand and actively manage situations where multiple critical functions depend on a single third party or a small number of providers. Exit plans are mandatory, not optional.

Senior management is personally accountable. DORA is not a compliance exercise that can be delegated and forgotten.

NIS2: Supply Chain Risk Across Critical Infrastructure

The Network and Information Security Directive 2 (NIS2) extends cybersecurity obligations across a significantly wider range of sectors — including energy, transport, health, digital infrastructure, and manufacturing. Full compliance is required by October 2026. In Germany, registration deadlines close in April 2026.

Critically, NIS2 puts supply chain security explicitly in scope. Regulated entities must assess the cybersecurity practices of their suppliers and take appropriate risk management measures where weaknesses are identified. This is not a one-time exercise. NIS2 expects continuous oversight, not annual questionnaires.

Fines under NIS2 reach up to €10 million or 2% of global annual turnover. Management are personally liable for non-compliance.

FCA Operational Resilience: Third Parties and Critical Services

UK financial services firms face a parallel set of obligations under FCA operational resilience rules. Firms must identify important business services, set impact tolerances, and demonstrate they can remain within those tolerances even when a third party fails.

The FCA has already issued £15.7 million in fines in Q1 2026. Critical Third Party designations — applying enhanced oversight to the most systemically important service providers — are expected during 2026. Final rules on third-party outsourcing registers and incident reporting are also due this year.

Firms are now expected to evidence operational resilience, not just document it. Telling your regulator you have a plan is not sufficient if you cannot demonstrate the plan works under realistic stress scenarios.

Most TPRM programmes were built for a lower-stakes environment. The following components reflect what regulators now expect.

Risk-tiered supplier classification. Not all third parties carry equal exposure. A critical ICT provider processing customer data under DORA is materially different from an office supplies vendor. Tier your suppliers based on their criticality, replaceability, data access, and regulatory relevance — and apply proportionate oversight to each tier.

Due diligence before onboarding. Risk assessment must happen before a supplier is engaged, not after the contract is signed. This includes financial stability, security posture, regulatory standing, and sub-contractor exposure (fourth-party risk). For regulated services, the assessment should be documented and retained.

Contractual obligations aligned to regulatory requirements. DORA mandates specific contractual clauses with ICT third-party providers — covering audit rights, exit assistance, security standards, incident notification, and business continuity obligations. Firms that have not reviewed legacy contracts against DORA requirements have an urgent gap to close.

Ongoing monitoring, not point-in-time assessment. Annual questionnaires do not meet the standard regulators now expect. Effective TPRM requires continuous monitoring of supplier risk — tracking changes in security posture, financial health, regulatory status, and incident history between formal review cycles.

Concentration risk management. Regulators are specifically focused on scenarios where a single failure could cascade across multiple firms or critical services. Mapping your dependencies — including where the same provider underpins multiple business services — is now a core TPRM requirement.

Exit planning. Every critical third-party relationship should have a documented exit strategy before it is needed. This includes data portability, transition timelines, interim service arrangements, and identification of alternative providers. DORA makes this explicit. Regulators treat an untested exit plan with similar scepticism to an untested business continuity plan.

Audit-ready records. Documentation, evidence of assessments, board-level reporting, and response records must be retained and accessible. When a regulator asks for evidence of your TPRM programme, "we have a spreadsheet" is not a defensible answer. 

The gap between regulatory expectation and current practice is, for many organisations, substantial. The most common failures are structural, not superficial.

Spreadsheet-based tracking. Point-in-time data held in spreadsheets cannot support continuous monitoring, automated risk scoring, or audit-trail requirements. Manual processes introduce errors, create version control problems, and cannot scale as supply chains grow.

Inconsistent assessment depth. Without a standardised framework and tooling, the depth and quality of third-party assessments depends on who conducted them. Regulators expect consistency. Firms that cannot demonstrate it cannot demonstrate control.

No fourth-party visibility. Your critical suppliers have their own suppliers. A breach or failure at a fourth party can disrupt your operations even if your direct supplier remains intact. Most TPRM programmes have no systematic view of this exposure.

Reactive rather than continuous. Assessing a supplier at onboarding and then annually is not the same as monitoring them continuously. A supplier's risk profile can change materially between annual reviews — through a security incident, a change of ownership, a financial deterioration, or a regulatory sanction. Programmes built on periodic snapshots miss this.

Disconnected from the wider GRC estate. Third-party risk exists in isolation in many organisations — managed by procurement or a separate vendor team, disconnected from the risk register, compliance programmes, and operational resilience planning. Regulators view TPRM as integral to the GRC estate, not adjacent to it. 

Manual TPRM processes cannot meet the scale, consistency, and auditability that regulators now require. Purpose-built GRC technology closes the gap between what organisations need to evidence and what spreadsheet-based programmes can realistically deliver.

SureCloud's TPRM capability delivers 50% faster third-party risk assessments, 40% faster third-party onboarding, and 35% greater consistency across assessments — with a complete audit trail available at every stage. Third-party data is held in a single connected platform, updated in real time, and visible across risk, compliance, and operational resilience workstreams without manual re-entry.

GRACiE, SureCloud's AI, monitors the TPRM programme continuously — flagging changes, surfacing emerging risks, and generating audit-ready outputs without analyst overhead. For organisations facing DORA, NIS2, or FCA scrutiny, this is the difference between a programme that evidences control and one that documents intent.

SureCloud is recognised in the Gartner Market Guide for TPRM Solutions and has 19 years of GRC expertise embedded in the platform.

1. Third-party operational risk management is a binding regulatory obligation under DORA, NIS2, and FCA operational resilience rules — not a best practice.
2. Regulators expect continuous monitoring, documented due diligence, contractual alignment, concentration risk management, and tested exit plans.
3. Annual questionnaires and spreadsheet-based tracking do not meet the current standard.
4. Fourth-party risk (your suppliers' suppliers) is in scope and must be systematically addressed.
5. Management and boards are personally liable under DORA and NIS2 for failures in third-party risk oversight.
6. A connected GRC platform — not a siloed TPRM tool — is the most defensible architecture against regulatory scrutiny.