What Is Third-Party Risk Management (TPRM)?
Comprehensive reference guide to third-party risk management (TPRM), covering its scope, regulatory drivers under DORA and NIS2, the distinction between TPRM and VRM, and why EU regulated entities must operationalise supply chain risk oversight.
- 1
TPRM is a continuous programme spanning the full third-party lifecycle, not a point-in-time assessment performed at contract signing.
- 2
DORA Articles 28-30 impose the most prescriptive third-party risk requirements in any jurisdiction, including a mandatory ICT third-party register that must be kept current and submitted on request.
- 3
NIS2 Article 21(2)(d) extends supply chain security obligations beyond ICT vendors to any supplier whose compromise could affect network and information system security.
- 4
TPRM is broader than VRM — it encompasses non-commercial third parties, open-source dependencies, and fourth-party risks that EU regulations explicitly require organisations to address.
- 5
Effective TPRM programmes require five core components: governance with management body oversight, comprehensive inventory, risk-based assessment, continuous monitoring, and structured reporting.
1. Definition and Scope of TPRM
Third-party risk management (TPRM) is the discipline of identifying, assessing, monitoring, and mitigating risks that arise from an organisation's reliance on external entities. These external entities include vendors, suppliers, service providers, contractors, partners, and any other organisation that has access to your systems, data, facilities, or personnel. TPRM encompasses the entire lifecycle of a third-party relationship, from initial due diligence and onboarding through ongoing monitoring and eventual offboarding.
The scope of TPRM extends far beyond procurement and contract management. It addresses operational risk (what happens when a critical supplier fails to deliver), cybersecurity risk (what happens when a vendor's systems are compromised and your data or access pathways are exposed), compliance risk (what happens when a supplier's practices violate regulations that apply to your organisation), financial risk (what happens when a key vendor becomes insolvent), reputational risk (what happens when a supplier is involved in unethical practices), and concentration risk (what happens when too many critical functions depend on a single provider or a small cluster of related providers).
In the EU regulatory context, TPRM has evolved from a best practice into a legal obligation. The Digital Operational Resilience Act (DORA), the Network and Information Security Directive (NIS2), and the General Data Protection Regulation (GDPR) each impose specific obligations related to third-party oversight. Organisations that treat TPRM as a compliance checkbox rather than an operational discipline will find themselves unable to meet the substance of these requirements. Effective TPRM requires governance structures, processes, technology, and human expertise working in concert to provide visibility into and control over the risks that third parties introduce into your environment.
TPRM is not a single assessment performed at contract signing. It is a continuous programme that spans the entire relationship lifecycle and addresses multiple risk domains simultaneously.
2. Why TPRM Matters for EU Regulated Entities
The EU regulatory landscape has made third-party risk management a non-negotiable operational requirement for regulated entities. Three converging forces drive this: the increasing digitisation of financial services and critical infrastructure (which deepens dependencies on ICT third parties), the growing sophistication of supply chain attacks (SolarWinds, Kaseya, and MOVEit demonstrated that attacking suppliers is often easier than attacking well-defended targets directly), and the explicit recognition by EU legislators that resilience cannot stop at the organisation's own perimeter.
For financial entities, DORA represents the most prescriptive third-party risk framework in the world. Articles 28 through 30 establish detailed requirements for managing ICT third-party risk, including mandatory contractual provisions, criticality assessments, concentration risk analysis, and the maintenance of a register of all ICT third-party arrangements. The European Supervisory Authorities (ESAs) have published Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) that specify the exact format and content of this register, leaving no ambiguity about what is expected. Financial entities that have not operationalised these requirements face supervisory action from their national competent authority.
Beyond financial services, NIS2 casts a wider net. Article 21(2)(d) requires essential and important entities across all in-scope sectors to implement supply chain security measures, including security-related aspects of the relationships between the entity and its direct suppliers or service providers. The Directive requires entities to take into account the vulnerabilities specific to each direct supplier and service provider, the overall quality of products and cybersecurity practices of their suppliers, and the results of coordinated security risk assessments of critical supply chains. This is not a narrow ICT focus — it applies to any supply chain relationship that could affect the security of network and information systems.
3. DORA Article 28-30: ICT Third-Party Risk Requirements
DORA's Chapter V establishes the most comprehensive regulatory framework for ICT third-party risk in any jurisdiction. Article 28 sets out general principles for managing ICT third-party risk, requiring financial entities to manage third-party risk as an integral part of their overall ICT risk management framework. Critically, Article 28(2) mandates that financial entities maintain and update a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers. This register must be submitted to competent authorities upon request and is the cornerstone of DORA's supervisory approach to third-party risk.
Article 29 addresses preliminary assessment and contractual arrangements. Before entering into an ICT third-party arrangement, financial entities must assess whether the arrangement concerns an ICT service supporting critical or important functions, verify that the ICT third-party service provider complies with appropriate information security standards, and identify and assess all relevant risks. The contractual arrangements themselves must include detailed provisions covering service level descriptions, data processing locations, availability guarantees, termination rights, audit access, incident notification obligations, and exit strategies. These are not optional contract enhancements — they are regulatory requirements, and contracts that omit them expose the financial entity to supervisory findings.
Article 30 addresses key contractual provisions in greater detail, specifying the mandatory elements that must appear in contracts for ICT services supporting critical or important functions. These include the obligation for the ICT provider to cooperate with the competent authority, detailed provisions on exit strategies and transition periods, the right of the financial entity to conduct audits (directly or through pooled audits and third-party certifications), and data protection obligations that align with GDPR requirements. The level of specificity in Article 30 is unprecedented in financial regulation and reflects the ESAs' recognition that inadequate contracts have historically been a primary source of third-party risk materialisation.
DORA's ICT third-party register is not a one-time documentation exercise. It must be kept current and submitted to competent authorities upon request. Financial entities should treat it as a living inventory maintained through automated data feeds wherever possible.
4. NIS2 Supply Chain Security Under Article 21(2)(d)
NIS2 takes a broader approach to supply chain risk than DORA, reflecting its cross-sectoral scope. Article 21(2)(d) requires essential and important entities to implement measures addressing supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers. Unlike DORA, which focuses specifically on ICT third-party service providers, NIS2's supply chain obligation extends to any supplier or service provider whose compromise could affect the entity's network and information system security.
The practical implications are significant. An energy utility must consider not just its IT vendors but also its operational technology suppliers, maintenance contractors, and any third party with physical or logical access to control systems. A hospital must assess not just its electronic health record provider but also medical device manufacturers, laboratory service providers, and facilities management companies whose systems connect to hospital networks. The scope determination under NIS2 requires a risk-based analysis of every supplier relationship to determine which ones could plausibly affect network and information system security.
Article 21(2)(d) further requires entities to take into account the vulnerabilities specific to each direct supplier and service provider, the overall quality of products and cybersecurity practices of suppliers and service providers, including their secure development procedures, and the results of coordinated security risk assessments of critical supply chains carried out under Article 22. This last element — coordinated risk assessments — is a novel EU-level mechanism where ENISA and the Cooperation Group can initiate sector-wide assessments of critical supply chains (as was done for 5G networks under the EU Toolbox). Entities must incorporate the results of any such assessments into their own supply chain risk management, creating a feedback loop between EU-level intelligence and entity-level controls.
5. TPRM vs VRM: Understanding the Distinction
The terms third-party risk management (TPRM) and vendor risk management (VRM) are often used interchangeably, but they denote different scopes. VRM is a subset of TPRM that focuses specifically on commercial vendors — organisations from which you purchase goods or services. VRM programmes typically concentrate on the procurement lifecycle: vendor selection, contract negotiation, performance monitoring, and renewal or termination. The risk domains addressed by VRM tend to centre on operational, financial, and compliance risks related to the vendor's delivery of contracted services.
TPRM encompasses VRM but extends to all third-party relationships, including non-commercial ones. Joint venture partners, industry consortia, open-source software communities, government agencies with data-sharing arrangements, academic research collaborators, and fourth-party dependencies (your vendor's vendors) all fall within TPRM's scope. This broader view is essential because risks do not respect commercial boundaries. An open-source library that is not a vendor relationship in any commercial sense can introduce catastrophic supply chain risk, as the Log4Shell vulnerability demonstrated. A government-mandated data reporting interface can become an attack vector if the government agency's systems are compromised.
For EU regulatory compliance, the TPRM framing is more appropriate than VRM. DORA refers to ICT third-party service providers — a term that encompasses both commercial vendors and non-commercial arrangements. NIS2 refers to direct suppliers and service providers, which again is broader than a vendor-only lens. GDPR Article 28 addresses data processors, which may include non-commercial entities. Organisations that build their risk management programme around VRM alone will leave regulatory gaps in their coverage of non-vendor third parties that nonetheless introduce material risk.
When building your programme, use TPRM as the umbrella framework and VRM as a workstream within it. This ensures you capture non-vendor third parties (open-source dependencies, data-sharing partners, fourth parties) that regulatory frameworks explicitly include.
6. Building a TPRM Programme: Core Components
An effective TPRM programme requires five core components: governance, inventory, assessment, monitoring, and reporting. Governance establishes the organisational structure, policies, roles, and accountability lines for third-party risk. Under DORA, the management body must approve the policy on the use of ICT services provided by ICT third-party service providers (Article 28(2)). Under NIS2, the management body must approve the cybersecurity risk-management measures that include supply chain security (Article 20). Both frameworks require management body oversight, not just CISO-level responsibility.
Inventory is the foundation of everything else — you cannot manage risk in relationships you do not know exist. Build and maintain a comprehensive register of all third-party relationships, classified by criticality, risk tier, and the nature of access or dependency. For financial entities under DORA, this inventory must conform to the specific register format defined in the ITS. For all in-scope entities, the inventory should capture at minimum: the identity and legal structure of the third party, the services provided, the data shared, the systems accessed, the contractual terms, the assessed risk level, and the date of last assessment.
Assessment, monitoring, and reporting form the operational cycle of the programme. Initial assessments evaluate a third party's risk profile before or during onboarding. Ongoing monitoring tracks changes in risk posture between formal assessments — a vendor that was low risk at contract signing can become high risk following a data breach, acquisition, or change in geopolitical circumstances. Reporting translates risk data into actionable intelligence for management bodies, risk committees, and regulators. The cadence and depth of each activity should scale with the third party's criticality tier: critical vendors warrant deep initial assessments, continuous monitoring, and quarterly board reporting, while low-risk suppliers may require only a standardised questionnaire and annual review.
7. GDPR Data Processor Obligations in the TPRM Context
GDPR Article 28 imposes specific obligations on controllers regarding their data processors, and these obligations form a critical component of any TPRM programme that involves personal data. The controller must use only processors providing sufficient guarantees to implement appropriate technical and organisational measures so that processing meets GDPR requirements and ensures the protection of data subject rights. Processing by a processor must be governed by a contract or other legal act that sets out the subject-matter and duration of processing, the nature and purpose, the type of personal data, categories of data subjects, and the controller's obligations and rights.
The practical intersection of GDPR Article 28 and TPRM programmes is significant. Every vendor or third party that processes personal data on your behalf is a data processor (or sub-processor) and must be subject to the contractual and oversight requirements of Article 28. This includes cloud infrastructure providers, SaaS platforms, payroll processors, marketing automation tools, analytics services, and any other third party that accesses, stores, transmits, or processes personal data. The controller must conduct due diligence to verify the processor's data protection capabilities, include the mandatory contractual clauses specified in Article 28(3), and maintain oversight throughout the processing relationship.
Sub-processor management is a particularly challenging area. Article 28(2) requires that a processor must not engage another processor without prior specific or general written authorisation of the controller. Where general authorisation is given, the processor must inform the controller of any intended addition or replacement of sub-processors, giving the controller the opportunity to object. In practice, this means your TPRM programme must track not just your direct third parties but also their sub-processors — a fourth-party visibility challenge that grows exponentially with the number of vendor relationships. Organisations under both GDPR and DORA face compounding obligations here, as DORA's ICT sub-outsourcing provisions in Article 29(2) impose additional requirements on the chain of ICT service providers.
What is the difference between TPRM and VRM?
Vendor risk management (VRM) is a subset of third-party risk management (TPRM) focused specifically on commercial vendor relationships. TPRM encompasses all external parties that introduce risk, including non-commercial partners, open-source communities, government data-sharing arrangements, and fourth parties (your vendors' vendors). EU regulations such as DORA and NIS2 use broader terminology — ICT third-party service providers and direct suppliers — that aligns with the TPRM scope rather than the narrower VRM lens.
What is the DORA ICT third-party register and who must maintain it?
The DORA ICT third-party register is a mandatory inventory of all contractual arrangements for ICT services, required under Article 28(2) for all financial entities within DORA's scope. The register must conform to the format specified in the Implementing Technical Standards published by the European Supervisory Authorities and must be submitted to competent authorities upon request. It must be kept current — not just created once — and should capture service descriptions, criticality assessments, data processing locations, sub-outsourcing chains, and contractual terms.
Does NIS2 supply chain security only apply to ICT suppliers?
No. NIS2 Article 21(2)(d) refers to supply chain security concerning relationships with direct suppliers and service providers, without limiting the obligation to ICT suppliers. Any supplier whose compromise could affect the security of an entity's network and information systems falls within scope. For example, a facilities management company with network access, an OT equipment manufacturer, or a maintenance contractor with physical access to critical infrastructure all require assessment under NIS2's supply chain provisions.
How does GDPR Article 28 interact with TPRM programmes?
GDPR Article 28 requires data controllers to conduct due diligence on processors, include mandatory contractual clauses, and maintain ongoing oversight of any third party processing personal data. This directly overlaps with TPRM: every vendor or partner that handles personal data must be assessed for data protection capability, bound by Article 28-compliant contracts, and monitored throughout the relationship. Sub-processor chains add complexity, as controllers must be informed of and able to object to new sub-processors engaged by their direct processors.
What risks does TPRM address beyond cybersecurity?
TPRM addresses a broad spectrum of risks including operational risk (service delivery failure or business continuity threats), financial risk (vendor insolvency or instability), compliance risk (regulatory violations by the third party that expose your organisation), reputational risk (association with unethical or sanctioned entities), concentration risk (excessive dependency on a single provider or related group), and geopolitical risk (data sovereignty issues, sanctions exposure, or political instability affecting supplier operations). A mature TPRM programme assesses all these dimensions, weighted by the criticality of the third-party relationship.
Ready to Operationalise This?
Turn this guide into working compliance workflows. Create an account or schedule a personalised demo.