Third-party vendors are the most common initial access vector in enterprise breaches — not because attackers prefer them, but because they provide access to multiple targets from a single compromise. The SolarWinds SUNBURST campaign, the MOVEit Transfer zero-day exploitation in 2023, and the Kaseya VSA ransomware event demonstrated at scale what security teams have known for years: your security posture is only as strong as the weakest link in your vendor ecosystem.
For organizations subject to regulatory frameworks — NY DFS 23 NYCRR 500, HIPAA, CMMC, SOC 2, or Reg S-P — third-party risk management is not just a best practice. It is a specific, auditable obligation. Building a formal Third-Party Risk Management (TPRM) program is both a compliance necessity and a practical defense against supply-chain attacks.
Why Third-Party Risk Has Become Critical Infrastructure Risk
The scale of third-party breach exposure is now structural. Consider the precedents:
- SolarWinds (2020): A trojanized software update to SolarWinds Orion was pushed to approximately 18,000 organizations, giving nation-state actors (SVR) access to the networks of US government agencies, defense contractors, and Fortune 500 companies. The initial access was a trusted software vendor's update mechanism.
- Kaseya VSA (2021): In July 2021, REvil exploited a zero-day in Kaseya's VSA remote monitoring and management platform (CVE-2021-30116) to push ransomware through roughly 50-60 managed service providers, compromising an estimated 800 to 1,500 downstream businesses in a single coordinated event.
- MOVEit Transfer (2023): Cl0p exploited a SQL injection zero-day (CVE-2023-34362) in Progress Software's MOVEit Transfer application, ultimately compromising more than 2,700 organizations and exposing the data of nearly 96 million individuals — including US federal agencies, UK pension providers, and major financial institutions. The critical point: many victims had no direct relationship with MOVEit — they were compromised through vendors who used it.
These events share a common pattern: a trusted vendor relationship providing privileged access to networks or sensitive data, exploited to bypass the victim organization's own perimeter controls.
Vendor Tiering Methodology
Not all vendors present equal risk. A TPRM program's first operational step is building a vendor inventory and applying a tiering methodology that determines the level of due diligence required. Tiering is typically based on three dimensions: data access (what categories and volumes of sensitive data the vendor can access), system access (whether the vendor has direct, privileged, or remote access to production systems), and business criticality (what the operational impact of a vendor failure or breach would be).
Most organizations use a four-tier model:
- Critical (Tier 1): Vendors with privileged system access or access to large volumes of sensitive data, where a compromise would cause immediate, significant operational or compliance impact. Examples: managed security service providers, cloud hosting providers, core banking platforms, EHR vendors.
- High (Tier 2): Vendors with access to sensitive data or systems, where a compromise could cause meaningful harm. Examples: payroll processors, HR platforms, SaaS tools with SSO integration, legal counsel with client data access.
- Medium (Tier 3): Vendors with limited access to internal systems or non-sensitive data. Examples: marketing platforms, productivity tools without sensitive data, non-integrated SaaS tools.
- Low (Tier 4): Vendors with no access to sensitive data or internal systems. Examples: office supplies vendors, facilities services, non-digital service providers.
Due Diligence for Critical and High-Risk Vendors
For Tier 1 and Tier 2 vendors, due diligence should include: completion of a security questionnaire aligned to your regulatory framework (NIST 800-53, CIS Controls, or a custom questionnaire); review of current SOC 2 Type II reports with attention to Section IV (control test results, deviations, and exceptions); review of penetration test reports or executive summaries for the prior 12 months; verification of cyber insurance coverage including limits and sublimits; and review of the vendor's incident response and notification procedures.
Reading SOC 2 Section IV: What Actually Matters
Many organizations request SOC 2 Type II reports from vendors without knowing how to evaluate them. Section III of a SOC 2 report contains the auditor's opinion and the description of the vendor's system. Section IV contains the detailed testing results — the most operationally meaningful section. Look specifically for: the number and nature of deviations (exceptions where controls were not operating effectively); whether deviations were remediated during the audit period; any qualified opinion or emphasis of matter paragraphs in the auditor's report; and the scope of the assessment (ensuring it covers the systems processing your data).
Continuous Monitoring
Point-in-time assessments are insufficient for high-risk vendors. Continuous monitoring using external attack surface monitoring tools provides ongoing visibility into vendor security posture between formal assessments. BitSight and SecurityScorecard assign quantitative risk scores based on observed security signals — open vulnerabilities, botnet activity, TLS configuration, patching cadence, dark web intelligence. These scores are imperfect but provide an early warning signal when a vendor's security posture deteriorates.
Contract Security Requirements
Security requirements must be embedded in vendor contracts, not just assessed at onboarding. Key contractual provisions for Tier 1 and Tier 2 vendors include: right-to-audit clauses permitting security assessment of the vendor's environment; incident notification requirements (typically requiring notice within 24-72 hours of a confirmed breach affecting your data); data handling and retention requirements; subprocessor notification obligations; and specific security control requirements (encryption at rest and in transit, MFA for vendor staff accessing your systems, background checks for personnel with system access).
NYDFS 500 Third-Party Provider Requirements
Under 23 NYCRR 500.11 (as amended in the 2023 amendments), covered entities must implement written policies and procedures governing the cybersecurity practices of third-party service providers. Requirements include: security risk assessments of all third-party service providers prior to onboarding; minimum cybersecurity practices required by contract; periodic reassessment based on risk; and immediate notice requirements when a third-party provider suffers a cybersecurity event affecting the covered entity's data.
If your organization is building or maturing a TPRM program, Fortress MSSP can assist with vendor tier assessments, security questionnaire design, SOC 2 report review, and penetration testing of vendor-connected interfaces. A virtual CISO engagement can own the TPRM program design and governance. Contact us to discuss your vendor risk program.