Opening Framing
Modern organizations don't operate in isolation. Cloud providers host infrastructure, SaaS applications process data, contractors access systems, and supply chains span the globe. Each third-party relationship extends your attack surface and introduces risk you don't directly control. Some of the largest breaches—Target, SolarWinds, Kaseya—originated through third parties.
Third-party risk management (TPRM) provides systematic processes for identifying, assessing, and managing risks from external relationships. It covers the full lifecycle: due diligence before engagement, contractual protections, ongoing monitoring, and termination procedures. Effective TPRM balances thoroughness with practicality—you can't assess every vendor like a critical cloud provider, but you can't ignore risk either.
This week covers third-party risk identification, vendor assessment approaches, contractual security requirements, ongoing monitoring, and incident management with third parties. You'll learn to build practical TPRM programs that protect the organization while enabling business relationships.
Key insight: You can outsource the work, but you can't outsource the accountability.
1) Third-Party Risk Landscape
Understanding the scope and types of third-party relationships is the foundation of TPRM:
Third-Party Categories:
TYPES OF THIRD PARTIES:
┌─────────────────────────────────────────────────────────────┐
│ Service Providers: │
│ - Cloud infrastructure (AWS, Azure, GCP) │
│ - SaaS applications (Salesforce, Workday, Slack) │
│ - Managed services (MSP, MSSP) │
│ - Professional services (consultants, auditors) │
│ - Business process outsourcing (payroll, HR) │
│ │
│ Technology Vendors: │
│ - Software vendors (licensed software) │
│ - Hardware vendors (equipment, devices) │
│ - Development tools and libraries │
│ - Open source components │
│ │
│ Business Partners: │
│ - Joint ventures │
│ - Channel partners and resellers │
│ - Integration partners │
│ - Data sharing partners │
│ │
│ Supply Chain: │
│ - Manufacturing suppliers │
│ - Logistics providers │
│ - Raw material suppliers │
│ │
│ Contractors and Contingent Workers: │
│ - Individual contractors │
│ - Staffing agencies │
│ - Offshore development teams │
└─────────────────────────────────────────────────────────────┘
THIRD-PARTY RISK TYPES:
┌─────────────────────────────────────────────────────────────┐
│ Security Risk: │
│ - Data breach through vendor │
│ - Compromised vendor as attack vector │
│ - Inadequate vendor security controls │
│ - Shared infrastructure vulnerabilities │
│ │
│ Privacy Risk: │
│ - Unauthorized data use │
│ - Non-compliant data handling │
│ - Cross-border data transfers │
│ - Data retention violations │
│ │
│ Operational Risk: │
│ - Vendor service outages │
│ - Vendor business failure │
│ - Performance degradation │
│ - Vendor lock-in │
│ │
│ Compliance Risk: │
│ - Vendor non-compliance affecting your compliance │
│ - Regulatory violations through vendor │
│ - Audit failures due to vendor issues │
│ │
│ Reputational Risk: │
│ - Association with vendor incidents │
│ - Customer trust affected by vendor issues │
│ │
│ Concentration Risk: │
│ - Over-reliance on single vendor │
│ - Multiple critical services from one provider │
│ - Geographic concentration │
│ │
│ Fourth-Party Risk (Nth-Party): │
│ - Your vendor's vendors │
│ - Subcontractors and sub-processors │
│ - Supply chain depth │
└─────────────────────────────────────────────────────────────┘Third-Party Risk Examples:
Notable Third-Party Incidents:
SUPPLY CHAIN ATTACKS:
┌─────────────────────────────────────────────────────────────┐
│ SolarWinds (2020): │
│ - Attackers compromised software build process │
│ - Malicious code distributed via legitimate updates │
│ - 18,000+ organizations affected │
│ - Included government agencies and major corporations │
│ - Lesson: Software supply chain is critical attack vector │
│ │
│ Kaseya (2021): │
│ - Attackers exploited vulnerability in Kaseya VSA │
│ - MSPs using Kaseya spread ransomware to their customers │
│ - 800-1,500 businesses affected │
│ - Lesson: MSP compromise multiplies impact │
│ │
│ Log4j (2021): │
│ - Critical vulnerability in widely-used logging library │
│ - Present in thousands of applications │
│ - Organizations didn't know they used it │
│ - Lesson: Know your dependencies (SBOM) │
└─────────────────────────────────────────────────────────────┘
VENDOR DATA BREACHES:
┌─────────────────────────────────────────────────────────────┐
│ Target (2013): │
│ - Attackers entered through HVAC vendor │
│ - Vendor had network access for billing │
│ - 40 million payment cards compromised │
│ - Lesson: Vendor access must be controlled and segmented │
│ │
│ Accellion (2021): │
│ - File transfer appliance vulnerabilities exploited │
│ - Multiple organizations breached through same vendor │
│ - Healthcare, government, education affected │
│ - Lesson: Legacy vendor systems are attractive targets │
└─────────────────────────────────────────────────────────────┘Key insight: Third-party risk is often underestimated because the connection isn't obvious until an incident occurs.
2) Vendor Risk Assessment
Risk-based vendor assessment ensures appropriate due diligence based on risk level:
Vendor Tiering:
RISK-BASED CLASSIFICATION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TIER 1 - CRITICAL: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Characteristics: │ │
│ │ - Access to sensitive/regulated data │ │
│ │ - Critical to business operations │ │
│ │ - Difficult to replace │ │
│ │ - Direct system integration │ │
│ │ │ │
│ │ Examples: │ │
│ │ - Cloud infrastructure providers │ │
│ │ - Payment processors │ │
│ │ - Core business SaaS │ │
│ │ - Data processing partners │ │
│ │ │ │
│ │ Assessment: Full due diligence, on-site if needed │ │
│ │ Frequency: Annual reassessment + continuous monitoring │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ TIER 2 - HIGH: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Characteristics: │ │
│ │ - Access to internal data (not highly sensitive) │ │
│ │ - Important but not critical operations │ │
│ │ - Replaceable with moderate effort │ │
│ │ - Network or system access │ │
│ │ │ │
│ │ Examples: │ │
│ │ - HR systems │ │
│ │ - Email/collaboration platforms │ │
│ │ - IT support providers │ │
│ │ │ │
│ │ Assessment: Detailed questionnaire + documentation │ │
│ │ Frequency: Annual or biennial reassessment │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ TIER 3 - MODERATE: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Characteristics: │ │
│ │ - Limited data access │ │
│ │ - Not operationally critical │ │
│ │ - Easily replaceable │ │
│ │ - No direct system access │ │
│ │ │ │
│ │ Examples: │ │
│ │ - Marketing tools │ │
│ │ - Office supplies vendors │ │
│ │ - Training providers │ │
│ │ │ │
│ │ Assessment: Standard questionnaire │ │
│ │ Frequency: Every 2-3 years or risk-triggered │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ TIER 4 - LOW: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Characteristics: │ │
│ │ - No data access │ │
│ │ - No system access │ │
│ │ - Transactional relationship │ │
│ │ │ │
│ │ Examples: │ │
│ │ - Catering services │ │
│ │ - Cleaning services │ │
│ │ - General contractors │ │
│ │ │ │
│ │ Assessment: Basic verification only │ │
│ │ Frequency: As needed │ │
│ └─────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
TIERING CRITERIA:
┌─────────────────────────────────────────────────────────────┐
│ Factor │ Weight │ Scoring │
│ ──────────────────────────┼────────┼───────────────────────│
│ Data sensitivity │ High │ 1-5 based on class │
│ Data volume │ Medium │ 1-5 based on records │
│ System access level │ High │ 1-5 based on privilege│
│ Business criticality │ High │ 1-5 based on impact │
│ Replaceability │ Medium │ 1-5 (5=hard to replace│
│ Regulatory scope │ High │ 1-5 based on regs │
│ Geographic considerations │ Medium │ 1-5 based on location │
│ │
│ Calculate weighted score to determine tier │
└─────────────────────────────────────────────────────────────┘Assessment Methods:
Vendor Assessment Approaches:
ASSESSMENT METHODS BY TIER:
┌─────────────────────────────────────────────────────────────┐
│ Tier 1 (Critical): │
│ - Detailed security questionnaire (200+ questions) │
│ - Request SOC 2 Type II or ISO 27001 certificate │
│ - Review penetration test results │
│ - On-site assessment (if warranted) │
│ - Architecture/security review │
│ - Business continuity review │
│ - Financial stability assessment │
│ - Reference checks │
│ │
│ Tier 2 (High): │
│ - Standard security questionnaire (100+ questions) │
│ - Request SOC 2 or equivalent attestation │
│ - Review security certifications │
│ - Documentation review │
│ │
│ Tier 3 (Moderate): │
│ - Abbreviated questionnaire (30-50 questions) │
│ - Accept industry certifications as evidence │
│ - Basic due diligence │
│ │
│ Tier 4 (Low): │
│ - Basic business verification │
│ - Standard contract terms │
└─────────────────────────────────────────────────────────────┘
SECURITY QUESTIONNAIRE DOMAINS:
┌─────────────────────────────────────────────────────────────┐
│ 1. Governance and Risk Management │
│ - Security policies and procedures │
│ - Risk assessment process │
│ - Security organization and responsibility │
│ - Compliance certifications │
│ │
│ 2. Access Control │
│ - Identity management │
│ - Authentication mechanisms │
│ - Authorization and least privilege │
│ - Privileged access management │
│ │
│ 3. Data Protection │
│ - Data classification │
│ - Encryption (at rest and in transit) │
│ - Data retention and disposal │
│ - Data loss prevention │
│ │
│ 4. Network Security │
│ - Network architecture │
│ - Segmentation │
│ - Firewall and perimeter controls │
│ - Remote access │
│ │
│ 5. Security Operations │
│ - Vulnerability management │
│ - Patch management │
│ - Logging and monitoring │
│ - Security incident response │
│ │
│ 6. Business Continuity │
│ - Backup and recovery │
│ - Disaster recovery │
│ - Business continuity planning │
│ - Redundancy and resilience │
│ │
│ 7. Physical Security │
│ - Data center security │
│ - Office security │
│ - Environmental controls │
│ │
│ 8. Human Resources Security │
│ - Background checks │
│ - Security awareness training │
│ - Termination procedures │
│ │
│ 9. Third-Party Management │
│ - Subcontractor oversight │
│ - Fourth-party risk │
│ - Supply chain security │
│ │
│ 10. Privacy │
│ - Privacy program │
│ - Data subject rights │
│ - Cross-border transfers │
│ - Regulatory compliance │
└─────────────────────────────────────────────────────────────┘
USING ATTESTATION REPORTS:
┌─────────────────────────────────────────────────────────────┐
│ SOC 2 Type II Report Review: │
│ │
│ Key sections to review: │
│ - Opinion (unqualified = good) │
│ - Scope (services covered, criteria included) │
│ - Description of system │
│ - Control activities │
│ - Test results (any exceptions?) │
│ - Complementary user entity controls (CUECs) │
│ - Subservice organizations │
│ │
│ Red flags: │
│ - Qualified opinion │
│ - Many exceptions in testing │
│ - Narrow scope that doesn't cover your use │
│ - Old report (should be <12 months) │
│ - Bridge letter needed to cover gap │
│ │
│ Don't forget: │
│ - Review CUECs - these are YOUR responsibilities │
│ - Check subservice organizations - are they carved out? │
└─────────────────────────────────────────────────────────────┘Key insight: Scale assessment effort to risk. Spending months assessing a low-risk vendor wastes resources better spent on critical ones.
3) Contractual Security Requirements
Contracts establish legally enforceable security obligations:
Security Contract Terms:
ESSENTIAL CONTRACT PROVISIONS:
┌─────────────────────────────────────────────────────────────┐
│ Data Protection: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ - Define what data vendor will access/process │ │
│ │ - Specify permitted uses and prohibitions │ │
│ │ - Require encryption standards │ │
│ │ - Specify data location requirements │ │
│ │ - Define retention and deletion requirements │ │
│ │ - Restrict subprocessing without approval │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ Security Requirements: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ - Require specific security controls │ │
│ │ - Reference security standards (ISO, SOC 2) │ │
│ │ - Require security certifications │ │
│ │ - Mandate vulnerability management │ │
│ │ - Require security awareness training │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ Audit Rights: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ - Right to audit vendor security │ │
│ │ - Right to request security assessments │ │
│ │ - Right to review SOC reports and certifications │ │
│ │ - Frequency and notice requirements │ │
│ │ - Cost allocation │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ Incident Response: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ - Breach notification timeline (e.g., 24-72 hours) │ │
│ │ - Information to be provided │ │
│ │ - Cooperation requirements │ │
│ │ - Responsibility for notification costs │ │
│ │ - Forensic investigation rights │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ Business Continuity: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ - Service level agreements (SLAs) │ │
│ │ - Uptime requirements │ │
│ │ - Disaster recovery capabilities │ │
│ │ - RPO/RTO commitments │ │
│ │ - Penalties for SLA breaches │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ Termination: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ - Data return procedures │ │
│ │ - Data destruction requirements │ │
│ │ - Certification of destruction │ │
│ │ - Transition assistance │ │
│ │ - Termination for security cause │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ Liability and Indemnification: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ - Security breach liability │ │
│ │ - Indemnification for vendor negligence │ │
│ │ - Liability caps (negotiate carefully) │ │
│ │ - Insurance requirements │ │
│ └─────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘Data Processing Agreements:
DPA Requirements (GDPR-style):
DATA PROCESSING AGREEMENT:
┌─────────────────────────────────────────────────────────────┐
│ Required when vendor processes personal data on your behalf │
│ │
│ Must include (GDPR Article 28): │
│ │
│ 1. Subject matter and duration of processing │
│ 2. Nature and purpose of processing │
│ 3. Type of personal data and categories of data subjects │
│ 4. Controller's obligations and rights │
│ │
│ Processor must: │
│ - Process only on documented instructions │
│ - Ensure personnel confidentiality │
│ - Implement appropriate security measures │
│ - Obtain approval for sub-processors │
│ - Assist controller with data subject rights │
│ - Assist with compliance obligations │
│ - Delete or return data at end of services │
│ - Allow and contribute to audits │
└─────────────────────────────────────────────────────────────┘
BUSINESS ASSOCIATE AGREEMENT (HIPAA):
┌─────────────────────────────────────────────────────────────┐
│ Required when vendor creates, receives, maintains, or │
│ transmits PHI on behalf of covered entity │
│ │
│ Must include: │
│ - Permitted uses and disclosures of PHI │
│ - Requirement for appropriate safeguards │
│ - Reporting requirements for breaches │
│ - Requirement to ensure subcontractor compliance │
│ - Access to PHI for covered entity │
│ - Return or destruction of PHI at termination │
│ - Agreement to comply with Security Rule │
└─────────────────────────────────────────────────────────────┘
CONTRACT NEGOTIATION PRIORITIES:
┌─────────────────────────────────────────────────────────────┐
│ High Priority (don't compromise): │
│ - Breach notification timeframes │
│ - Audit rights │
│ - Data handling and deletion │
│ - Subcontractor restrictions │
│ │
│ Medium Priority (negotiate best terms): │
│ - Specific security controls │
│ - SLA terms │
│ - Liability caps │
│ - Insurance minimums │
│ │
│ Lower Priority (accept reasonable terms): │
│ - Audit notice periods │
│ - Minor procedural details │
│ - Standard legal boilerplate │
│ │
│ Note: Leverage varies by vendor size and relationship │
│ Large vendors may have non-negotiable terms │
└─────────────────────────────────────────────────────────────┘Key insight: Get security requirements in the contract before signing—it's much harder to add them later.
4) Ongoing Vendor Monitoring
Initial assessment isn't enough—vendor risk changes over time:
Continuous Vendor Monitoring:
MONITORING ACTIVITIES:
┌─────────────────────────────────────────────────────────────┐
│ Periodic Reassessment: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ - Annual security questionnaire update │ │
│ │ - Review updated SOC reports/certifications │ │
│ │ - Assess changes since last review │ │
│ │ - Verify remediation of previous findings │ │
│ │ │ │
│ │ Frequency by tier: │ │
│ │ - Tier 1: Annual │ │
│ │ - Tier 2: Annual to biennial │ │
│ │ - Tier 3: Every 2-3 years │ │
│ │ - Tier 4: As triggered │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ Continuous Monitoring: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ - Security rating services (BitSight, SecurityScorecard)│ │
│ │ - Threat intelligence feeds │ │
│ │ - Dark web monitoring for vendor mentions │ │
│ │ - News monitoring for vendor incidents │ │
│ │ - Financial health monitoring │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ Performance Monitoring: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ - SLA tracking and reporting │ │
│ │ - Incident tracking │ │
│ │ - Service quality metrics │ │
│ │ - User feedback/complaints │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ Contract Monitoring: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ - Certification expiration tracking │ │
│ │ - Contract renewal dates │ │
│ │ - Insurance certificate expiration │ │
│ │ - Compliance requirement changes │ │
│ └─────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
SECURITY RATING SERVICES:
┌─────────────────────────────────────────────────────────────┐
│ External security ratings provide ongoing visibility: │
│ │
│ What they measure: │
│ - External vulnerability exposure │
│ - Email security configuration │
│ - Web application security │
│ - DNS security │
│ - Patching cadence │
│ - Network security │
│ - Data leak exposure │
│ │
│ Benefits: │
│ - Continuous, automated monitoring │
│ - No vendor cooperation required │
│ - Benchmark against peers │
│ - Alert on changes │
│ │
│ Limitations: │
│ - External view only (can't see internal controls) │
│ - May not reflect actual security posture │
│ - False positives/negatives possible │
│ - Should supplement, not replace, assessments │
│ │
│ Major providers: BitSight, SecurityScorecard, RiskRecon, │
│ UpGuard, Panorays │
└─────────────────────────────────────────────────────────────┘
TRIGGER-BASED REASSESSMENT:
┌─────────────────────────────────────────────────────────────┐
│ Reassess vendors when: │
│ │
│ - Vendor experiences security incident │
│ - Significant change in vendor services │
│ - Vendor acquisition or major organizational change │
│ - Significant drop in security rating │
│ - Change in data access or scope │
│ - Regulatory change affecting vendor │
│ - Contract renewal approaching │
│ - Audit findings related to vendor │
│ - Negative news or industry alerts │
│ - Financial distress indicators │
└─────────────────────────────────────────────────────────────┘Vendor Risk Dashboard:
TPRM Dashboard Metrics:
PORTFOLIO VIEW:
┌─────────────────────────────────────────────────────────────┐
│ Total Vendors: 247 │
│ │
│ By Tier: By Risk Rating: By Assessment Status:│
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │
│ │ Tier 1: 12 │ │ Critical: 3 │ │ Current: 198 │ │
│ │ Tier 2: 35 │ │ High: 15 │ │ Due Soon: 28 │ │
│ │ Tier 3: 78 │ │ Medium: 45 │ │ Overdue: 21 │ │
│ │ Tier 4: 122 │ │ Low: 184 │ │ │ │
│ └──────────────┘ └──────────────┘ └──────────────────┘ │
│ │
│ Vendors with Open Findings: 18 │
│ Vendors with Expiring Certifications (90 days): 7 │
│ Contracts Expiring (90 days): 12 │
└─────────────────────────────────────────────────────────────┘
KEY METRICS TO TRACK:
┌─────────────────────────────────────────────────────────────┐
│ Coverage Metrics: │
│ - % vendors assessed │
│ - % critical vendors with current assessment │
│ - % vendors with executed contracts │
│ - % vendors with required certifications │
│ │
│ Risk Metrics: │
│ - Distribution by risk tier │
│ - Vendors exceeding risk threshold │
│ - Risk trend over time │
│ - Concentration risk (vendors per critical function) │
│ │
│ Operational Metrics: │
│ - Time to complete assessments │
│ - Assessment backlog │
│ - Finding remediation rates │
│ - Vendor incidents │
└─────────────────────────────────────────────────────────────┘Key insight: Monitoring catches changes between assessments— a vendor's security posture today may differ from last year's assessment.
5) Vendor Incident Management
When vendors have security incidents, your response must be coordinated:
Vendor Incident Response:
VENDOR INCIDENT PROCESS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ VENDOR INCIDENT DETECTED │ │
│ │ (notification, news, monitoring, customer report) │ │
│ └──────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ INITIAL ASSESSMENT │ │
│ │ - Determine if your data/systems affected │ │
│ │ - Identify scope of vendor relationship │ │
│ │ - Assess potential impact │ │
│ └──────────────────────────────────────────────────────┘ │
│ │ │
│ ┌─────────────┴─────────────┐ │
│ │ │ │
│ ▼ ▼ │
│ ┌────────────┐ ┌────────────┐ │
│ │ AFFECTED │ │NOT AFFECTED│ │
│ └─────┬──────┘ └─────┬──────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ Activate IR plan │ │ Document and │ │
│ │ Engage vendor │ │ monitor │ │
│ │ Contain impact │ │ │ │
│ └────────┬─────────┘ └──────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ COORDINATE WITH VENDOR │ │
│ │ - Obtain incident details │ │
│ │ - Understand data/system exposure │ │
│ │ - Get timeline of events │ │
│ │ - Receive remediation plans │ │
│ └──────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ DETERMINE OBLIGATIONS │ │
│ │ - Customer notification requirements │ │
│ │ - Regulatory notification requirements │ │
│ │ - Internal stakeholder communication │ │
│ │ - Insurance notification │ │
│ └──────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ EXECUTE RESPONSE │ │
│ │ - Implement containment measures │ │
│ │ - Issue required notifications │ │
│ │ - Coordinate with legal counsel │ │
│ │ - Manage communications │ │
│ └──────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ POST-INCIDENT │ │
│ │ - Verify vendor remediation │ │
│ │ - Assess vendor relationship │ │
│ │ - Document lessons learned │ │
│ │ - Update vendor risk assessment │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘Vendor Incident Playbook:
Vendor Incident Playbook:
INFORMATION TO OBTAIN FROM VENDOR:
┌─────────────────────────────────────────────────────────────┐
│ Initial Questions: │
│ - What happened and when? │
│ - What data/systems were affected? │
│ - Was our data/access involved? │
│ - What is the scope of impact? │
│ - Is the incident contained? │
│ │
│ Detail Questions: │
│ - What specific data elements were exposed? │
│ - How many records affected? │
│ - What was the attack vector? │
│ - What is the timeline of events? │
│ - What has been done to contain/remediate? │
│ - What is the remediation plan? │
│ - When will we receive a written incident report? │
│ - What are you doing to prevent recurrence? │
│ │
│ For Breaches Involving Your Data: │
│ - Detailed data inventory of exposed records │
│ - Evidence preservation for investigation │
│ - Forensic report (when available) │
│ - Documentation for regulatory notifications │
└─────────────────────────────────────────────────────────────┘
COMMUNICATION TEMPLATES:
┌─────────────────────────────────────────────────────────────┐
│ Initial Vendor Inquiry: │
│ ───────────────────────────────────────────────────────────│
│ Subject: Security Incident Inquiry - [Vendor Name] │
│ │
│ We have become aware of a potential security incident │
│ affecting [vendor name]. As [vendor] processes data on │
│ our behalf, please provide the following: │
│ │
│ 1. Confirmation of incident scope │
│ 2. Whether our data/systems are affected │
│ 3. Timeline of events │
│ 4. Current containment status │
│ 5. Point of contact for further coordination │
│ │
│ Please respond within [24 hours/timeframe per contract]. │
│ ───────────────────────────────────────────────────────────│
│ │
│ Executive Briefing: │
│ ───────────────────────────────────────────────────────────│
│ - Vendor: [Name] │
│ - Incident Type: [Brief description] │
│ - Our Exposure: [Affected/Not Affected/Investigating] │
│ - Data at Risk: [Types and volumes] │
│ - Business Impact: [Assessment] │
│ - Actions Taken: [List] │
│ - Notification Obligations: [Status] │
│ - Next Steps: [Plan] │
└─────────────────────────────────────────────────────────────┘
POST-INCIDENT VENDOR ASSESSMENT:
┌─────────────────────────────────────────────────────────────┐
│ After vendor incident, evaluate: │
│ │
│ - Did vendor notify us per contract requirements? │
│ - Did vendor cooperate appropriately? │
│ - Were root causes addressed? │
│ - Has vendor implemented adequate remediation? │
│ - Should we continue the relationship? │
│ - Should we adjust vendor tier/monitoring? │
│ - Are contract amendments needed? │
│ - Should we invoke contract termination rights? │
│ │
│ Document decision and rationale │
└─────────────────────────────────────────────────────────────┘Key insight: Your breach notification obligations don't disappear because a vendor caused the breach—plan for how you'll respond to vendor incidents.
Real-World Context
Case Study: Vendor Assessment at Scale
A financial services firm discovered they had 3,000+ vendors but only 50 had ever been security assessed. They implemented a risk-based TPRM program: automated vendor inventory from procurement systems, risk tiering based on data access and criticality, differentiated assessment approaches by tier, and continuous monitoring via security ratings. Within 18 months, all Tier 1 vendors were fully assessed, Tier 2 had standardized questionnaires, and they had visibility into critical vendor security posture. A key success factor: they accepted SOC 2 reports instead of custom questionnaires for vendors that had them, reducing vendor fatigue.
Case Study: Vendor Incident Response
When a major cloud provider experienced an outage affecting thousands of customers, one organization's TPRM program enabled rapid response: they immediately knew which business processes depended on that provider, had vendor contact information readily available, had contractual SLAs to reference, and could assess business impact within hours. Organizations without TPRM spent days determining if they were affected and whom to contact. The prepared organization activated their BCP, communicated with customers proactively, and later held the vendor accountable for SLA breaches.
TPRM Quick Reference:
TPRM Checklist:
PROGRAM FOUNDATION:
□ Vendor inventory established
□ Tiering methodology defined
□ Assessment approaches by tier documented
□ Questionnaire templates created
□ Contract security requirements defined
□ Roles and responsibilities assigned
VENDOR ONBOARDING:
□ Risk tier assigned
□ Assessment completed per tier requirements
□ Findings addressed or accepted
□ Contract with security terms executed
□ DPA/BAA if required
□ Registered in vendor inventory
ONGOING MANAGEMENT:
□ Reassessment schedule maintained
□ Certifications tracked
□ Contract renewals monitored
□ Continuous monitoring in place
□ Findings tracked to remediation
INCIDENT PREPAREDNESS:
□ Vendor incident playbook exists
□ Contact information current
□ Notification requirements documented
□ Communication templates readyEffective TPRM isn't about assessing every vendor equally— it's about right-sizing effort to actual risk.
Guided Lab: TPRM Program
In this lab, you'll build a third-party risk management program from assessment through monitoring.
Lab Scenario:
- Healthcare technology company
- 100+ vendors, no formal TPRM program
- Subject to HIPAA, SOC 2 requirements
- Recent concern about cloud provider security
- Need to establish TPRM from scratch
Exercise Steps:
- Define vendor tiering methodology
- Create vendor inventory template
- Develop assessment questionnaire
- Design contract security addendum
- Create vendor risk register
- Design monitoring dashboard
- Develop vendor incident playbook
- Create TPRM policy
Reflection Questions:
- How would you prioritize assessing existing vendors?
- What challenges do you anticipate with vendor cooperation?
- How would you handle critical vendors that refuse assessment?
Week Outcome Check
By the end of this week, you should be able to:
- Identify and categorize third-party relationships
- Develop risk-based vendor tiering methodologies
- Conduct vendor security assessments
- Review and interpret SOC 2 reports
- Draft contractual security requirements
- Implement ongoing vendor monitoring
- Respond to vendor security incidents
- Build comprehensive TPRM programs
🎯 Hands-On Labs (Free & Essential)
Build third-party risk management programs with practical vendor assessment exercises.
🤝 Vendor Risk Assessment Lab
What you'll do: Conduct vendor security assessments—develop questionnaires,
analyze responses, score risk, make go/no-go decisions.
Why it matters: Third-party breaches are increasingly common—your vendors
are your attack surface.
Time estimate: 3-4 hours
📋 SIG Questionnaire Practice
What you'll do: Complete Standardized Information Gathering (SIG)
questionnaires—understand common vendor assessment formats.
Why it matters: SIG questionnaires are industry-standard for vendor
assessments.
Time estimate: 2-3 hours
🔍 Vendor Continuous Monitoring
What you'll do: Design vendor monitoring programs—establish KPIs, automate
tracking, respond to changes in vendor risk posture.
Why it matters: Point-in-time assessments miss ongoing risk
changes—continuous monitoring is essential.
Time estimate: 2-3 hours
💡 Lab Strategy: Risk-tier your vendors—focus deep assessments on high-risk, high-access vendors.
Resources
Lab
Complete the following lab exercises to practice TPRM concepts.