Vendor tiering is the process of sorting vendors into a small number of risk tiers - typically critical, significant, and low - based on a fixed set of criteria, so that assessment depth, monitoring intensity, and reassessment cadence scale with actual exposure instead of being applied uniformly or by gut feel. Without it, a program either over-assesses low-risk vendors (burning scarce analyst time on a marketing tool with no data access) or under-assesses high-risk ones (giving a payroll processor the same light-touch review as a stock-photo subscription).
What tiering actually sorts on
Tiering criteria should describe the relationship, not the vendor's reputation or how well you happen to know them. The factors that hold up under audit are the same ones that define inherent risk: what the vendor can reach, not yet how well it's protected.
- Data sensitivity and volume. What kind of data the vendor can access - regulated personal data, payment data, source code, credentials - and how much of it.
- Operational dependency. What breaks, and how fast, if the vendor is unavailable. A vendor behind a core production dependency tiers higher than one behind an internal convenience tool, regardless of data sensitivity.
- Regulatory scope. Whether the vendor's function falls under a specific regime - a business associate touching PHI under HIPAA, a processor under GDPR Article 28, an ICT provider supporting a critical function under DORA.
- Integration depth and privileged access. Whether the vendor has standing credentials, API keys, or network access into your environment versus a one-way data export.
- Subprocessor chain and concentration exposure. How many further parties the vendor relies on, and whether it shares a subprocessor - a cloud region, an identity provider - with a large share of your other vendors. See concentration risk in the glossary.
Contract value and how long you've worked with a vendor are common substitutes for these criteria, and both are poor proxies: a low-spend API that authenticates every login is a materially different risk than a large invoice for an offline print vendor.
A practical three-tier model
Most defensible programs converge on three tiers rather than a finer-grained scale, because more tiers add administrative overhead without adding much decision quality. Each tier should carry a concrete, pre-agreed rule for assessment depth, monitoring, and reassessment - not just a label.
| Tier | Typical profile | Assessment depth | Ongoing treatment |
|---|---|---|---|
| Critical | High data sensitivity, deep integration or privileged access, operationally load-bearing, or in scope for a named regulatory regime | Full evidence-based assessment - SIG or equivalent questionnaire, SOC 2/ISO 27001 review, subprocessor mapping, contract review | Continuous monitoring plus scheduled re-assessment; any material signal triggers immediate re-review |
| Significant | Moderate data access or a standard SaaS tool with a defined, bounded data scope | Targeted questionnaire and certification review, scoped to the specific access granted | Periodic reassessment on a fixed calendar, with monitoring used for broad triage between cycles |
| Low | Minimal or no access to sensitive data or systems | Lightweight intake check; a security rating or public-posture scan is often sufficient as the primary signal | Re-assessed only if the relationship changes or an incident is detected |
This maps directly onto the tiering table in security ratings vs evidence-based TPRM, which covers which assessment method - rating, questionnaire, or both - fits each tier.
What regulators expect from tiering
Tiering is not just an internal efficiency measure; several frameworks explicitly require risk-scaled oversight rather than one-size-fits-all review. The 2023 Interagency Guidance on Third-Party Relationships, issued jointly by the OCC, the Federal Reserve, and the FDIC, states plainly that a banking organization's third-party risk management should be "commensurate with the level of risk, complexity, and size of the banking organization and the nature of the third-party relationship" - the regulatory version of tiering. DORA builds tiering into law directly by requiring in-scope financial entities to identify and register ICT third-party providers supporting "critical or important functions" for stricter contractual and oversight requirements than the rest of the portfolio. And ISO/IEC 27036-1, the ISO standard for information security in supplier relationships, frames categorizing suppliers by the risk they introduce as a foundational step before deciding how to manage each relationship. None of these sources hands you a rubric - they require that you have one, apply it consistently, and can show your work.
Where tiering goes wrong
- Tiering by spend or relationship length instead of exposure. A vendor's invoice size and a vendor's access to your data are unrelated variables; using the first as a proxy for the second misclassifies vendors in both directions.
- Setting the tier once and never revisiting it. A vendor's access and criticality change - a new integration, an expanded data-sharing agreement, an acquisition - and the tier should change with it. Build explicit re-tiering triggers into intake and change-management processes rather than relying on someone to notice.
- Blending inherent and residual risk into one tier score. Tier should be set by inherent-risk factors - what the vendor touches - not by how well-controlled it happens to be today; conflating the two is the specific error covered in inherent vs residual risk, and it produces the same misclassification here.
- No documented methodology. If a vendor's tier can't be traced to specific, named criteria, it isn't defensible to an auditor, and it's hard to explain to the business unit that thinks its vendor was tiered too strictly.
- Applying the same tier count regardless of portfolio size. A three-tier model that works for 200 vendors may need finer sub-segmentation at 5,000 - see TPRM for large enterprises for what changes at scale.
Putting tiering into a program
Write the criteria and thresholds down before you tier a single vendor, apply them at intake, and revisit the tier whenever the relationship's access or criticality changes - not on a fixed calendar alone. Platforms that pair continuous monitoring with evidence-based scoring, Rescana among them, can flag when a vendor's real-world footprint has outgrown its assigned tier, but the criteria and thresholds themselves are a program decision no platform can make for you.
Frequently asked questions
How do you tier third-party vendors by risk?
Vendor tiering sorts vendors into a small number of tiers - typically critical, significant, and low - using a fixed set of criteria: the sensitivity and volume of data the vendor can access, how operationally dependent you are on it, its regulatory scope, the depth of its integration or privileged access, and its subprocessor and concentration exposure. Each tier should carry a pre-agreed rule for assessment depth (full evidence-based review versus a lightweight check), monitoring intensity, and reassessment cadence, so the tier assigned at intake determines a concrete, documented level of ongoing scrutiny rather than a label with no operational consequence.
What criteria should determine a vendor's risk tier?
The criteria that hold up under audit describe what the relationship exposes, not the vendor's reputation or contract size: data sensitivity and volume the vendor can access, operational dependency (what breaks if the vendor is unavailable), regulatory scope (whether the vendor falls under a regime like HIPAA, GDPR, or DORA), integration depth and privileged access, and subprocessor or concentration exposure. Contract value and relationship length are common but unreliable substitutes - a low-spend vendor with standing access to production systems is a materially different risk than a large invoice for an offline service with no data access.
How many vendor risk tiers should a TPRM program use?
Most defensible programs use three tiers - commonly labeled critical, significant, and low - because additional tiers add administrative overhead without meaningfully improving decisions. Each tier should map to a concrete rule: critical vendors get a full evidence-based assessment and continuous monitoring with immediate re-review on any material signal; significant vendors get a targeted questionnaire and periodic reassessment; low vendors get a lightweight intake check and are only re-assessed if the relationship changes or an incident occurs. Very large portfolios sometimes add finer sub-segmentation within a tier, but the base model stays three-tier.
Does a vendor's risk tier ever change after onboarding?
Yes, and a program that never re-tiers a vendor after intake has a stale risk picture by design. A vendor's tier should change whenever the underlying exposure changes - a new integration or data-sharing agreement, an expanded scope of work, an acquisition, or a shift in regulatory scope - not on the vendor's behavior or control improvements, which affect residual risk rather than the inherent-risk factors that set the tier. Mature programs build explicit re-tiering triggers into change-management and contract-renewal processes, and use continuous monitoring signals to flag when a vendor's real-world footprint has outgrown its assigned tier.