Explain the processes associated with third-party risk assessment and management

Your security is only as strong as your weakest vendor. Third-party risk management ensures that external relationships don’t create unmanaged attack surface.

Vendor Assessment

Due Diligence

Investigating a vendor’s security posture before entering a relationship.

• Review their security certifications (SOC 2, ISOInternational Organization for Standardization — Publishes ISO 27001/27002 security standards 27001)
• Request penetration test results or vulnerability scan summaries
• Evaluate their incident response history and disclosure practices
• Assess their financial stability (a vendor going bankrupt is a business continuity risk)

Vendor Questionnaires

Standardized sets of security questions sent to potential vendors.

• SIG (Standardized Information Gathering) questionnaire is a common framework
• Cover: access controls, encryption, incident response, data handling, compliance, subcontractors
• Limitation: Self-reported — trust but verify through audits and evidence requests

Right to Audit

Contractual provision allowing you to audit the vendor’s security controls.

• May include on-site assessments, evidence review, or third-party audit results
• Critical for high-risk vendors handling sensitive data

Evidence of Security

• SOC 2 Type II: Independent audit of security controls over time (6-12 months). Most commonly requested.
• SOC 2 Type I: Point-in-time assessment. Less valuable than Type II.
• ISOInternational Organization for Standardization — Publishes ISO 27001/27002 security standards 27001 certification: Demonstrates an Information Security Management System
• Penetration test reports: Evidence of proactive security testing
• Compliance certificates: PCI-DSSPayment Card Industry Data Security Standard — Credit card data protection standard, HIPAAHealth Insurance Portability and Accountability Act — US healthcare data protection law attestation, FedRAMP authorization

Agreements

Service Level Agreement (SLA)

Defines measurable performance expectations.

• Uptime guarantees (99.9%, 99.99%)
• Response times for incidents and support
• Penalties for non-compliance
• Security-relevant SLAs: Patch deployment timeframes, incident notification deadlines, backup/recovery metrics

Memorandum of Understanding (MOU)

Less formal than a contract. Documents mutual intent and expectations between organizations.

• Common between government agencies or partner organizations
• May or may not be legally binding depending on language

Memorandum of Agreement (MOA)

More specific than an MOUMemorandum of Understanding — Informal agreement documenting mutual intent. Documents agreed-upon terms and responsibilities.

• Typically includes specific deliverables and timelines
• More formal than MOUMemorandum of Understanding — Informal agreement documenting mutual intent, less comprehensive than a full contract

Master Service Agreement (MSA)

Overarching contract governing the overall relationship between organizations.

• Covers general terms, liability, dispute resolution
• Individual projects/services operate under the MSAMaster Service Agreement — Overarching contract governing a vendor relationship with specific statements of work (SOWStatement of Work — Specific project deliverables under an MSA)

Non-Disclosure Agreement (NDA)

Legal agreement preventing disclosure of confidential information.

• Mutual NDANon-Disclosure Agreement — Legal agreement preventing info disclosure: both parties agree not to disclose
• One-way NDANon-Disclosure Agreement — Legal agreement preventing info disclosure: one party discloses, the other agrees to protect
• Must be in place before sharing sensitive information during vendor evaluation

Business Partners Agreement (BPA)

Defines the relationship between business partners including responsibilities, profit sharing, and liability.

Data Processing Agreement (DPA)

Required under GDPRGeneral Data Protection Regulation — EU data privacy regulation when a data controller engages a data processor.

• Defines what data is processed, how, and under what protections
• Specifies data subject rights handling, breach notification requirements

Rules of Engagement

When engaging vendors for security assessments, penetration testing, or managed services, the rules of engagement define the boundaries:

Key Components

• Scope: What systems, networks, and data are in scope. What’s explicitly excluded.
• Timeline: Start and end dates, permitted testing windows (business hours only? 24/7?)
• Authorization: Written permission from asset owners. Legal cover for the testing party.
• Off-limits: Systems or actions that must not be touched (production databases, medical devices, ICSIndustrial Control System — Systems managing physical industrial processes/SCADASupervisory Control and Data Acquisition — Industrial control system for remote monitoring unless specifically authorized)
• Escalation procedures: What happens if a critical vulnerability is found mid-assessment. Who is called.
• Communication: Primary contacts, out-of-band communication methods, status reporting cadence.
• Liability and indemnification: Who is responsible if testing causes an outage or data loss.
• Data handling: How assessment data is stored, transmitted, and destroyed after engagement.

Why It Matters

Without clear rules of engagement, a pentester who brings down a production system is acting within what they thought was authorized scope. Ambiguity creates legal risk for both parties.

Statement of Work (SOW)

What It Contains

• Specific deliverables: What the vendor will produce (pentest report, remediation plan, scan results)
• Scope of work: Detailed description of tasks and activities
• Timeline and milestones: When deliverables are due
• Resource requirements: Who from each side is involved
• Acceptance criteria: How deliverables are evaluated and accepted
• Pricing and payment terms: Fixed-fee, T&M, milestone-based

SOW vs. MSA

• MSAMaster Service Agreement — Overarching contract governing a vendor relationship (Master Service Agreement): Governs the overall vendor relationship — liability, IPInternet Protocol — Network layer addressing and routing ownership, dispute resolution, termination clauses. Rarely changes.
• SOWStatement of Work — Specific project deliverables under an MSA: Governs a specific project or engagement under the MSAMaster Service Agreement — Overarching contract governing a vendor relationship. Changes with each engagement.
• One MSAMaster Service Agreement — Overarching contract governing a vendor relationship can have many SOWs underneath it.

Vendor Questionnaire Frameworks

Common Frameworks

Framework	Focus	Use Case
SIG (Standardized Information Gathering)	Comprehensive security assessment	General-purpose vendor evaluation
CAIQ (Consensus Assessments Initiative Questionnaire)	Cloud-specific security controls	CSA-aligned, evaluating cloud/SaaSSoftware as a Service — Cloud: provider manages everything, you configure vendors
HECVAT	Higher education vendor risk	Universities evaluating EdTech vendors
NISTNational Institute of Standards and Technology — US standards body, publishes CSF and SP 800 series 800-171 self-assessment	Federal supply chain security	Vendors handling CUI (Controlled Unclassified Information)
Custom	Org-specific requirements	When standard frameworks don’t cover industry-specific needs

Best Practices

• Use a standardized framework — don’t reinvent the wheel each time
• Require evidence for critical responses (don’t just accept “yes” — ask for the policy/scan/cert)
• Weight responses by risk: a vendor handling PIIPersonally Identifiable Information — Data that can identify an individual gets scrutinized more than a vendor providing office supplies
• Reassess periodically, not just at onboarding

Independent Assessments

Third-party verification of a vendor’s security posture — more credible than self-reporting:

Assessment	What It Proves	Validity
SOC 2 Type II	Controls operating effectively over 6-12 months	Annual renewal
ISOInternational Organization for Standardization — Publishes ISO 27001/27002 security standards 27001	ISMS meets international standard	3-year certification, annual surveillance audits
FedRAMP	Meets federal cloud security requirements (NISTNational Institute of Standards and Technology — US standards body, publishes CSF and SP 800 series 800-53)	Continuous monitoring after ATO
HITRUST CSFCybersecurity Framework — NIST framework: Identify, Protect, Detect, Respond, Recover	Comprehensive health industry security framework	2-year certification
PCI-DSSPayment Card Industry Data Security Standard — Credit card data protection standard	Payment card data protection	Annual assessment or SAQ

Key point: Accept reports but read them. A SOC 2 with 15 exceptions is very different from one with zero. Look at the scope — a SOC 2 covering one product doesn’t mean the vendor’s entire operation is secure.

Supply Chain Analysis

Mapping Dependencies

• Identify all vendors and what they provide (not just technology — cleaning services have physical access too)
• Map data flows: which vendors touch sensitive data, where does it go, how is it protected
• Identify critical vendors: single points of failure where that vendor’s outage = your outage
• Map fourth-party relationships: your vendor’s vendors, especially for data processing

Critical Vendor Identification

A vendor is critical if any of these apply:

• They have access to sensitive/regulated data
• Their outage would stop your business operations
• They have privileged access to your systems
• They are the sole provider of a critical service (no alternative)
• Regulatory requirements flow through them (payment processing, healthcare data)

Critical vendors get: more frequent assessments, stricter SLAService Level Agreement — Measurable performance expectations with a vendor requirements, contractual right-to-audit, business continuity requirements, and exit/transition planning.

Supply Chain Risk

Vendor Dependency

Reliance on a vendor for critical services creates business continuity risk.

• What happens if the vendor has an outage, breach, or goes out of business?
• Mitigation: Multi-vendor strategies, contractual protections, exit planning

Fourth-Party Risk

Your vendor’s vendors. Their breach is your breach if they handle your data.

• SolarWinds attack: customers trusted SolarWinds, but the breach came through SolarWinds’ build process
• Require vendors to disclose and manage their own third-party relationships

Hardware Supply Chain

• Tampered hardware components (documented cases of firmware implants)
• Counterfeit components that may fail or contain backdoors
• Mitigation: Trusted suppliers, hardware integrity verification, chain of custody documentation

Software Supply Chain

• Compromised open-source dependencies (npm, PyPI malicious packages)
• Compromised update mechanisms (SolarWinds, Codecov, Kaseya)
• Mitigation: Software composition analysis (SCASoftware Composition Analysis — Identifying vulnerable third-party dependencies), vendor security assessment, code signing verification

Ongoing Monitoring

Vendor assessment isn’t one-and-done. Continuous monitoring includes:

• Regular reassessment (annual at minimum, more frequent for critical vendors)
• Monitoring vendor security posture changes (breach notifications, security rating services)
• Reviewing SLAService Level Agreement — Measurable performance expectations with a vendor compliance
• Tracking vendor access to your systems and data
• Offboarding procedures when relationships end (revoke access, retrieve data, confirm destruction)

Offensive Context

Supply chain attacks are among the most effective offensive techniques because they exploit trust relationships. Compromising a vendor with privileged access to multiple organizations is force multiplication — one breach yields many victims. SolarWinds, Kaseya, and Codecov demonstrated that even sophisticated organizations can be compromised through their vendors. Third-party risk management is the defensive response to supply chain offense — and it requires thinking about how an attacker would choose which vendor to target to maximize downstream access.