Vendor Tiering: Criteria, a 3-Tier Model and Review Cadence

Last updated July 2026. Vendor tiering is the decision that makes every other part of third-party risk affordable. Assess 400 suppliers to the same depth and you will either spend the year on questionnaires nobody reads, or quietly stop assessing anyone. Tiering fixes that by deciding, once and defensibly, how much scrutiny each vendor earns.

This guide covers what tiering actually is, the criteria that drive a tier, a three-tier model you can copy, how often to reassess each tier, and the mistakes that quietly turn a tiering model back into a spreadsheet nobody trusts.

What is vendor tiering?

Vendor tiering is the practice of sorting third parties into risk bands so that the depth of your due diligence matches the damage that vendor could cause. A tier 1 vendor whose failure would halt operations or expose regulated data gets a full assessment and continuous monitoring. A tier 3 vendor with no data access gets a short check and an annual look.

The word people reach for instead is criticality, and the two are close but not identical. Criticality describes the vendor. A tier describes what you are going to do about it: which questionnaire, which evidence, which approver, which review cadence. Tiering is criticality turned into a policy your team can execute the same way every time.

What criteria decide a vendor's tier?

Most programs land on four or five factors. Keep the list short. A twenty-factor scoring model looks rigorous in a policy document and gets abandoned within two quarters because nobody can fill it in consistently.

Notice what is missing: contract value. Spend is a procurement signal, not a security one. The cheapest line item in your AP ledger can be the marketing tool with a token that reads your entire CRM, and the most expensive can be a facilities contract with no network access at all. Use spend to find vendors, never to rank their risk.

A three-tier vendor tiering model you can copy

Three tiers is the right default for almost everyone. Four is defensible at enterprise scale. Five means you will spend more time arguing about tier boundaries than assessing vendors.

The single most valuable rule in that table is the tier 3 screening set. Its job is not to assess the vendor. Its job is to confirm the assumption that put them in tier 3, because the expensive incidents in third-party risk are almost always a vendor everyone believed was harmless. A four-question screen that asks what data they hold and what access they were granted will re-tier a handful of vendors every year, and those are exactly the ones you needed to catch.

How often should you reassess each tier?

Match cadence to tier: tier 1 vendors get continuous monitoring and a formal annual reassessment, tier 2 gets a scheduled review every 12 to 24 months, and tier 3 gets an inventory check once a year. Then layer event triggers on top, because the calendar is not what tells you a vendor got worse.

The triggers that matter more than the schedule are a disclosed breach at the vendor or in their supply chain, an acquisition or change of control, a material change in the data or access they hold, a lapsed or newly scoped certificate, and the vendor moving into a new jurisdiction. Any one of those should pull a review forward regardless of when the last one happened. Quarterly formal reassessment of tier 1 vendors is advocated by some frameworks and is genuinely rigorous, but for most mid-market teams it produces reviews the vendor cannot service and the team cannot staff. Continuous monitoring plus a real annual reassessment and honest triggers beats a quarterly cycle everyone starts skipping in month seven.

Where do you get the vendor list in the first place?

Almost every tiering project stalls here, because the security team's list of vendors is the list they remember. The complete list lives in finance. Start from what the company actually pays: the AP ledger, the corporate card statements, and the purchase order records that show what was approved and by whom. Then reconcile that against your identity provider's list of SSO and OAuth integrations, which catches the tools that were adopted with a credit card and never went through procurement at all.

Those two sources together usually produce two to three times the vendor count anyone expected, and that gap is the real finding. You cannot tier a vendor you do not know you have, and a tiering model applied to a partial inventory gives you the confidence of a complete program with none of the coverage.

Does vendor tiering satisfy SOC 2 or ISO 27001?

Tiering by itself is not a control, but it is what makes the vendor management controls in both frameworks evidenceable. SOC 2 expects you to show that third parties handling your data are evaluated and monitored. ISO 27001 covers supplier relationships in Annex A. Neither prescribes a tier model, and neither will accept a policy with no records behind it.

What an auditor tests is consistency. They will take your tiering criteria, pick a handful of vendors, and check that each one was tiered by those criteria, assessed at the depth the policy promises for that tier, and reviewed on the cadence you wrote down. A defensible three-tier model with complete records beats an elaborate five-tier model applied to half the inventory, every time. That is also why the tiering rationale belongs in the vendor record rather than in someone's head: the reason a vendor is tier 2 is the thing you will be asked to produce.

Common vendor tiering mistakes

Four failure modes come up repeatedly, and all four are recoverable.

Tiering once and never again. A vendor onboarded three years ago for a read-only reporting feed now has write access to production and holds customer records. Nothing in the process noticed, because tiering happened at onboarding and the record was never revisited. Re-tier on change, not on anniversary.

Letting the business self-tier. Ask a project owner how critical their vendor is and the answer is critical, because critical is how you get budget. Tier from the criteria, with the business owner supplying facts about data and access rather than a rating.

Grading the tier 1 list on paper alone. A SOC 2 report filed without reading it is not diligence. Check the scope, the period, the carve-outs and the exceptions, because a clean-looking report can exclude the exact system you depend on. This is the work a vendor security assessment exists to make repeatable.

Tiering for the outbound direction only. Every company running vendor tiering is itself a tier 1 vendor to somebody, and that customer is sending a questionnaire that holds up a deal. Teams that treat inbound assessments as a sales interruption rather than part of the same program end up rebuilding the same evidence twice a quarter. Security questionnaire automation is the other half of the workflow, not a separate problem.

How software changes the tiering job

Tiering does not need a platform. A spreadsheet with five criteria and three tiers is a real improvement over assessing everyone identically, and plenty of programs run that way for years. What software changes is whether the model survives contact with a growing inventory.

The parts that break first are the ones a spreadsheet cannot do: noticing that a vendor's certificate expired, catching the breach disclosure that should have triggered a review, keeping the tier rationale attached to the vendor record when the person who wrote it leaves, and producing the evidence trail an auditor asks for without a week of archaeology. The platforms buyers shortlist for this work split into three categories, covered in our guide to the best third-party risk management software, and they solve different halves of it. Security ratings vendors like SecurityScorecard and its competitors monitor the outside view continuously. Profile exchanges such as Whistic and the other assessment networks shorten the collection work for vendors already in their catalog.

Where Scrutineer fits

Scrutineer runs tiering as part of one workflow rather than as a preliminary spreadsheet. Each vendor carries its tier, the criteria that produced it and the diligence that tier requires, so the assessment sent, the evidence collected and the review cadence follow from the tier automatically instead of from someone remembering. Monitoring and trigger events re-open the review when the vendor changes, and the whole record is the audit evidence.

It also runs the inbound direction from the same evidence base, which is the part most third-party risk management software leaves to a different tool. The controls mapped for your own SOC 2, ISO 27001, HIPAA, GDPR, PCI, SOX, CMMC and FedRAMP work are the same controls your customers are asking about, so answering them is a drafting job rather than a research project. Scrutineer is decision support and audit readiness: an accredited independent auditor still performs the audit and issues the attestation.