Most organizations have far more vendors than their security team can assess in depth. Tiering is how you decide, consistently and defensibly, which suppliers get a full review, which get a light check, and which need little more than a contract. Without it, assessment effort tends to follow whoever shouts loudest in procurement rather than actual exposure. This template gives you a starting structure for scoring criticality and data sensitivity; the weights and thresholds should reflect your own business.
Criteria that drive a vendor's tier
A worked tiering example
Here is one simple way to structure a model. Score data sensitivity and operational criticality from 1 to 4 each, then apply overrides for special conditions. The tier comes from the higher of the two scores rather than their sum, so a vendor that is extremely critical but holds no data is not diluted into a lower tier.
Four vendors scored
A Tier 2 High would sit between: for example, a customer support tool with access to customer records but a manual fallback if it fails. Overrides let you force a minimum tier for conditions you never want diluted, such as any vendor handling cardholder data or protected health information.
What each tier triggers
Triggers for re-tiering
- The vendor gains access to a new data category or much larger data volume.
- A pilot or proof of concept becomes production use.
- The vendor is acquired, changes hosting region, or adds significant subprocessors.
- A security incident at the vendor or a failed reassessment.
- The business builds a customer commitment that depends on the vendor.
- New AI features that process your data in ways the original assessment did not cover.
Framework expectations
No major framework mandates a specific tiering scheme, but most expect risk-proportionate supplier management. ISO/IEC 27001:2022 Annex A 5.19 asks for processes to manage supplier information security risks, and 5.22 for monitoring and reviewing supplier services. SOC 2 CC9.2 covers vendor and business partner risk. NIST CSF 2.0 GV.SC expects suppliers to be known and prioritized by criticality. PCI DSS 4.0.1 Requirement 12.8.1 requires a list of third-party service providers with a description of services provided. A documented tiering model is the simplest way to show auditors that your level of scrutiny is deliberate. Background on the discipline sits in the third-party risk glossary entry.
Evidence to keep
- Approved tiering methodology with criteria, scales, and overrides
- Complete vendor inventory showing each vendor's tier and the date it was set
- Intake records showing tiering happened before contract signature
- Due diligence records matching the requirements for each tier
- Reassessment dates, with overdue items visible
- Exceptions where a vendor was onboarded before assessment, with approver
Common mistakes
- Tiering only vendors that procurement routes to security, while teams buy SaaS on corporate cards.
- Summing scores so high criticality is averaged away by low data sensitivity.
- Never re-tiering, so vendors keep the tier assigned at a small pilot years ago.
- Tiers with no practical difference in the due diligence they trigger.
For how tiering fits the rest of a program, read the vendor risk program guide or see the vendor risk program use case. Asurvo's Third Party product covers vendor inventory, tiering, questionnaires, risk scoring, and continuous monitoring in one workflow.