Third-Party and Vendor Risk Management

Third-party and vendor risk management (TPRM/VRM) is the structured discipline through which organizations identify, assess, monitor, and respond to security and compliance risks arising from relationships with external entities — suppliers, software vendors, cloud providers, contractors, and other service partners. The scope spans initial due diligence through ongoing monitoring and contract termination. Regulatory bodies including the Office of the Comptroller of the Currency (OCC), the Federal Financial Institutions Examination Council (FFIEC), and the Department of Health and Human Services (HHS) Office for Civil Rights have each issued binding or guidance-level expectations that make formal TPRM programs a compliance requirement rather than an optional practice. Practitioners navigating this sector will find the field governed by overlapping frameworks, tiered vendor classification systems, and audit-ready documentation standards. The Infosec Providers on this site catalog service providers and framework resources relevant to this discipline.

Definition and scope

Third-party risk management addresses the exposure an organization accepts when it extends trust — data access, system connectivity, process dependency — to an external party. The term "vendor" is used broadly and encompasses software-as-a-service (SaaS) providers, managed security service providers (MSSPs), payroll processors, legal firms, cloud infrastructure vendors, and subcontractors retained by primary vendors (fourth parties).

NIST defines supply chain risk management within NIST SP 800-161 Rev. 1 as encompassing "the processes to identify, assess, and mitigate products and services that may contain potentially malicious functionality, are counterfeit, or are vulnerable due to poor manufacturing and development practices within the supply chain." This framing covers both intentional threats and unintentional security deficiencies introduced through external relationships.

The scope of TPRM programs is typically bounded by two axes:

• Risk tier — The sensitivity of data or criticality of systems the vendor can access, ranging from Tier 1 (no data access, minimal integration) through Tier 4 (direct access to regulated data or critical infrastructure).
• Relationship type — Technology vendors, professional service firms, and outsourced business process providers carry distinct risk profiles and require different assessment approaches.

How it works

A functional TPRM program operates across five discrete phases:

1. Vendor identification and inventory — Cataloging all third-party relationships, including shadow IT and departmentally contracted tools that may not route through central procurement. Without a complete inventory, risk tiering is structurally incomplete.

2. Risk tiering and classification — Assigning each vendor to a risk category based on data access scope, regulatory sensitivity, and operational criticality. The FFIEC IT Examination Handbook — specifically the Third-Party Relationships booklet — outlines tiering criteria for financial institutions, including whether a third party supports critical operations or processes nonpublic personal information.

3. Due diligence and initial assessment — Collecting and evaluating security documentation: SOC 2 Type II reports, ISO 27001 certifications, penetration test summaries, business continuity plans, and responses to standardized questionnaires such as the Shared Assessments Standardized Information Gathering (SIG) questionnaire.

4. Contract and SLA alignment — Embedding security requirements into contractual terms, including breach notification timelines, audit rights, subcontractor disclosure obligations, and incident response coordination responsibilities. HHS guidance under 45 CFR § 164.308(b) requires covered entities to execute Business Associate Agreements (BAAs) with vendors who handle protected health information (PHI).

5. Ongoing monitoring and reassessment — Continuous or periodic review of vendor security posture through updated questionnaires, external threat intelligence, and trigger-based reassessments (e.g., vendor breach disclosures, ownership changes, scope expansions). The OCC's Third-Party Relationships: Interagency Guidance (2023), jointly issued with the Federal Reserve and FDIC, formalizes ongoing monitoring as a required program element for banking organizations.

Common scenarios

SaaS vendor with regulated data access — A healthcare organization contracts a SaaS platform for patient scheduling. The vendor stores PHI, triggering BAA requirements under HIPAA and full-tier due diligence including a review of the vendor's encryption standards, access control policies, and breach history.

Mergers and acquisitions due diligence — An acquiring company inherits the target's vendor ecosystem, including any undisclosed fourth-party dependencies. TPRM practitioners conduct rapid vendor inventory and tiering as part of pre-close or post-close integration assessment.

Supply chain software compromise — A development toolchain component used by a primary software vendor is compromised upstream. This scenario — exemplified by documented supply chain incidents involving widely deployed IT management software — requires organizations to have fourth-party visibility and contractual rights to vendor subcontractor disclosures. CISA's Cyber Supply Chain Risk Management (C-SCRM) guidance addresses this attack vector directly.

Critical infrastructure outsourcing — An energy utility outsources operational technology (OT) network monitoring to a managed services provider. NERC CIP standards, specifically NERC CIP-013-1, mandate supply chain risk management plans for bulk electric system operators.

Contrast — IT vendor vs. professional services firm: An IT vendor with system-level access to internal infrastructure requires technical security controls review (network segmentation, privileged access management, logging). A law firm handling litigation documents requires data handling policy review, secure transmission verification, and subcontractor disclosure — the assessment methodology differs significantly despite both qualifying as third parties.

Decision boundaries

TPRM programs require practitioners to distinguish between assessment types, program triggers, and escalation thresholds. Key decision points include:

• When to require a full assessment vs. a streamlined questionnaire — Typically determined by risk tier assignment; Tier 3 and Tier 4 vendors generally require full due diligence including evidence review, while Tier 1 and 2 vendors may qualify for abbreviated self-attestation processes.
• When a vendor's risk profile triggers executive or board-level reporting — Regulated industries including banking and publicly traded companies face disclosure obligations when vendor concentrations or incidents cross materiality thresholds. The SEC's cybersecurity disclosure rules (effective December 2023) require registrants to disclose material cybersecurity incidents, which may originate from third parties.
• When to terminate or pause a vendor relationship — Contractual offboarding criteria should specify conditions: unresolved critical findings, breach of SLA security terms, or failure to maintain required certifications such as SOC 2 Type II or FedRAMP authorization for federal contractors.
• Differentiating TPRM from procurement — TPRM is a risk function, not a sourcing function. Procurement evaluates cost and capability; TPRM evaluates security posture, compliance alignment, and residual risk acceptance. The two functions share data but carry distinct mandates and reporting lines.

Practitioners seeking to locate qualified TPRM service providers, framework consultants, and audit-readiness specialists can reference the Infosec Providers and review the for guidance on how providers in this sector are structured and classified.