How to Build a Third-Party Risk Management Programme

That Goes Beyond the Annual Questionnaire

The SolarWinds attack. The MOVEit vulnerability exploitation. The Change Healthcare ransomware incident. Three of the most significant cybersecurity events of recent years had one thing in common: the initial attack vector was a trusted third party. The organisation's own security controls were largely irrelevant because the attacker entered through a supplier that those controls did not cover. 

The most common response to third-party risk is the security questionnaire. Every year, suppliers receive a document asking whether they have a written information security policy, whether they conduct background checks, whether they have ISO 27001 or SOC 2. The supplier answers yes to most questions. The organisation files the response. The third-party risk has not been reduced by one iota. 

This guide is for the GRC professional building a TPRM programme that actually manages risk rather than documents the appearance of managing it.

A completed security questionnaire is evidence that the supplier filled out a form. It is not evidence that the supplier is secure. The questionnaire-only TPRM programme provides compliance evidence and false assurance simultaneously. The programme that actually manages risk uses questionnaires as one input among several, not as the primary control. 

The Five Components of a TPRM Programme That Works 

1. Third-party inventory and criticality tiering 

The foundation of any TPRM programme is knowing what third parties you have. Most organisations discover during their first TPRM programme build that they have significantly more third parties than they thought: shadow IT procurement, departmental SaaS subscriptions, legacy supplier relationships that never went through a formal approval process. 

Once the inventory exists, every third party must be assigned a criticality tier based on two factors: the data or systems they access (sensitivity), and the operational dependency on them (what happens to the business if this supplier fails or is compromised). A Tier 1 critical supplier requires a different assessment process from a Tier 3 low-risk one. The tiering is the mechanism that makes the programme scalable, applying the most intensive scrutiny to the highest risk, not uniformly to all. 

2. Risk assessment proportionate to tier 

Tier 1 (critical) suppliers: full security assessment including questionnaire, documentation review, evidence sampling, and ideally on-site assessment or third-party audit report review. Annual reassessment minimum. Contractual security requirements explicitly stated. 

Tier 2 (material) suppliers: detailed questionnaire, documentation review for high-risk areas, evidence of relevant certifications (ISO 27001, SOC 2 Type II). Biannual review minimum. 

Tier 3 (standard) suppliers: streamlined questionnaire, standard contractual requirements, triennial review or event-triggered review on significant changes. 

3. Continuous monitoring 

Third-party risk does not expire annually when a questionnaire is refreshed. The supplier who was secure at the start of the year can be compromised by February. Continuous monitoring uses external threat intelligence sources, SecurityScorecard, BitSight, Recorded Future to detect degraded security posture, data breach disclosures, dark web mentions, and infrastructure changes in critical suppliers between formal assessments. Monitoring triggers investigation when the risk profile of a critical supplier changes materially. 

4. Contractual security requirements 

Security assessments without contractual teeth are advisory. For Tier 1 and Tier 2 suppliers, the contract must specify: minimum security standards the supplier must maintain, breach notification obligations (timeline and scope), the right to audit, data handling and sub-processor restrictions, and incident response cooperation requirements. Under DORA, ICT third-party contracts for EU financial entities have specific mandatory clauses that must be included. 

5. Fourth-party risk visibility 

The supplier's suppliers are the fourth-party risk layer that most TPRM programmes ignore. The SolarWinds incident was a fourth-party risk event for many organisations; their direct supplier was not compromised, but the supplier's supplier was. DORA explicitly requires ICT third-party risk management to address concentration risk and supply chain depth. The TPRM programme that only looks one tier deep has blind spots that sophisticated attackers exploit.

The TPRM programme that ticks all five boxes inventory, tiered assessment, continuous monitoring, contractual requirements, and fourth-party visibility is still not a guarantee against supply chain compromise. It is a programme that reduces the probability of undetected compromise, speeds detection when compromise occurs, and demonstrates the governance standard that regulators and auditors increasingly require. 

The DORA Context 

For financial services organisations within DORA scope, TPRM is not optional and the requirements are specific. DORA Article 28 requires financial entities to implement a comprehensive ICT third-party risk management policy, including pre-contractual due diligence requirements, mandatory contractual provisions, ongoing monitoring and assessment, and exit strategies for critical third-party dependencies. 

DORA introduces the concept of Critical Third-Party Providers (CTPPs): ICT third-party providers designated as critical by the European Supervisory Authorities based on systemic importance. CTPPs face direct regulatory oversight and examination. Financial entities that rely on CTPPs must manage those relationships with enhanced scrutiny. 

For UK organisations outside DORA scope, the PRA and FCA operational resilience frameworks impose similar but not identical third-party risk requirements. The direction of travel is the same: supply chain risk management is moving from best practice to regulatory obligation across the financial sector globally.