Third-Party Risk Management (TPRM): A Practical Guide and Lifecycle

Last updated: 22 October 2026

Quick answer: Third-party risk management (TPRM) is the process of identifying, assessing, contracting for, monitoring and exiting the risks that come from vendors, suppliers, data processors, ICT providers and their own subcontractors. It runs as a lifecycle: inventory, tiering, due diligence, contracting, onboarding, continuous monitoring, remediation and offboarding. In Europe it is no longer optional for many organisations, because DORA, NIS2 and GDPR all put explicit duties on the organisation that relies on the third party.

Most organisations now depend on dozens or hundreds of outside providers: cloud hosts, SaaS tools, payroll processors, managed service providers, software vendors and, increasingly, AI services. Each one can expose your data, interrupt a service or bring a vulnerability into your environment.

Regulators have drawn the consequence clearly. Outsourcing a service does not outsource accountability. If a processor leaks personal data or an ICT provider goes down, supervisors look first at the organisation that chose and oversaw that provider, and at its management body.

Many teams still run vendor oversight on an annual spreadsheet questionnaire. That gives a snapshot once a year, leaves procurement, legal and security working from different lists, and says little about what changed in between.

This guide explains what TPRM covers, which regulations require it, how to run each stage of the lifecycle, how to tier vendors, what to automate and which metrics show the programme is working.

What is third-party risk management and what does it cover?

TPRM covers any external party that provides goods or services, handles your data, connects to your systems or supports a business process, plus the parties they rely on.

In practice the scope usually includes:

• Vendors and suppliers: anyone you buy software, hardware or services from, from a major cloud platform to a small marketing agency.
• Data processors: providers that process personal data on your behalf, such as CRM, HR, payroll and email platforms. These carry specific GDPR obligations.
• ICT service providers: cloud, hosting, data centre, network, managed IT and managed security providers. For financial entities, these are the focus of DORA.
• Outsourcing partners: providers running a whole function for you, such as customer support, claims handling or payment processing.
• Fourth parties: your vendors’ own subcontractors and sub-processors. You rarely have a contract with them, but their failures reach you just the same.

The risks are broader than cybersecurity. A mature programme looks at information security, data protection, operational resilience and continuity, concentration (too many critical services on one provider), financial stability, legal and regulatory compliance, and reputational or ethical concerns.

Why do regulators now require third-party risk management?

Because several EU and international frameworks now set explicit, auditable requirements for how you select, contract with and oversee third parties, and some make the management body directly responsible.

DORA: ICT third-party risk and the register of information

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied to EU financial entities since 17 January 2025. Chapter V (Articles 28 to 44) deals with ICT third-party risk. The main obligations for financial entities are:

• Manage ICT third-party risk as an integral part of the ICT risk management framework, with a strategy and policy on the use of ICT services, especially those supporting critical or important functions (Article 28).
• Maintain a register of information on all contractual arrangements with ICT third-party service providers, report on it to the competent authority at least yearly, and make the full register available on request (Article 28(3)).
• Assess providers before contracting, including due diligence and conflicts of interest (Article 28(4)), and assess ICT concentration risk (Article 29).
• Include the key contractual provisions set out in Article 30, with stronger requirements for services supporting critical or important functions, such as audit rights, exit and termination rights, and service levels.
• Have exit strategies for ICT services supporting critical or important functions (Article 28(8)).

Article 5 also requires the management body to approve and periodically review the policy on arrangements for ICT services provided by third parties. DORA separately creates an EU oversight framework for critical ICT third-party providers designated by the European Supervisory Authorities. Our DORA register of information guide explains the register’s structure and reporting in detail.

NIS2: supply chain security under Article 21

The NIS2 Directive (EU) 2022/2555 lists supply chain security among the minimum cybersecurity risk-management measures in Article 21(2)(d), “including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers”. Article 21(3) adds that entities must take into account the vulnerabilities specific to each direct supplier and service provider, the overall quality of their products and cybersecurity practices, including secure development procedures, and the results of coordinated EU supply chain risk assessments.

Under Article 20, management bodies must approve these measures, oversee their implementation and can be held liable for infringements under national law. See our guides on NIS2 supply chain security and the full set of Article 21 risk-management measures.

GDPR: Article 28 processors

Under Article 28 of the GDPR, a controller may only use processors that provide sufficient guarantees of appropriate technical and organisational measures. The processing must be governed by a contract that covers, among other things, documented instructions, confidentiality, security under Article 32, conditions for engaging sub-processors, assistance with data subject rights and breaches, deletion or return of data at the end of the service, and audit and information rights. Processors need the controller’s prior written authorisation, specific or general, to engage sub-processors, and must pass the same obligations down. Where processors transfer data outside the EEA, Chapter V transfer rules apply too.

ISO 27001: Annex A supplier controls

ISO/IEC 27001:2022 Annex A contains five supplier-related controls: 5.19 information security in supplier relationships, 5.20 addressing information security within supplier agreements, 5.21 managing information security in the ICT supply chain, 5.22 monitoring, review and change management of supplier services, and 5.23 information security for use of cloud services. Certification auditors will expect evidence that these operate in practice, not just a policy. Our overview of ISO 27001 Annex A controls covers them in context.

Outside the EU, similar expectations appear in the UK PRA’s supervisory statement SS2/21 on outsourcing and third-party risk management and in the US banking agencies’ 2023 interagency guidance on third-party relationships. The specifics differ, but the lifecycle below satisfies the common core.

What are the stages of the TPRM lifecycle?

A practical lifecycle has eight stages, from building the inventory through to a controlled exit. Each stage should produce evidence you can show an auditor or supervisor.

1. Build and maintain the third-party inventory

You cannot manage vendors you do not know about. Combine supplier lists from procurement and finance, contracts from legal, SaaS and cloud accounts from IT, and processors from your record of processing activities. For each third party, record the service, business owner, contract dates, data shared, systems connected, locations and any known subcontractors. Linking vendors to the assets and processes they support, as in GDPR data mapping, is what later lets you see which failures would hurt most.

2. Tier vendors by criticality and inherent risk

Not every vendor needs the same scrutiny. Use a short intake questionnaire to establish inherent risk: what data the vendor handles, whether it connects to your network, whether it supports a critical or important function, how easily it could be replaced, and whether it falls under a specific regulation. Tiering drives everything that follows, from assessment depth to review frequency (see the table below).

3. Carry out due diligence and security questionnaires

Scale the assessment to the tier. Low-risk vendors may need only basic checks. Higher tiers warrant a security and privacy questionnaire, review of certifications and reports such as ISO 27001 certificates or SOC 2 reports, policy evidence, financial checks, and for the most critical providers, a call or on-site review. Keep questionnaires focused: a long generic form sent to every vendor produces fatigue on both sides and answers nobody reads. Our vendor risk assessment questionnaire provides a question bank you can adapt by tier.

4. Contract with the right clauses

Turn due diligence findings into contractual obligations. Depending on the vendor and regulation, that means a data processing agreement meeting GDPR Article 28, DORA Article 30 provisions for ICT services, security requirements, incident notification timelines, audit and access rights, sub-contracting and sub-processor approval, service levels, data location, and termination and exit assistance. Legal, procurement and security should agree a standard clause set by tier so negotiations do not start from scratch.

5. Onboard securely

Before go-live, confirm that agreed controls are in place: access provisioned on least privilege, integrations reviewed, data flows documented and transfer mechanisms in place for any international transfers. Record the vendor owner, the residual risk accepted and the next review date.

6. Monitor continuously

Risk changes between annual reviews. Monitoring combines scheduled reassessments by tier with event-driven triggers: a vendor breach or outage, an expired certificate, a change of ownership, a new sub-processor, a new data type being shared, or a material change in the service. Track performance against service levels and keep certifications and reports current.

7. Manage issues and remediation

Findings from assessments or incidents should become tracked issues with an owner, an agreed fix and a deadline, recorded in your risk register alongside other organisational risks. Where a vendor cannot fix an issue, decide formally whether to accept, mitigate with your own controls, or exit. Our risk register template shows the fields that make vendor risks reportable.

8. Offboard and exit

When a relationship ends, revoke access, retrieve or confirm deletion of data (GDPR Article 28(3)(g) requires deletion or return), close integrations and update the inventory and any regulatory register. For critical services, the exit should follow a plan written and tested before you needed it, as DORA requires for ICT services supporting critical or important functions.

How should you tier third parties?

Tier on a combination of impact if the vendor fails and the sensitivity of the data or access it has, then let the tier set the depth and frequency of oversight.

The review frequencies are a common starting point, not a regulatory requirement. Set your own in line with your risk appetite statement, and record the rationale. Re-tier a vendor whenever the scope of the service or the data shared changes.

Common mistake: tiering on contract value. A low-cost SaaS tool that holds your customer database can be far riskier than an expensive consultancy with no data access.

What about cyber supply chain risk management (C-SCRM)?

C-SCRM is the part of third-party risk that focuses on the security of the technology you buy and the chain of suppliers that builds and maintains it.

Where general TPRM asks whether a vendor protects your data, C-SCRM also asks whether the software, hardware and services you depend on could be compromised before they reach you, for example through a tampered software update, a vulnerable open-source component or a compromised managed service provider with access to many customers.

NIST’s SP 800-161 Revision 1 is the most detailed public guidance on C-SCRM. It is mandatory practice for US federal agencies and widely used as a reference by federal contractors and private organisations. NIS2 Article 21(3) points the same way, by asking entities to consider suppliers’ secure development procedures.

Practical C-SCRM steps include:

• Asking critical software suppliers about secure development practices and how they handle vulnerabilities in third-party components, including whether they can provide a software bill of materials (SBOM).
• Identifying which providers have privileged or remote access to your environment and restricting and monitoring that access.
• Requiring prompt notification of security incidents and vulnerabilities affecting the products you use.
• Mapping concentration: which single providers, or shared fourth parties, sit behind several of your critical services.

What parts of TPRM should you automate?

Automate the repetitive collection, tracking and reminder work, and keep human judgement for tiering decisions, risk acceptance and negotiation.

Good candidates for automation are:

• A single vendor repository holding contracts, certifications, assessments and owners, instead of separate procurement, legal and security spreadsheets.
• Intake and tiering through a standard form that suggests a tier from the answers.
• Questionnaire distribution through a vendor-facing portal, with templates by tier, reminders and evidence upload, instead of email attachments.
• Review scheduling and alerts for reassessments, contract renewals and expiring certifications.
• Issue tracking that turns findings into tasks with owners and deadlines and feeds a central risk register.
• Reporting for management and regulators, such as dashboards by tier and exports that support registers like DORA’s.

Enactia’s Vendor and Third Party Management module covers much of this. It maintains a vendor registry with ownership, agreements and certifications, links vendors to your processes and assets, runs online vendor risk assessments and due diligence using ready-made or custom templates, lets vendors answer directly in the platform, tracks international data transfers and transfer impact assessments, and sends notifications and alerts. Vendor assessment risks flow into the central enterprise risk register, and the asset management module shows how risk propagates from a vendor to the assets and business processes it supports. Enterprise suites such as OneTrust or Archer tend to suit large organisations with dedicated administration teams; whichever tool you choose, check that it fits your tiering model and regulatory reporting needs.

If you want to see this applied to your own vendor list, you can start your 14-day free trial.

Which TPRM metrics should you track?

Track a small set of metrics that show coverage, timeliness and risk reduction, and report them to the management body that approves the policy.

In practice: start with coverage and overdue assessments. They are easy to measure and usually reveal the biggest gaps first.

Key takeaways

• TPRM covers vendors, suppliers, processors, ICT providers, outsourcers and fourth parties, across security, privacy, resilience and other risks.
• DORA, NIS2 Article 21, GDPR Article 28 and ISO 27001 Annex A all set specific third-party requirements, and DORA and NIS2 make management bodies accountable.
• Run TPRM as a lifecycle: inventory, tiering, due diligence, contracting, onboarding, monitoring, remediation and exit.
• Tier by impact and data sensitivity, not contract value, and let the tier set the depth of oversight.
• Automate collection, reminders and reporting; keep people for judgement and risk acceptance.

Frequently asked questions

What is the difference between TPRM and vendor risk management?
The terms are often used interchangeably. Vendor risk management usually refers to suppliers you buy from, while third-party risk management is broader and can include partners, outsourcers, affiliates and fourth parties that do not have a direct purchasing relationship with you.

What is a fourth party?
A fourth party is a subcontractor or sub-processor of your vendor, such as the cloud platform your SaaS provider runs on. You manage fourth-party risk mainly through your vendor: by asking who their key subcontractors are, requiring approval or notice of changes, and flowing down contractual obligations. GDPR and DORA both address subcontracting explicitly.

Does DORA require a register of all ICT vendors?
Yes. Article 28(3) requires financial entities to keep a register of information on all contractual arrangements for ICT services provided by ICT third-party service providers, with more detail for those supporting critical or important functions. Entities report on it to their competent authority at least yearly and must provide the full register on request.

How often should vendors be reassessed?
Base it on the tier. A common approach is at least annually for critical vendors, every one to two years for high and medium vendors, and at renewal for low-risk vendors, with event-driven reassessments after incidents or material changes. Document the rationale in your TPRM policy.

Are security questionnaires enough for due diligence?
Rarely on their own. Questionnaires are self-reported, so for higher-risk vendors combine them with independent evidence such as certifications, audit reports, penetration test summaries and contractual commitments, and follow up on answers that do not match the evidence.

Building a TPRM programme that lasts

Effective third-party risk management is less about a perfect questionnaire and more about a repeatable lifecycle: knowing who your third parties are, focusing effort on the ones that matter, writing findings into contracts, fixing issues and planning the exit before you need it. That same structure meets the core of DORA, NIS2, GDPR and ISO 27001 at once.

To discuss how Enactia can support your vendor and third-party programme, contact us or book a demo or start your 14-day free trial.

This article is for general information and is not legal advice.