Most companies have far more vendors than they can review in depth. The office coffee subscription and the cloud provider hosting production do not deserve the same scrutiny, and treating them alike produces one of two outcomes: a review process so heavy nobody finishes it, or one so light it misses the vendors that matter.
Tiering is the fix. You sort vendors into a few levels of risk, and the level decides how much review each one gets. The hard part is choosing the criteria. Spend, brand recognition and how strategic a vendor feels are all tempting, and all poor predictors of security risk.
This article argues for tiering primarily by data access, shows a four-tier model, lists the intake questions that set a tier, and covers the edge cases where data access alone gives the wrong answer.
Why the frameworks expect tiering
None of the major frameworks prescribes a tiering model. They all expect proportionate vendor risk management, which in practice means tiering.
SOC 2. CC9.2 in the AICPA's trust services criteria expects you to assess and manage risks associated with vendors and business partners. Auditors look for a defined process applied consistently, not the same review for every supplier.
ISO/IEC 27001:2022. Annex A control 5.19 covers information security in supplier relationships, and 5.22 covers monitoring and review of supplier services. Both imply that the effort fits the risk.
PCI DSS v4.0. Requirement 12.8 asks you to maintain a list of third-party service providers that can affect account data security, perform due diligence before engagement, and monitor their compliance status at least annually.
A tiering model is how you show an auditor the effort is proportionate by design, rather than by whoever had time.
Why data access is the right primary axis
The consequence of a vendor failure depends mostly on what the vendor can reach. A vendor with no access to your data or systems can let you down commercially, but it cannot leak your customers' records. A vendor holding those records can.
Data access is also observable. You can usually establish what data flows to a vendor from the integration, the contract and the people using it. That makes tiering repeatable, which matters when two people tier vendors over a year and need to reach the same answers.
Two secondary factors adjust the tier:
System access. Can the vendor change your production environment, your code or your identity configuration? Write access to production is serious even when no customer data is read.
Operational dependence. If the vendor goes down, does your service go down? A payment processor or a DNS provider may hold little sensitive data and still sit on your critical path.
Use your data classification policy for the data categories. If you do not have one, the tiers below assume three levels: sensitive (customer data, personal data, regulated data, credentials and secrets), internal, and public.
A four-tier model
The model below is illustrative. Adjust the boundaries to your data and your customers' expectations, and write the final version into your vendor management procedure.
| Tier | Typical criteria | Review it triggers |
|---|---|---|
| 1 Critical | Stores or processes sensitive customer or regulated data at volume, or has write access to production, or sits on the critical path of your service | Full due diligence before contract, independent assurance report reviewed, contract security terms, annual reassessment, ongoing monitoring |
| 2 High | Limited sensitive data, such as support tools that can view customer records, or employee personal data in HR systems | Due diligence before contract, assurance report or questionnaire, annual reassessment |
| 3 Moderate | Internal business data only, no production access, no critical dependence | Short security review at intake, reassessment every two years or on change of use |
| 4 Low | Public data or none, no integration, no dependence | Registration in the inventory and an owner; no security review |
Keep the number of tiers small. Three or four is enough. With more, the distinctions between adjacent tiers become arguments, and the arguments become inconsistent results.
The intake questions that set a tier
Tiering happens at intake, before the contract is signed. The person requesting the vendor should be able to answer a short set of questions in a few minutes:
What data will the vendor store, process or be able to view? Name the categories, and say whether any are customer, personal, health or payment data.
How will the data reach the vendor: manual upload, API integration, OAuth connection, or vendor staff logging in to your systems?
Will the vendor, or its software, be able to change anything in your production environment, source code or identity provider?
If the vendor were unavailable for a day, what would stop working, and would customers notice?
Will the vendor sign a data processing agreement or business associate agreement, if one is needed?
Who internally owns the relationship?
The answers map directly to the table. Where a question cannot be answered, assume the higher tier until it can. A data processing agreement or a business associate agreement requirement is a strong signal of tier one or two on its own.
Edge cases where data access misleads
Integrations broader than the use case
A scheduling tool connected through OAuth may request read access to every mailbox and file in your workspace, even if the team only wants it for calendars. Tier on the access the vendor is granted, not the access you intend to use. Where you can, reduce the scope before tiering.
Tools that touch production without reading data
Build systems, deployment tools, monitoring agents and infrastructure-as-code services often see little customer data but can change production. Tier them on system access. A compromised deployment pipeline can do more damage than a breached analytics tool.
Vendors whose staff can see your screens
Support and co-browsing tools, and consultancies with access to your systems, may give vendor personnel a view of sensitive data during normal work. Count that as data access.
Critical dependence with little data
Payment processors, DNS, email delivery and identity providers can be tier one on dependence alone. Their failure stops your service even if the data they hold is limited.
Free tools and trials
A free tool connected to production data is no less risky than a paid one. It is often riskier, because nobody negotiated the terms. Your intake should apply to anything that touches company data, not only to purchases.
Keeping tiers accurate
A tier is a statement about how a vendor is used today. Usage changes. A vendor brought in for internal reporting gets connected to the production database a year later, and nobody revisits the tier.
Three habits keep tiers current:
Re-tier on change of use. Make a new integration, a new data category or a broader OAuth scope a trigger for the intake questions again.
Re-tier at each reassessment. Ask the owner to confirm the answers rather than assuming them.
Record the reason. Store the answers that produced the tier next to it. When an auditor asks why a vendor is tier three, the answer should be on file, not in someone's memory.
Common tiering mistakes
Tiering by spend. An expensive consultancy may see nothing sensitive. A cheap API may hold your customers' personal data.
Tiering by reputation. A large, well-known vendor is not automatically low risk. Its scale changes the type of assurance available, not the consequence if it fails.
Tiering once. A tier set at onboarding and never revisited is a guess about the past.
Tiering without an owner. Every vendor needs a named internal owner, who answers intake questions, confirms reassessments, and starts offboarding.
Tiering feeds your risk register as well. Tier one vendors often appear there as risks of their own, rated with the same likelihood and impact scales as everything else.
How TrustLynce helps
TrustLynce's third-party risk module keeps the vendor inventory with each vendor's owner, data access answers and tier, and schedules the reviews and reassessments each tier requires. Tier changes are recorded with their reasons, so the history is there when an auditor asks.