What is Vendor Risk Management?

What is Vendor Risk Management?

Vendor risk management (VRM) is the process of identifying, assessing, monitoring, and mitigating risks associated with third-party vendors and service providers. As organizations increasingly rely on external partners for critical services — from cloud infrastructure to payroll processing — the security of those vendors directly impacts the organization's own risk posture.

Why vendor risk management matters

Third-party vendors are a leading source of data breaches and security incidents. When a vendor that handles your data is compromised, you are compromised. Compliance frameworks recognize this reality:

• SOC 2 — CC9.2 requires organizations to assess and manage risks associated with vendors and business partners
• ISO 27001 — controls A.5.19 through A.5.23 address information security in supplier relationships
• NIST CSF — the Identify function includes supply chain risk management
• HIPAA — requires Business Associate Agreements with vendors handling PHI
• PCI DSS — requires monitoring of service provider PCI DSS compliance

Components of a VRM program

An effective vendor risk management program includes:

Vendor inventory — maintain a complete list of all third-party vendors, including:

• What services they provide
• What data they can access
• Their criticality to business operations
• Contract terms and renewal dates

Risk assessment — evaluate each vendor's security posture through:

• Security questionnaires (SIG, CAIQ, or custom)
• Review of compliance reports (SOC 2, ISO 27001 certificates)
• Technical assessments when appropriate
• Review of publicly available security information

Risk tiering — classify vendors by risk level based on:

• Sensitivity of data they access
• Criticality of the service they provide
• Volume of data handled
• Regulatory requirements (e.g., HIPAA business associates)

Contractual protections — ensure vendor contracts include:

• Security requirements and responsibilities
• Data protection obligations
• Breach notification requirements
• Right to audit
• Compliance certifications

Ongoing monitoring — continuously monitor vendors through:

• Annual or periodic reassessments
• Review of updated compliance reports
• Monitoring for security incidents or breaches
• Tracking changes in the vendor's services or risk profile

Vendor assessment process

A typical vendor assessment follows these steps:

1. Categorize the vendor — determine risk tier based on data access and service criticality
2. Send questionnaire — distribute a security questionnaire appropriate to the risk tier
3. Review responses — evaluate the vendor's security practices against your requirements
4. Request evidence — ask for supporting documentation (SOC 2 report, policies, certifications)
5. Identify gaps — document areas where the vendor does not meet your standards
6. Make decision — approve, approve with conditions, or reject the vendor
7. Document results — record the assessment findings and decision
8. Schedule reassessment — set a date for the next review based on risk tier

Common challenges

• Managing assessments across dozens or hundreds of vendors
• Getting timely responses to security questionnaires
• Assessing vendors that lack formal compliance certifications
• Monitoring vendor risk between assessment cycles
• Balancing thoroughness with business velocity

VRM requirements by compliance framework

Different compliance frameworks address vendor risk management with varying depth and specificity. Understanding where each framework sets expectations helps you design a VRM program that satisfies multiple standards simultaneously.

SOC 2 treats vendor risk as part of the broader risk management criteria. CC9.2 requires organizations to assess risks arising from vendor and business partner relationships, while CC3.2 covers risk identification across the entity — including third-party risks. Auditors expect documented vendor inventories, risk assessments, and evidence of ongoing monitoring.

ISO 27001 provides the most prescriptive set of supplier controls. Controls A.5.19 through A.5.23 cover information security in supplier relationships, including establishing policies, addressing security within agreements, managing the ICT supply chain, monitoring and reviewing supplier services, and managing changes to supplier services.

HIPAA takes a narrower but legally binding approach. Any vendor that creates, receives, maintains, or transmits protected health information (PHI) on behalf of a covered entity must sign a Business Associate Agreement. The BAA must specify permitted uses of PHI, breach notification obligations, and data return or destruction requirements.

PCI DSS Requirement 12.8 requires organizations to maintain a list of service providers, ensure a written agreement acknowledging the provider's security responsibilities, establish a process for engaging providers, and monitor their PCI DSS compliance status at least annually. Requirement 12.9 adds that service providers must themselves acknowledge their responsibilities in writing.

NIST CSF 2.0 significantly expanded its supply chain risk management guidance, moving it from a sub-category into its own top-level function category — GV.SC — under the Govern function. This reflects the growing recognition that supply chain risk requires dedicated governance structures, not just ad hoc assessments. For a deeper look at these changes, see our guide to NIST CSF v2.0 changes.

Building a vendor risk tiering model

Not every vendor requires the same level of scrutiny. A risk tiering model lets you allocate assessment effort proportionally to the risk each vendor introduces. Most organizations use a four-tier model based on data sensitivity, service criticality, and replaceability.

Critical (Tier 1) — The vendor handles sensitive data (PII, PHI, cardholder data), provides a business-critical service, or would be difficult and costly to replace. Examples include your primary cloud infrastructure provider, EHR system, or payment processor.

• Full security assessment with detailed questionnaire (SIG or equivalent)
• Review of SOC 2 Type II report and/or ISO 27001 certificate
• Annual reassessment at minimum, with continuous monitoring where feasible
• Comprehensive contractual security requirements, including breach notification, audit rights, and data handling obligations
• Executive-level relationship management and regular security review meetings

High (Tier 2) — The vendor accesses internal systems or handles moderate-sensitivity data, but the service is not irreplaceable. Examples include HR/payroll platforms, CRM systems, or development tools with access to production data.

• Standard security questionnaire
• Review of available compliance certifications
• Annual reassessment
• Basic contractual protections including breach notification and data protection clauses
• Periodic check-ins with vendor security contacts

Medium (Tier 3) — The vendor has limited data access, provides a replaceable service, and does not interact with regulated data. Examples include project management tools, marketing analytics platforms, or office productivity suites.

• Abbreviated assessment or targeted questionnaire
• Biennial reassessment (every two years)
• Standard contract terms with security addendum
• Reassess earlier if the vendor's scope of access changes

Low (Tier 4) — The vendor has no access to organizational data and provides a commodity service. Examples include office supply vendors, cleaning services, or publicly available information tools.

• Self-attestation or security waiver
• Reassess on contract renewal
• Standard procurement terms, no additional security clauses required

The tiering decision should be documented in your risk register and revisited whenever the vendor's scope of service changes. A vendor that starts at Tier 3 may move to Tier 1 if you later grant it access to sensitive data.

Vendor assessment tools and questionnaires

Choosing the right assessment tool depends on the vendor's risk tier, your industry, and the depth of information you need.

SIG (Standardized Information Gathering) questionnaire — maintained by Shared Assessments, the SIG is the most widely used vendor assessment questionnaire. SIG Full covers 18 risk domains and is appropriate for Tier 1 and Tier 2 vendors. SIG Lite provides a condensed version for lower-risk vendors. The SIG maps to multiple compliance frameworks, making it efficient for organizations with overlapping regulatory requirements.

CAIQ (Consensus Assessment Initiative Questionnaire) — developed by the Cloud Security Alliance, the CAIQ is purpose-built for evaluating cloud service providers. It maps to the CSA Cloud Controls Matrix and covers cloud-specific risks such as multi-tenancy, data residency, and virtualization security. Use it alongside or in place of the SIG for cloud-heavy vendor portfolios.

Custom questionnaires — many organizations supplement standardized questionnaires with custom questions tailored to their specific regulatory environment or risk appetite. Custom questions are particularly useful for addressing industry-specific risks, such as PCI DSS requirements for payment processors or HIPAA requirements for healthcare vendors.

Automated risk rating platforms — tools like SecurityScorecard and BitSight provide continuous, outside-in assessments of a vendor's security posture by analyzing publicly observable signals such as DNS configuration, patching cadence, exposed services, and breach history. These platforms are useful for continuous monitoring between formal assessment cycles and for initial screening of prospective vendors.

Direct review of compliance reports — reviewing a vendor's SOC 2 Type II report is often more valuable than a questionnaire response. A SOC 2 report is independently audited and covers the vendor's actual controls over a defined period, including any exceptions or control gaps identified by the auditor. Similarly, an ISO 27001 certificate confirms that the vendor's information security management system has been independently assessed. When a vendor can provide these reports, they should be your primary source of assurance — supplemented by questionnaires only for areas not covered by the audit scope.

Vendor offboarding and incident response

Vendor risk management does not end when the contract is signed — it also requires structured processes for when the relationship ends or when something goes wrong.

Vendor offboarding — terminating a vendor relationship requires deliberate steps to protect your data and systems:

• Data return or destruction — require the vendor to return all organizational data in a usable format and certify destruction of any remaining copies. The contract should specify timelines and acceptable destruction methods (e.g., cryptographic erasure, physical destruction).
• Access revocation — immediately revoke the vendor's access to all systems, networks, VPNs, and APIs. Disable any service accounts, API keys, or shared credentials associated with the vendor.
• Certificate and key rotation — if the vendor had access to encryption keys, certificates, or shared secrets, rotate them promptly. This includes API tokens, SSH keys, and any credentials the vendor may have stored.
• Risk register update — update your risk register to reflect the terminated relationship and document any residual risks, such as data that was processed during the engagement.
• Knowledge transfer — if the vendor provided a critical service, ensure operational knowledge has been transferred to the replacement vendor or internal team before the relationship ends.

Vendor-side breach response — your contracts and BAAs should establish clear expectations for what happens when a vendor experiences a security incident:

• Notification timelines — specify how quickly the vendor must notify you of a confirmed or suspected breach. Industry standards range from 24 to 72 hours, but for critical vendors handling regulated data, shorter timelines may be appropriate. HIPAA requires notification without unreasonable delay and no later than 60 days.
• Cooperation requirements — the vendor should be contractually obligated to cooperate with your incident response investigation, including providing forensic evidence, access logs, and impact assessments.
• Remediation obligations — define who bears responsibility for remediation costs, including notification to affected individuals, credit monitoring, legal fees, and regulatory fines. The contract should also specify timelines for implementing corrective actions.
• Communication coordination — establish protocols for how breach-related communications will be coordinated between your organization and the vendor to ensure consistent messaging to regulators, customers, and the public.

A well-defined vendor offboarding and incident response process reduces the risk of lingering access, orphaned data, and confused responsibilities when the unexpected happens.

How episki helps

episki centralizes vendor risk management with vendor inventories, automated questionnaire distribution, risk scoring, and reassessment scheduling. The platform tracks vendor compliance status and flags vendors that require attention. Learn more on our compliance platform.