Vendor risk management works only when it covers the full vendor lifecycle, from due diligence to offboarding, treating continuous monitoring as a core discipline rather than an end-of-year task.
When a supplier’s systems are compromised, the breach rarely stays contained; it moves upstream. Your data, your operations, your customers: all affected by a security failure you did not cause and may not have seen coming.
That gap (between the risk you carry through your supplier relationships and the visibility you have into it) is what third-party risk management (TPRM) and vendor risk management (VRM) exist to close.
Your third-party relationships now underpin most of your operations. Cloud providers, software vendors, outsourced processing, logistics partners: each one extends your operational perimeter in ways that are difficult to audit and sometimes harder to reverse. This guide sets out how a structured approach to third-party risk works in practice: what to assess, when to assess it, and how to design a programme that holds up under operational and regulatory pressure.
What TPRM and VRM mean in practice
TPRM is the discipline of identifying, assessing, and controlling the risks that arise from your relationships with external parties. Vendor risk management (VRM) is the subset focused on the suppliers you contract with directly.
In practice, the two terms are often used interchangeably. The distinction starts to matter in larger organisations with complex third-party ecosystems, where some relationships sit outside standard procurement channels (partnerships, interoperability agreements, industry bodies) but still carry material risk.
What both frameworks share is a straightforward principle: when you engage a vendor, you inherit a portion of their risk profile. If their controls are weak, your data may be exposed. If their operations fail, your service continuity is affected. If they breach a regulation, the compliance consequence may extend to you. The scope of TPRM is broader than most programmes assume at the start.
The six stages of vendor risk you need to manage
Your vendor risk management programme does not end when a contract is signed. It runs across the full relationship: from initial sourcing through to offboarding. Treating each stage as a distinct operational discipline is what separates programmes that work from those that exist only on paper.
Start with inventory; you cannot manage what you have not counted. Supplier lists in procurement systems rarely reflect operational reality. Shadow agreements, legacy contracts, and relationships managed at department level often never reach a central register. Without a reliable inventory, everything that follows is guesswork.
Once you have a complete picture, segment your vendors by criticality. Not every supplier warrants the same intensity of oversight. Criticality criteria should combine data access (what type, how much, where stored), operational dependency (what fails if the vendor fails), and regulatory sensitivity. This classification determines how much due diligence each vendor receives and how frequently you reassess them.
Before onboarding, carry out due diligence on the vendor’s control environment: security certifications, business continuity arrangements, data protection practices, and subcontractor relationships. Questionnaires are the most common vehicle. Bear in mind that questionnaire responses are declarations, not evidence. For higher-criticality vendors, verify responses against audit reports, penetration testing summaries, and certification documents.
Due diligence findings feed into a risk profile, which shapes what goes into the contract. Risk management at this stage is a practical decision: which risks you accept and which require contractual controls. The clauses that reduce your exposure most reliably include breach notification obligations with specified timing and scope, rights of audit, subprocessor disclosure and approval requirements, data localisation commitments, and exit provisions that protect your data and continuity when the relationship ends.
Continuous monitoring is where most programmes lose effectiveness. The risk management lifecycle does not pause after onboarding. Ownership changes, certifications lapse, infrastructure vulnerabilities emerge. A programme that only reviews vendors at the point of onboarding will miss most of the risk that actually materialises. Set a review cadence by criticality tier: quarterly for your highest-risk vendors, annually for lower-tier suppliers. Review outside that schedule whenever a significant change occurs: an ownership change, a security incident, or a material shift in scope.
Offboarding is the stage most often neglected. Ending a vendor relationship carries its own risks: data return and deletion, access revocation, knowledge transfer, and service continuity all require structured management. The compliance exposure from underdeveloped offboarding rarely becomes visible until after the relationship has ended.
The four risk categories your assessment needs to cover
At due diligence and at each reassessment, the categories of risk to evaluate are broadly consistent. The depth of your assessment should reflect the vendor’s criticality tier.
Cybersecurity risk covers the vendor’s technical controls, vulnerability management processes, incident detection and response capability, and the security of any integration points with your systems. ISO 27001 certification is a useful baseline indicator, not a guarantee. Certification scope matters, and certificates can lapse or be held by entities that have since changed their practices.
Operational and business continuity risk covers resilience to disruption. You want to know not just whether a vendor has a business continuity plan, but whether they have tested it and when. For vendors providing critical services, evidence of testing carries more weight than documentation.
Data protection and compliance risk covers how the vendor handles personal data, where it is stored and processed, how cross-border transfers are managed, and whether the vendor maintains its own compliance programme. This is especially relevant for processors operating across jurisdictions.
Supply chain risk covers your vendor’s own subcontractors and technology dependencies. A vendor may have strong internal controls while depending on third parties with materially weaker security practices. The most practical control available is contractual: require vendors to disclose their key subcontractors, apply minimum security standards in those relationships, and inform you of material changes.
TPRM and regulatory requirements (NIS2, DORA, GDPR, ISO, EU AI Act)
The requirements across NIS2, DORA, GDPR, and ISO overlap considerably. A well-designed TPRM programme can satisfy most of them through a single set of processes, provided you build that overlap into the design from the start.
The NIS2 Directive requires operators of essential services and important entities to manage supply chain security as part of their cybersecurity obligations. You need to assess the security practices of your direct suppliers and be able to demonstrate that assessment to the relevant national authority.
DORA applies to financial institutions and their ICT service providers. It requires written agreements with all ICT third-party service providers covering access rights, audit rights, data security standards, and business continuity. It also introduces mandatory registers of ICT third-party dependencies and, for providers designated as critical, direct supervisory oversight by European financial regulators. If you already have a functioning TPRM programme, the right approach to DORA is a gap analysis, not a new process.
GDPR requires that any vendor processing personal data on your behalf does so under a data processing agreement that specifies the subject matter, duration, nature, and purpose of processing, with appropriate security obligations. You are required to carry out due diligence on processors before appointment.
ISO 27001 addresses supplier relationships requiring a policy for managing information security across supplier relationships. ISO 22301 requires that your continuity arrangements account for the resilience of key suppliers, not only your own operations.
For vendors that use AI systems, your assessment also needs to account for the requirements of the EU AI Act, particularly those covering transparency, oversight, and risk management for high-risk systems. The Regulation applies to both providers of AI systems and deployers that put those systems to use, so using an AI solution supplied by a third party creates its own regulatory obligations on your side. Vendor due diligence for AI-based solutions therefore needs to establish which risk category the system falls into, whether it has undergone the required conformity assessment, and how human oversight of its operation is documented. For high-risk systems, the Regulation also requires technical documentation, event logging, and audit-enabling mechanisms; these obligations must be reflected in your contract terms with the vendor. Without those provisions, you absorb the vendor’s regulatory exposure with no meaningful ability to control it.
Where programmes lose effectiveness
The most common gap is coverage; you build an assessment process and apply it to a fraction of your actual supplier base. Critical vendors receive thorough attention; mid-tier and tail suppliers do not. Risk concentrates precisely where your visibility is lowest.
Treating due diligence as a one-time gate is the second recurring failure. A vendor that passed assessment three years ago may have changed significantly. Acquisitions, leadership changes, and technology platform shifts can all alter a vendor’s risk profile without triggering a reassessment under a poorly designed programme.
Over-reliance on questionnaire responses compounds this. The quality of a questionnaire response depends on the honesty and competence of the person completing it. For high-criticality vendors, validate responses against evidence: current audit reports, penetration testing summaries, and the actual scope of certifications held.
The fourth failure is structural. Vendor risk management sits at the intersection of procurement, IT, security, legal, and compliance. When none of those functions has a clear mandate, the programme exists on paper but not in practice. Effective TPRM requires a designated owner with sufficient authority, active contribution from each relevant function, and executive sponsorship that keeps the programme operating consistently, not only at the point of a high-profile incident.
Summary
Vendor risk management only works when it stops being a one-off project and becomes a steady part of how your organisation operates. Full lifecycle coverage, criticality-based segmentation, evidence-backed due diligence, and continuous monitoring form a single mechanism in which each element reinforces the others. NIS2, DORA, GDPR, and the ISO standards now describe what mature TPRM programmes have been practising for years, so for most organisations, the practical first step is a gap analysis against the existing process; building a new programme from scratch is rarely the answer. The most important decision sits earlier: who in your organisation has the mandate to keep the programme running day to day.
