# Third-Party Risk Tiering and Assessment
Third-party risk tiering and assessment is the practice of categorizing vendors, suppliers, and service providers by the risk they represent to an organization's security posture, then applying proportionate due diligence, contractual requirements, and ongoing monitoring to each tier. It is how organizations scale vendor risk management across a vendor population that might number in the dozens, hundreds, or thousands.
The core insight is straightforward: not every vendor deserves the same level of scrutiny. A cloud provider with access to production databases containing millions of customer records represents fundamentally different risk than a catering company that services the office cafeteria. Treating both with the same assessment rigor wastes resources on low-risk relationships and, critically, produces so much assessment volume that the high-risk relationships receive diluted attention. Tiering solves this by making the depth of assessment proportionate to the severity of the potential impact.
Third-party risk is not hypothetical. The breach of a trusted vendor can be as damaging as a direct attack, often more so, because the vendor relationship carries implicit trust that security controls rely on. The 2020 SolarWinds compromise and the 2021 Kaseya ransomware attack are the defining case studies of how third-party risk can cascade through entire ecosystems, and both fundamentally changed how organizations think about vendor security management.
The first step in any third-party risk program is inventory. An organization must know who its vendors are before it can tier them. This sounds obvious but is frequently not done: shadow IT, departmental purchasing decisions, and subsidiary acquisitions all create vendor relationships that the security team may not be aware of. Vendor discovery involves cross-referencing accounts payable records, software license inventories, network traffic analysis, and business unit interviews.
Once the vendor population is identified, each vendor is tiered based on two dimensions: the sensitivity of data the vendor accesses (or could access) and the depth of the vendor's access to the organization's systems and networks. These two factors combine to produce a risk tier.
Critical tier vendors have direct access to the organization's most sensitive data or production systems. This category includes cloud infrastructure providers (AWS, Azure, GCP), SaaS platforms that process protected health information (PHI), personally identifiable information (PII), or financial data, managed security service providers (MSSPs), and any vendor with administrative or privileged access to production environments. A compromise of a Critical vendor has the potential to produce a significant breach or operational disruption with immediate notification obligations.
High tier vendors have access to internal networks or handle meaningful volumes of data that, while not the most sensitive, would create material harm if compromised. This includes IT vendors with network access, managed service providers (MSPs) serving desktop or server environments, development partners with code repository access, and integration vendors with API-level access to internal systems.
Medium tier vendors have limited system access and handle data of moderate sensitivity. Marketing automation platforms that hold contact lists, HR technology vendors that process employee records, and customer support tools with access to ticket data and limited account information fall here. The exposure from a Medium vendor compromise is real but constrained in scope.
Low tier vendors have no meaningful system access and handle no sensitive data. Facilities vendors, catering companies, office supply providers, and most professional services firms with no data sharing fall into this tier. Their risk is primarily reputational or compliance-related rather than data security-related.
Assessment methodology scales with the tier. Critical vendors receive annual SOC 2 Type II report review, completion of a Standardized Information Gathering (SIG) questionnaire, and continuous external monitoring through platforms such as BitSight, SecurityScorecard, or RiskRecon. High vendors receive SOC 2 Type II review and SIG questionnaire completion, typically on an annual cycle. Medium vendors complete an abbreviated questionnaire of 20 to 30 targeted questions aligned to the specific risk exposure. Low vendors provide annual self-attestation confirming no change in their data handling or system access profile.
Your attack surface does not end at your perimeter. Every vendor with access to your systems or data extends your attack surface into their environment. If their security controls fail, your data is exposed. If their infrastructure is compromised, the attacker may use that access to pivot into your network. If their availability fails, your operations may fail with it.
The SolarWinds incident is the most consequential third-party risk event in recent history. SolarWinds provided IT monitoring software to approximately 33,000 organizations, including U.S. government agencies and major enterprises. Attackers compromised SolarWinds' build pipeline and inserted a backdoor into a software update distributed to roughly 18,000 customers. The affected organizations had no direct vulnerability: they were compromised because they trusted a vendor that was itself compromised. The lesson is that the implicit trust granted to a Critical tier vendor (in this case, an IT monitoring platform with deep network visibility) can be weaponized at scale.
The Kaseya ransomware attack in July 2021 followed a similar pattern but cascaded through a different layer. Kaseya provided remote monitoring and management (RMM) software used by managed service providers. The attacker exploited a vulnerability in Kaseya's VSA platform to push ransomware through the MSP supply chain to approximately 1,500 end-customer organizations simultaneously. None of the 1,500 affected organizations had a direct relationship with the attacker. They were victims of their MSPs' vendor relationship with Kaseya.
Both incidents validate the same principle: a vendor's security posture is part of your attack surface, and Critical tier vendors deserve scrutiny proportionate to the damage their compromise could cause.
Beyond breach risk, third-party risk management is increasingly required by regulation. HIPAA Security Rule requires covered entities to execute Business Associate Agreements (BAAs) with vendors handling PHI. NYDFS Cybersecurity Regulation (23 NYCRR 500) requires financial institutions to implement third-party service provider security policies. GDPR Article 28 requires data processing agreements with all processors handling EU personal data. The SEC's cybersecurity disclosure rules create indirect pressure on public companies to understand and disclose material third-party risks.
The SIG Questionnaire (Standardized Information Gathering) is maintained by Shared Assessments and is the industry standard questionnaire for vendor security assessment. The full SIG covers 19 domain areas including security policy, access controls, change management, incident response, physical security, and privacy. For High tier vendors, the SIG Questionnaire is typically paired with a SOC 2 Type II report. The SIG Lite (an abbreviated version) is appropriate for Medium tier vendors. Shared Assessments updates the SIG annually to reflect current regulatory requirements and threat landscape changes.
SOC 2 Type II reports are the standard assurance mechanism for software and service vendors. A SOC 2 Type II report confirms that an independent auditor observed the vendor's controls operating effectively over a defined period (typically 6 to 12 months) against the AICPA Trust Services Criteria (security, availability, processing integrity, confidentiality, and privacy). The "Type II" designation (as opposed to Type I, which only confirms design adequacy at a point in time) is critical: it provides evidence of operational effectiveness, not just design intent. Critical and High tier vendors should provide current SOC 2 Type II reports as a baseline assessment artifact.
Continuous monitoring platforms provide ongoing third-party risk visibility between formal assessment cycles. BitSight, SecurityScorecard, and RiskRecon generate security ratings based on external signals observable without vendor cooperation: open ports and exposed services, DNS and TLS certificate issues, breach history and dark web exposure, botnet and malware associations, and patch cadence indicators from observed software version data. These signals do not provide the same depth as an internal audit, but they provide continuous visibility that annual assessments cannot. A sudden score drop for a Critical tier vendor is an early warning signal that warrants immediate outreach and verification.
Contract requirements for vendor relationships should be tiered alongside assessment requirements. All vendors, regardless of tier, should sign a data processing agreement defining data handling obligations and restrictions. For Critical and High tier vendors, contracts should include: incident notification requirements (typically 24 to 72 hours from discovery of a breach affecting the organization's data), right-to-audit provisions allowing the organization to request additional evidence or conduct on-site assessments, security cooperation obligations requiring the vendor to remediate identified vulnerabilities within defined timeframes, and subprocessor notification requirements obligating the vendor to inform the organization before engaging additional third parties with access to the organization's data.
Fourth-party risk is the emerging frontier: the risk introduced by the vendors of your vendors. If your Critical tier cloud provider uses a subprocessor with weak security, that subprocessor's compromise can affect your data without a direct relationship. SOC 2 Type II reports include subservice organization carve-outs that identify significant subprocessors; reviewing these carve-outs as part of the assessment process is increasingly considered a best practice.
Program governance requires ownership and defined processes. Typically, third-party risk management is a shared responsibility between information security, procurement or vendor management, and legal. The most effective programs integrate TPRM into the procurement process: no new vendor is onboarded without completing the appropriate tier assessment, and Critical tier vendor assessments require CISO or security leadership approval before contract execution.
Third-party risk is operationalized within CDA's Risk Governance and Assurance (RGA) domain through the Perpetual Compliance Assurance (PCA) methodology. PCA's continuous assurance model is directly applicable to vendor risk: the goal is not to assess vendors once a year and file the results, but to maintain continuous visibility into the security posture of the vendors who represent the most significant risk.
Mission RGA-R03, Vendor Risk Assessment, implements the tiered assessment framework as a standard component of CDA's RGA engagements. The mission scope includes vendor inventory and tier classification, assessment execution by tier, contract gap analysis, and continuous monitoring program design for Critical and High tier vendors. The output is a vendor risk register that feeds directly into the organization's broader risk register (RGA-R02), ensuring that third-party risk is visible alongside internal risk and prioritized with the same quantitative framework.
The SolarWinds and Kaseya incidents are foundational case studies in CDA's threat briefings and educational content for a specific reason: they illustrate that supply chain security is not a niche concern for large enterprises. Any organization that relies on software, managed services, or cloud infrastructure (which is every organization operating today) has a supply chain attack surface. The question is whether that surface is managed or ignored.
CDA's PDM framing positions supply chain risk through two lenses. Within RGA, vendor risk management is a governance and assurance function. But the Orbital Alliance Framework (OAF), one of CDA's cross-domain protocols, addresses the broader organizational dimension: how security obligations and risk management practices extend across organizational boundaries into supplier and partner relationships. OAF is relevant when the relationship is not just vendor-client but involves deep operational integration, shared infrastructure, or joint service delivery.
The practical guidance CDA provides for organizations building or maturing their TPRM programs: start with inventory (you cannot manage what you do not know), tier ruthlessly based on actual access and data sensitivity rather than vendor prominence, and build continuous monitoring for Critical vendors before expanding assessment rigor to lower tiers. The failure mode in most TPRM programs is over-investing in questionnaire completion for Low and Medium vendors while under-monitoring the Critical vendors whose compromise would be genuinely catastrophic. Tiering corrects this inversion.