Category: Controller & Processor Roles

Third-Party and Vendor Risk Management

Also known as: TPRM, Third-Party Risk Management, Vendor Risk Management, VRM

Simply put

Third-Party and Vendor Risk Management is the process of identifying and reducing the risks that can arise when an organization relies on outside parties, such as vendors, suppliers, and business partners, to provide products or services. It aims to understand what could go wrong in these relationships and to put controls in place to manage those risks. Vendor Risk Management is generally treated as a subset focused specifically on the suppliers and vendors an organization uses.

Formal definition

Third-Party Risk Management (TPRM) is a form of risk management focused on identifying, assessing, and mitigating risks arising from an organization's use of third parties, implemented through a structured program that spans the third-party relationship lifecycle. Vendor Risk Management (VRM) is a narrower discipline concerned specifically with evaluating vendors, suppliers, and business partners and managing the risks associated with them; it is typically characterized as a subset of the broader TPRM domain, which may also intersect with enterprise risk management (ERM). In a data protection context, such programs are commonly used to support oversight of processors and other recipients of personal data, though the specific legal obligations governing those relationships (for example, controller-processor arrangements) derive from applicable law and instruments rather than from the risk-management program itself, and readers should verify those requirements against the current official text.

Why it matters

Organizations rarely operate in isolation. They rely on vendors, suppliers, and business partners to deliver products and services, and in a data protection context these third parties frequently process personal data on the organization's behalf or receive it as recipients. When something goes wrong within one of these relationships, the consequences can flow back to the organization that engaged the third party, which is why identifying and reducing third-party risk is a core governance concern rather than a purely operational one.

In the GDPR framework, a controller that engages a processor generally remains accountable for ensuring that appropriate safeguards are in place, and controller-processor arrangements are typically required to be governed by a written contract or other legal act. A TPRM or VRM program can help operationalize the oversight and due diligence that support these obligations, but the program itself does not create the legal requirements. Those obligations derive from applicable law and instruments, and the specific article references, contractual content requirements, and any national derogations should be verified against the current official text.

Because the discipline spans the full lifecycle of a third-party relationship, from selection and onboarding through ongoing monitoring and offboarding, weaknesses at any stage can expose an organization to privacy, security, operational, and compliance risk. The appropriate depth of assessment is generally risk-based and context-dependent, so a program should be calibrated to the nature of the data involved and the role each third party plays rather than applied uniformly.

Who it's relevant to

Data Protection Officers and Privacy Leads

DPOs and privacy leads typically use TPRM and VRM programs to help maintain visibility over which third parties process or receive personal data and under what safeguards. These programs can support the due diligence and monitoring activities associated with engaging processors, though the specific legal obligations governing those relationships derive from applicable law rather than from the program itself.

Compliance and Governance Teams

Compliance and governance functions generally rely on structured TPRM programs to operationalize oversight of third-party relationships and to document that appropriate controls are in place. Because the discipline may intersect with enterprise risk management, these teams often coordinate privacy-specific risk assessment with broader organizational risk governance.

Procurement and Vendor Management Functions

Procurement and vendor management teams are often the first point of contact in the third-party relationship lifecycle, from selection and onboarding onward. VRM, as a subset focused specifically on vendors and suppliers, is typically embedded in these processes so that risk considerations, including data protection risks, are addressed before and during engagement.

Legal Counsel

Legal counsel are generally involved in structuring the contracts and legal acts that govern third-party and controller-processor relationships. While a TPRM program can surface risks that inform these arrangements, counsel should verify the applicable contractual and legal requirements against the current official text, noting that member state implementation can vary.

Information Security and Engineering Teams

Security and engineering teams typically contribute to assessing the technical and organizational measures used by third parties and to ongoing monitoring of vendor risk. Their input helps ensure that risk assessments reflect the actual controls and data flows involved in each relationship, calibrated to the sensitivity of the data at stake.

Inside TPRM

Vendor Due Diligence

The assessment process undertaken before and during engagement of a third party that processes personal data, evaluating the vendor's technical and organisational measures, security posture, sub-processor arrangements, and ability to support the controller's compliance obligations. Under the GDPR, a controller must use only processors providing sufficient guarantees, as required by Article 28. The depth of diligence should generally be proportionate to the risk associated with the processing.

Data Processing Agreement (DPA)

A contract or other legal act required under Article 28 GDPR that binds a processor to the controller and sets out the subject matter, duration, nature and purpose of processing, the types of personal data and categories of data subjects, and the obligations and rights of the controller. It is distinct from a Data Protection Impact Assessment (Article 35), which is a risk assessment rather than a contractual instrument. A DPA is required where a processor acts on behalf of a controller and does not itself replace the need for a lawful basis for the underlying processing.

Sub-processor Management

Controls governing a processor's engagement of further processors. Article 28 generally requires that a processor not engage a sub-processor without prior specific or general written authorisation from the controller, and that equivalent data protection obligations flow down through the chain. Where general authorisation is used, the processor is typically expected to inform the controller of intended changes so the controller can object. The precise operational requirements can be shaped by the terms agreed and, in some cases, by regulator guidance.

Ongoing Monitoring and Audit Rights

Mechanisms allowing the controller to verify continued compliance over the life of the relationship, which may include audit and inspection rights reflected in the Article 28 arrangement, periodic reassessment, and review of security certifications or reports. Monitoring is generally treated as a continuing obligation rather than a one-time exercise, and its intensity typically scales with the risk of the processing.

International Transfer Controls

Where a vendor or its sub-processors are located outside the EEA, appropriate transfer mechanisms must be considered, such as an adequacy decision, Standard Contractual Clauses, or Binding Corporate Rules, potentially with supplementary measures following a transfer risk assessment. These mechanisms are distinct instruments and their availability and requirements evolve; readers should verify the current position against official sources. Standard Contractual Clauses and Binding Corporate Rules should not be treated as interchangeable.

Incident and Breach Coordination

Contractual and operational arrangements ensuring the vendor assists the controller with personal data breach obligations. Article 28 generally requires the processor to assist the controller in meeting breach-related duties, and processors are typically expected to notify the controller without undue delay after becoming aware of a breach. The controller usually retains responsibility for any required notification to the supervisory authority or data subjects, subject to assessment of the specific circumstances.

Common questions

Answers to the questions practitioners most commonly ask about TPRM.

If our organization signs a Data Processing Agreement with a vendor, does that transfer our compliance responsibility to them?

No. A Data Processing Agreement under Article 28 sets out obligations governing the processor's activities, but it does not shift accountability away from the controller. The controller generally remains responsible for the lawfulness of the processing and for demonstrating compliance, and typically must ensure it only engages processors providing sufficient guarantees. The vendor also bears its own direct obligations as a processor, but this is in addition to, not instead of, the controller's responsibilities. The precise allocation depends on the roles each party actually plays and should be assessed case by case.

Does a vendor risk assessment mean we have to obtain consent for every data-sharing arrangement with a third party?

No. Consent is only one of the legal bases available under Article 6, and engaging a vendor does not automatically require it. In many cases another basis, such as contract or legitimate interests, may be more appropriate, subject to assessment. Note also that where special category data under Article 9 is involved, an additional condition is required beyond the Article 6 basis. Vendor risk management concerns evaluating the third party's safeguards and reliability; it is a separate exercise from identifying and documenting the correct legal basis for the underlying processing.

How should we classify a vendor as a processor versus a controller, and why does it matter?

Classification generally turns on who determines the purposes and means of the processing rather than on contractual labels or job titles. A vendor acting only on documented instructions typically acts as a processor, while one deciding why and how data is processed may be a controller or joint controller. This matters because it drives which contractual instrument is appropriate, how obligations are allocated, and what accountability each party bears. Where the position is unclear, regulator guidance can help, though interpretations can diverge, so the analysis should be documented and revisited if the arrangement changes.

What should due diligence on a prospective vendor typically cover?

Due diligence commonly includes evaluating the vendor's technical and organizational measures, its use of sub-processors, its track record on security and reliability, the location of processing and any cross-border transfers, and its ability to support data subject rights and breach notification. The depth of review generally scales with the sensitivity and volume of data and the associated risk. The aim is to assess whether the vendor offers sufficient guarantees for the processing in question, and findings should be recorded to support the organization's accountability.

How do we handle vendors that use sub-processors?

Engagement of sub-processors is typically addressed within the Article 28 arrangement, which generally requires the processor to obtain authorization before engaging a sub-processor and to flow down equivalent data protection obligations. Organizations often maintain a mechanism to review and, where applicable, object to new sub-processors. Practically, this means tracking the sub-processor chain, understanding where processing occurs, and ensuring accountability is not lost as data moves further down the chain. The specific authorization mechanism should reflect what the contract provides.

What should we do when a vendor arrangement involves transfers of personal data outside the relevant jurisdiction?

Where a vendor arrangement involves transfers outside the EEA, or outside the UK under the UK GDPR, an appropriate transfer mechanism generally needs to be identified, and supplementary measures may be required depending on the circumstances. Available tools, adequacy positions, and expectations around supplementary measures evolve over time and can differ between regulators, so a mechanism that is appropriate at one point should not be assumed to remain so. Organizations should verify the current position against official sources and reassess arrangements periodically.

Common misconceptions

Signing a Data Processing Agreement makes the arrangement fully compliant and transfers liability to the vendor.

A DPA is a necessary component under Article 28 but does not by itself ensure compliance. The controller generally retains accountability for the processing, including having a lawful basis and verifying that the processor provides sufficient guarantees. Contractual allocation of responsibility does not automatically remove regulatory obligations, and the position is context dependent.

Every vendor relationship involving personal data is a controller-to-processor relationship requiring an Article 28 DPA.

The correct characterisation depends on who determines the purposes and means of processing. A vendor may act as a processor, a separate controller, or a joint controller, and the appropriate instrument differs accordingly. Conflating these roles can lead to the wrong contractual and compliance approach; the classification should be assessed for each relationship.

Using Standard Contractual Clauses guarantees that any international transfer to a vendor is lawful.

Transfer tools such as Standard Contractual Clauses are one recognised mechanism, but their use may need to be accompanied by a transfer risk assessment and supplementary measures depending on the destination and circumstances. Adequacy decisions and transfer tools evolve over time, so a mechanism that is sufficient today should not be assumed to remain so; verify against the current official position.

Best practices

Classify each vendor relationship by role (processor, separate controller, or joint controller) before selecting the appropriate contractual instrument, and revisit the classification if the processing changes.

Conduct risk-proportionate due diligence before onboarding and document the sufficient guarantees relied upon under Article 28, retaining evidence to support accountability.

Maintain an inventory of vendors and their sub-processors, including processing locations, so that international transfer mechanisms and supplementary measures can be assessed and kept current.

Ensure DPAs contain the elements required by Article 28, including sub-processor authorisation, audit and assistance obligations, and breach notification without undue delay to the controller.

Establish ongoing monitoring with periodic reassessment scaled to risk, rather than treating due diligence as a one-time exercise at contract signing.

Verify the current status of adequacy decisions and transfer tools against official sources at each review, since these mechanisms evolve and can diverge between EU and UK regimes.