Vendor Risk Management
Also known as: VRM, third-party risk management, TPRM, supplier risk management, supply chain risk management
Vendor risk management (VRM), also called third-party risk management (TPRM), is the ongoing process of identifying, assessing, monitoring, and mitigating the risks that third-party suppliers introduce to an organization through access to its systems, data, or operations.
Modern organizations rely on hundreds or thousands of vendors -- cloud providers, payroll services, software tools, professional service firms -- each of which can introduce cybersecurity, data privacy, compliance, or business continuity risk. VRM programs evaluate vendors before onboarding, set contractual security requirements, monitor vendors continuously, and manage incidents when vendors are breached.
Vendor Risk Management, explained at three levels
At home
Vendor risk management is about not trusting blindly that the companies you work with are as secure as you are. When you give a third-party company access to your systems or customer data, their security weaknesses become your problem. If your payroll provider gets hacked and employee salaries are exposed, your employees will blame you, not the payroll provider. VRM is the process of checking vendors' security before you sign up, putting security requirements in contracts, and checking in periodically to make sure they are still secure.
At work
A VRM program protects your organization from the risks that vendors introduce -- data breaches through vendor access, non-compliance passed through the supply chain (your vendors' GDPR violations become your violations too), operational disruptions when a key vendor goes down, and reputational damage when vendors behave improperly with your data. VRM involves: vendor inventory (knowing all your vendors), risk tiering (classifying vendors by their access to sensitive data and systems), due diligence (assessing each vendor's security posture before and during the relationship), contractual requirements (DPAs, security provisions, audit rights), and incident management (responding when a vendor is breached).
At home
VRM programs typically classify vendors by risk tier based on the sensitivity of data they access, the criticality of the service they provide, and their level of access to systems. A Tier 1 vendor (access to sensitive personal data, critical to operations) might require SOC 2 Type II attestation, annual security questionnaire, and DPA before onboarding. A Tier 3 vendor (no personal data access, low operational criticality) might require only a brief questionnaire. This tiering prevents organizations from spending the same due diligence effort on their office coffee supplier as on their cloud hosting provider.
At work
Third-party risk assessment methods include: security questionnaires (standardized or using frameworks like SIG, CAIQ, or VSA), review of third-party attestation reports (SOC 2, ISO 27001 certificates, penetration test summaries), contractual provisions (right to audit, security requirements, incident notification obligations), and continuous monitoring tools that track vendors' externally visible security posture (certificate expiry, dark web mentions, known vulnerabilities in the vendor's public-facing systems).
At home
Fourth-party risk is an increasingly important aspect of VRM: the risk introduced by your vendors' vendors. A cloud provider's security posture depends partly on their own supply chain -- the software libraries they use, the data center facilities they lease, the sub-processors they engage. Comprehensive VRM programs ask vendors to disclose key sub-processors and sub-contractors, require vendors to maintain their own VRM programs, and review CSP customer responsibility matrices to understand the shared responsibility model for cloud services.
At work
From a practitioner standpoint, the most common VRM failure is the offboarding gap: vendors are assessed at onboarding but not reassessed regularly, not notified of scope changes, and not formally offboarded when the relationship ends. A vendor that was low-risk at onboarding may become high-risk after expanding its service scope to include access to new data categories. VRM programs should trigger re-assessment when: the vendor's service scope expands, the vendor is acquired, the vendor discloses a security incident, the vendor's SOC 2 report or certificate lapses, or the vendor relationship changes materially. Offboarding should confirm that all access credentials have been revoked and that the vendor has deleted or returned all data per contract requirements.
Real-world examples
At home
Nadia hires a freelance developer to build a client portal for her law firm. Before giving the developer access to client records, she reviews their security practices, signs a confidentiality agreement with data handling clauses, and limits their access to only the test environment until development is complete. When the project ends, she immediately revokes all access credentials.
At work
The procurement team at Harrington Financial Services implemented a tiered vendor risk program. Critical vendors (Tier 1) required SOC 2 Type II reports within the last 12 months, annual security questionnaires, and signed DPAs before onboarding. A quarterly review dashboard flagged three Tier 1 vendors whose SOC 2 reports had lapsed -- each received a remediation notice requiring renewal within 60 days or suspension of data sharing.
Common confusions
- Vendor risk management is not a one-time procurement exercise. Assessing a vendor's security before signing a contract is necessary but not sufficient -- vendors' security postures change, they acquire other companies, they experience incidents, and their scope of service for your organization evolves. Effective VRM is continuous, not a gate at the start of a relationship.
- A vendor holding ISO 27001 certification or a SOC 2 report is not automatically low risk. Certifications and attestation reports apply to defined scopes; a vendor's certification may not cover the specific service or data they provide to your organization. Always check that the scope of the report or certificate covers the systems and services you are using, and that the report does not contain exceptions in areas relevant to your use case.
- VRM is not the same as contract management. A contract with good security provisions provides legal recourse after a breach -- it does not prevent the breach. VRM aims to prevent incidents by ensuring vendors actually implement the security measures they have contracted to provide, through due diligence, ongoing monitoring, and regular re-assessment rather than relying solely on contractual remedies after harm has occurred.
For analysts
In BA artefacts, VRM requirements surface as pre-conditions for integrations, procurement constraints, and ongoing monitoring obligations. When documenting requirements for a new system integration, specify the vendor's required risk tier, the due diligence evidence required before go-live (SOC 2 report, DPA, security questionnaire), and the contractual security provisions that must be in place. Include VRM re-assessment triggers in operational requirements: 'The vendor's security posture must be re-assessed if they disclose a material security incident, if their service scope expands to include additional personal data categories, or if their SOC 2 report or ISO 27001 certificate lapses.' This makes VRM an ongoing operational requirement, not just a procurement gate.
History & origin
Vendor risk management as a formal discipline emerged in the early 2000s, driven by high-profile supply chain attacks and regulatory requirements. The 2013 Target data breach -- where attackers entered Target's network through an HVAC vendor's credentials -- became a defining case study for third-party risk. Regulatory frameworks accelerated formalization: HIPAA required Business Associate Agreements (1996), PCI DSS required vendor management controls (2004), and GDPR Article 28 mandated documented controller-processor agreements (2018). The SolarWinds supply chain attack (2020) and the proliferation of SaaS tools dramatically expanded vendor risk programs' scope and elevated them to board-level attention.