Vendor Risk Management

# Vendor Risk Management

Definition

Vendor risk management (VRM), also called third-party risk management (TPRM), is the discipline of identifying, assessing, monitoring, and mitigating cybersecurity risks that originate from third-party relationships: software vendors, cloud service providers, managed service providers, SaaS applications, contractors, business partners, and any external entity that processes, stores, accesses, or influences the organization's data and systems.

The premise is structural. An organization does not operate in isolation. A typical mid-market company relies on 100 to 500 third-party vendors and service providers. Each third party that has access to the organization's data or systems is a potential breach vector. A vendor with weak security that has API access to the organization's production environment is an attack surface that the organization's own security controls do not cover.

The SolarWinds compromise (2020), the Kaseya VSA attack (2021), the MOVEit exploitation (2023), and every major supply chain incident share a common pattern: the attacker did not breach the target directly. The attacker breached a trusted vendor, and the trust relationship became the attack path. VRM exists to manage the risk that trust relationships create.

How It Works

The Vendor Risk Lifecycle

VRM operates as a continuous lifecycle across four phases:

Due diligence (pre-engagement). Before onboarding a new vendor, assess their security posture. The depth of assessment should be proportional to the risk: a vendor that will have access to Restricted data and production systems requires deep assessment (security questionnaire, SOC 2 report review, penetration test results, onsite assessment for critical vendors). A vendor providing low-risk services with no data access requires minimal assessment.

Tiering vendors by risk level is the first step. A common model:

| Tier | Risk Level | Access | Assessment Depth | |------|-----------|--------|-----------------| | Critical | High | Direct access to sensitive data or critical systems | SOC 2 Type II review, detailed questionnaire, contract security requirements, possible onsite assessment | | Important | Medium | Access to internal data or business-critical services | SOC 2 review or security questionnaire, contract security requirements | | Standard | Low | No direct data access, non-critical services | Standard questionnaire or self-attestation |

Contractual requirements. Embed security requirements in vendor contracts. Requirements should include: minimum security controls (MFA, encryption, patching cadence), breach notification timelines (the vendor must notify the organization within a defined period, typically 24 to 72 hours, of discovering a security incident that may affect the organization's data), right to audit (the organization can assess the vendor's security posture at defined intervals), data handling requirements (encryption, retention, disposal), and insurance requirements (the vendor maintains cyber insurance at a defined minimum).

Contractual requirements without enforcement are aspirational statements. The contract should specify consequences for non-compliance: remediation timelines, escalation procedures, and the right to terminate for material security deficiencies.

Ongoing monitoring. Vendor risk does not end at contract signing. Vendors change: they acquire other companies, they change their technology stack, they experience turnover in their security team, they face new threats. Ongoing monitoring verifies that the vendor's security posture is maintained throughout the relationship.

Monitoring methods: annual reassessment (repeat the questionnaire, review the updated SOC 2 report), continuous external monitoring (security rating services like BitSight or SecurityScorecard that provide ongoing outside-in assessment), incident monitoring (track the vendor's publicly disclosed security incidents and data breaches), and compliance verification (verify that certifications referenced in the contract are maintained and current).

Offboarding. When a vendor relationship ends, deprovisioning must be complete: revoke all access credentials, terminate API integrations, verify that the vendor has destroyed or returned all organizational data per the contractual requirements, and remove the vendor's systems from the trusted access list. Incomplete offboarding leaves access paths that nobody monitors, which are exactly the access paths an attacker targets.

The Questionnaire Problem

The industry-standard approach to vendor assessment is the security questionnaire: a document containing 50 to 200 questions about the vendor's security controls, sent to the vendor for completion. The vendor's sales team or GRC team fills it out and returns it. The organization reviews the responses and assigns a risk rating.

This approach has well-documented limitations:

Self-reported data. The vendor fills out the questionnaire. There is no independent verification that the answers are accurate. Vendors have an incentive to present their security posture favorably. Answers like "yes, we have MFA" may mean "we have MFA available but not enforced" or "we enabled MFA for our admin accounts but not for general users."

Point-in-time snapshot. The questionnaire captures the vendor's posture at the time of completion. It does not reflect changes that occur between annual reassessments. A vendor that was secure in January may experience a security regression by June that the organization does not discover until the next annual assessment.

Questionnaire fatigue. Vendors that serve hundreds of customers receive hundreds of questionnaires. Each customer sends a different questionnaire with different questions in different formats. The vendor's security team spends more time filling out questionnaires than improving security. The responses become template answers rather than thoughtful evaluations.

No operational context. A questionnaire answer of "yes, we encrypt data at rest" does not reveal what algorithm is used, how keys are managed, whether encryption is applied consistently, or whether the encryption implementation has been tested. Questionnaires capture checkbox compliance, not operational reality.

CDA's approach supplements questionnaires with operational verification: external assessment of the vendor's internet-facing posture (the same attack surface management techniques used for the organization's own environment), SOC 2 report review (which provides independent auditor assessment rather than self-reporting), contractual requirements with enforcement mechanisms, and continuous monitoring through security rating services.

Standardized Frameworks

Several frameworks standardize vendor risk assessment:

SIG (Standardized Information Gathering). Published by Shared Assessments, the SIG questionnaire provides a comprehensive, standardized set of questions covering 18 risk domains. The SIG Lite version provides a streamlined assessment for lower-risk vendors. SIG is the most widely adopted vendor assessment questionnaire in financial services and healthcare.

CAIQ (Consensus Assessments Initiative Questionnaire). Published by the Cloud Security Alliance, the CAIQ is specifically designed for cloud service provider assessment. It maps to CSA's Cloud Controls Matrix (CCM) and covers cloud-specific security topics.

NIST CSF Profiles. Organizations can request that vendors provide a NIST CSF Current Profile demonstrating their security posture against the framework's functions and categories. This approach is framework-aligned but requires the vendor to have conducted a CSF self-assessment.

SOC 2 Type II reports. The strongest form of vendor assurance short of a direct onsite audit. A SOC 2 Type II report provides an independent CPA firm's opinion on whether the vendor's controls operated effectively over a defined period. Requesting and reviewing SOC 2 reports is the most efficient way to assess critical vendor security because the assessment is independent, structured, and covers a period rather than a point in time.

Why It Matters

Third-Party Breaches Are Increasing

The frequency and impact of third-party breaches are increasing. The SolarWinds supply chain compromise affected 18,000 organizations. The MOVEit vulnerability exposed data from 2,500+ organizations. The Kaseya attack reached 1,500+ businesses through their MSPs. Each of these incidents involved a trusted vendor whose compromise cascaded to their customers.

Gartner predicted that by 2025, 45% of organizations worldwide will have experienced attacks on their software supply chains. The prediction was conservative. Organizations that do not manage vendor risk are not managing a significant portion of their overall cybersecurity risk.

Regulatory Mandates

VRM is mandated or strongly recommended by every major compliance framework. NIST CSF 2.0 elevated supply chain risk management to a category under the Govern function (GV.SC). ISO 27001:2022 includes Control A.5.19 (Information Security in Supplier Relationships), A.5.20 (Addressing Information Security Within Supplier Agreements), and A.5.21 (Managing Information Security in the ICT Supply Chain). PCI DSS Requirement 12.8 mandates policies and procedures for managing service providers with access to cardholder data. HIPAA requires business associate agreements (BAAs) with entities that handle PHI. SOC 2 CC9.2 requires vendor risk management processes.

The regulatory trend is clear: organizations are accountable for the security of their third parties, not just their own environments.

Insurance Implications

Cyber insurance underwriting increasingly evaluates VRM programs. Insurers ask about vendor assessment processes, critical vendor identification, and contractual security requirements. Some policies exclude losses that arise from vendor compromises if the organization did not conduct adequate due diligence. The insurance market is reinforcing the regulatory mandate: manage your vendor risk or face coverage limitations.

Related Articles

• Risk Governance and Assurance (RGA): Outer Space
• Supply Chain Security
• SOC 2 Type II
• Cyber Insurance
• ISO 27001
• NIST Cybersecurity Framework (CSF) 2.0

Sources

1. National Institute of Standards and Technology (NIST). "Cybersecurity Framework (CSF) 2.0: GV.SC (Cybersecurity Supply Chain Risk Management)." U.S. Department of Commerce, 2024.
2. International Organization for Standardization. "ISO/IEC 27001:2022, Annex A.5.19, A.5.20, A.5.21." ISO, 2022.
3. Shared Assessments. "Standardized Information Gathering (SIG) Questionnaire." Shared Assessments Program, updated annually.
4. Cloud Security Alliance. "Consensus Assessments Initiative Questionnaire (CAIQ) v4." CSA, 2022.
5. Gartner. "Predicts 2023: Cybersecurity Industry Focuses on the Human Deal." Gartner, 2022. (Third-party attack prediction.)

Word count: 1,918