Third-party breaches doubled year-over-year to account for 30% of all breaches in 2025 (SecurityScorecard). Nearly every high-impact breach involved a vendor-access vector, from compromised OAuth tokens affecting 700+ organizations (Salesloft-Drift) to antivirus update server compromises (eScan) and hosting provider breaches enabling software supply chain attacks (Notepad++). The Vanta State of Trust Report found that 46% of organizations experienced a vendor data breach after beginning the partnership.
Despite this, most organizations still rely on point-in-time questionnaires that assess risk at onboarding and then assume nothing changes. This guide covers how to build a third-party risk management (TPRM) program that continuously manages vendor risk throughout the relationship lifecycle.
Why TPRM Matters
Your security perimeter extends to every vendor that touches your data, systems, or networks. Data processors include SaaS applications, cloud providers, payroll services, and analytics platforms. Technology vendors encompass software suppliers, hardware manufacturers, and managed service providers. Business partners include supply chain partners, consultants, and legal and accounting firms. Infrastructure providers cover hosting providers, CDNs, DNS services, and certificate authorities.
A breach at any of these vendors can expose your data, disrupt your operations, or provide attackers with a pathway into your environment. PwC’s 2025 Global Digital Trust Insights found that 35% of directors rank third-party breaches among their top three cyber threats.
TPRM Lifecycle
Phase 1: Vendor Identification and Inventory
You cannot manage risk you haven’t identified. Maintain a complete, current inventory of all third-party relationships.
Inventory requirements:
| Field | Purpose |
|---|---|
| Vendor name and primary contact | Communication and accountability |
| Data shared/accessed | Understand exposure scope |
| System access level | Network, application, API, physical |
| Business criticality | Prioritize assessment and monitoring |
| Contract dates and terms | Track renewal and reassessment triggers |
| Security certifications | SOC 2, ISO 27001, PCI DSS, HITRUST |
| Last assessment date | Ensure ongoing oversight |
Vendor tiering:
| Tier | Criteria | Assessment Level |
|---|---|---|
| Critical | Access to sensitive data, production systems, or customer-facing services | Full security assessment, continuous monitoring, on-site review |
| High | Access to internal data or non-production systems | Detailed questionnaire, evidence review, periodic monitoring |
| Medium | Limited data access, no system access | Standard questionnaire, certification review |
| Low | No data or system access | Self-attestation, minimal review |
Phase 2: Risk Assessment
Assessment Methods
Security questionnaires like SIG (Standardized Information Gathering) and SIG Lite are industry-standard questionnaires from Shared Assessments covering 18 risk domains. CAIQ (Consensus Assessment Initiative Questionnaire) is a cloud-specific assessment from the Cloud Security Alliance. Supplement standardized questionnaires with organization-specific questions through custom questionnaires.
Questionnaires provide baseline understanding but are self-reported, and vendors will not voluntarily disclose weaknesses.
Evidence-based assessment involves requesting and reviewing SOC 2 Type II reports (which cover a period, not a point in time), reviewing penetration test reports and remediation evidence, validating ISO 27001 certification scope to ensure it covers the services you consume, and requesting incident history to understand how many security incidents occurred in the past 24 months and how they were handled.
Technical assessment includes external attack surface scanning (SecurityScorecard, BitSight, UpGuard), API security testing if the vendor provides APIs you consume, and configuration review for SaaS platforms (access controls, MFA enforcement, logging).
Risk Scoring
Develop a consistent risk scoring framework:
| Risk Factor | Weight | Data Source |
|---|---|---|
| Data sensitivity | High | Internal classification |
| Access level | High | Vendor inventory |
| Security maturity | High | Assessment results, certifications |
| Incident history | Medium | Assessment, breach databases, news monitoring |
| Financial stability | Medium | Credit reports, news monitoring |
| Geographic risk | Medium | Data residency, regulatory environment |
| Dependency concentration | Medium | How many critical services does this vendor provide? |
Phase 3: Contractual Controls
Contracts are your primary enforcement mechanism for vendor security requirements.
Essential contractual clauses include security requirements (minimum security controls the vendor must maintain such as encryption, MFA, and patching SLAs), incident notification (vendor must notify within 24-72 hours of a security incident affecting your data, noting SEC Regulation S-P mandates 72-hour notification from service providers), right to audit (authority to conduct security assessments or request evidence), data handling (classification, encryption, retention, and destruction requirements), subprocessor management (vendor must notify of and manage risks from their own third parties), termination and data return (procedures for secure data return or destruction at end of relationship), liability and indemnification (allocation of responsibility for breach costs), and compliance obligations (specific regulatory requirements the vendor must meet).
Phase 4: Continuous Monitoring
Point-in-time assessments miss the 364 days between annual reviews. Continuous monitoring fills this gap.
Automated monitoring uses external attack surface scoring through SecurityScorecard, BitSight, UpGuard, or RiskRecon to provide real-time risk scores based on external scanning. Breach monitoring tracks vendor appearances in breach databases, dark web forums, and news. Certificate monitoring tracks vendor TLS certificate validity and configuration. DNS and domain monitoring detects suspicious changes to vendor infrastructure.
Periodic reviews should reassess critical vendors at minimum annually and after significant changes. Trigger reassessment on contract renewal, scope expansion, reported breach, or significant organizational change (acquisition, leadership turnover). Review SOC 2 reports annually to verify that findings are addressed and controls are operating effectively.
Vendor communication involves establishing regular security review meetings with critical vendors (quarterly recommended), requesting notification of significant security changes (architecture, personnel, subprocessors), and sharing threat intelligence relevant to the vendor’s service (industry-specific campaigns, targeted threats).
Phase 5: Incident Response for Third-Party Breaches
When a vendor is breached, your response must be fast despite limited visibility into the vendor’s environment.
Immediate actions (0-24 hours) include confirming the scope (what data, systems, or access is potentially affected?), activating your IR plan with vendor breach-specific procedures, restricting or revoking vendor access until scope is understood, preserving logs of vendor activity in your environment, and notifying legal, compliance, and executive leadership.
Investigation (24-72 hours) involves working with the vendor to understand the timeline, root cause, and extent of compromise. Determine if your data was accessed, exfiltrated, or encrypted. Assess whether the vendor breach could have provided access to your internal systems. Begin regulatory impact assessment (notification obligations, disclosure requirements).
Recovery involves restoring vendor access only after receiving evidence of remediation. Monitor vendor access closely for 90 days post-incident. Update vendor risk score and tiering based on incident severity and response quality. Document lessons learned and update TPRM program accordingly.
Regulatory Requirements
SEC Regulation S-P (Effective December 2025)
For financial services entities, vendors must notify within 72 hours of incidents affecting customer data. Entities must have contractual clauses mandating this notification timeline. Security governance must include vendor oversight documentation.
SEC Cyber Incident Disclosure
Publicly traded companies must disclose material incidents within 4 business days. Third-party breaches that are material to the company require the same disclosure. Pre-incident vendor risk documentation demonstrates governance for materiality decisions.
Other Requirements
GDPR Article 28 requires data processor agreements with specific security obligations. HIPAA requires Business Associate Agreements (BAAs) for vendors handling PHI. PCI DSS 4.0 Requirement 12.8 covers managing and monitoring service provider compliance. NIST SP 800-161 Rev. 1 (C-SCRM) provides comprehensive supply chain risk management guidance integrating with NIST 800-53 and CSF.
TPRM Metrics
| Metric | Description | Target |
|---|---|---|
| Vendor inventory completeness | Percentage of active vendors in the TPRM inventory | 100% |
| Assessment coverage (critical) | Percentage of critical vendors with current assessments | 100% |
| Assessment coverage (all) | Percentage of all tiered vendors with current assessments | > 90% |
| Continuous monitoring coverage | Percentage of critical vendors with automated monitoring | 100% |
| Mean time to assess | Average days from vendor onboarding to completed assessment | < 30 days |
| Finding remediation rate | Percentage of assessment findings addressed by vendors | > 85% |
| Incident notification compliance | Percentage of vendor incidents reported within contractual SLA | > 95% |
Common Pitfalls
Questionnaire theater sends questionnaires without reviewing responses or validating evidence, providing compliance documentation but no actual risk reduction. One-and-done assessment assesses at onboarding and never revisits, even though vendor security posture changes over time. Ignoring nth-party risk overlooks that your vendor’s vendors (subprocessors) can compromise your data, meaning contractual controls must cascade. Equal treatment assesses all vendors with the same rigor regardless of risk tier, wasting resources on low-risk vendors and under-assessing critical ones. Having no teeth in contracts means security requirements without consequences for non-compliance are suggestions, not requirements.
Getting Started
- Inventory all vendors with data access or system connectivity, starting with known critical vendors
- Tier vendors by data sensitivity, access level, and business criticality
- Assess critical and high-tier vendors using SIG questionnaires supplemented by evidence review
- Implement contracts with security requirements, incident notification SLAs, and audit rights
- Deploy monitoring for critical vendors using SecurityScorecard, BitSight, or similar platforms
- Prepare vendor breach response procedures and test them with tabletop exercises