Vendor Tiering: Your Vendor List Is Not a Vendor Program

Somewhere in every organization, there is a spreadsheet named ‘Vendors.’ It has 247 rows, four columns, and a last updated date that predates at least one executive leadership team reorganization. Sadly, this spreadsheet is a list, not a vendor program. It’s not a useless document, but it will fail you when you need details and quickly.

What you really need is a vendor program. A vendor program, unlike a list, is a system. And the moment you have a privacy incident, a DSR request, or a customer due diligence questionnaire, you learn the difference. The question is never “Do we have vendors?”

It’s more like “Which vendors touch personal data, what do they do with it, where is it processed, and what are we allowed to do about it?” And there is a very good chance your spreadsheet may not be cutting it for the deep dive answers that are needed when everyone is in a panic.

We’re all just trying to avoid the million-dollar question too casually stated, “Wait… isn’t that stored in [VendorName] too?”

Most outlets tell you what to think. The Flyover just tells you what happened. Free, fast, fact-focused news across politics, business, sports, and more. Join over 2.3 million readers — no paywall, no agenda.

Join Free Today

You probably already have a vendor security review, and that’s great. It’s necessary. That said, security and privacy overlap, but they are not interchangeable. A security review might confirm a vendor has strong controls. A privacy review asks whether this vendor should have this data at all, what is the vendor allowed to do with that data, what happens with subprocessors, what are the retention rules, and how do individual rights requests get handled.

Privacy reviews also force your business to question a vendor’s practices around visible compliance and whether your business we stand behind it? Subprocessors, cross‑border transfers, and data uses (including AI training) are where vendor risk tends to hide. Privacy reviews also intersect with employment privacy and customer expectations. If a vendor processes employee data (e.g., for HRIS, payroll, background checks, workplace monitoring tools), the organization may have additional notice obligations and higher sensitivity expectations, even if the vendor is ‘secure.’ And, finally, if you sell to enterprise customers, your vendor program becomes a sales enabler. Customers ask for subprocessors lists, transfer mechanisms, retention terms, and DSR workflows. A vendor register and a repeatable review process turn those requests into a fast answer instead of a month-long scramble.

Vendor risk appears at three predictable times.

First: onboarding. You’re evaluating a new tool, and the business wants to move fast.

Second: renewal. The contract is expiring, the vendor has become ‘mission critical,’ and you suddenly have leverage that you didn’t when you were a new client and they didn’t have to worry about churn.

Third: incident or complaint. Something goes wrong, and you discover you don’t have the contacts, contractual terms, or operational clarity you assumed you had.

Bonus: Extra mature programs also engage in spot checks where they randomly audit current vendors to see if they are complying with their requirements.

A mature program designs for all three moments and does spot checks. Most organizations only design for onboarding, and even that can sometimes be improvised. I unfortunately have spoken to some fairly mature organizations (think global banks) that get heartburn thinking about their vendor renewal processes, so this isn’t a ‘you’ problem. It’s an ‘all of us’ problem.

Most organizations also miss a fourth moment: feature expansion. A vendor adds a new module, turns on AI by default, changes hosting regions, or adds a new subprocessor. This is a gnarly one, because not all of these changes are obvious, and if you don’t have a way to detect them, you don’t really have ongoing oversight.

An end‑to‑end vendor privacy review generally looks like this:

If you want your vendor program to run smoothly, define a simple routing rule that assigns ownership out to specific departments. For instance, procurement owns intake and contracting workflow, privacy owns privacy requirements and decision-making, security owns technical controls, legal owns risk acceptance language and negotiation strategy, and the business unit owns the purpose, data selection, and implementation. When these owners are unclear, vendor reviews turn into a game of hot potato. Everyone is involved, nobody is accountable.

A vendor questionnaire is for the vendor. A vendor intake form is for your internal team. You need both because you can’t evaluate risk if you don’t know what you’re buying. At minimum, the business unit should provide you with the business purpose, the intended users, the data types involved, how data will be transferred (API, SFTP, manual uploads), whether the vendor will have admin access, whether the tool is customer-facing, the implementation timeline, and whether there is an alternative vendor if the risk is too high.

Some organizations go farther and ask the business to have an executive sponsor sign off on the intake or to validate in some way that this purpose isn’t covered by a tool that the organization already pays for. That can all be included in your intake. It’s up to you how detailed you make your internal intake, but you should view it is an internal fact-finding and vetting process before you involve the vendor team. This intake step also prevents the most common vendor review failure, and that is where privacy and security teams have to try and reverse‑engineer scope from marketing screenshots.

Tiering allows you to scale effort based on risk. Not having tiering means you have to treat every vendor as high-risk or worse than that as low-risk or maybe even worse than both of those, being uncertain about the risk and coping by waking up in a cold sweat every night like that poor procurement executive from the global bank I was talking about.

High‑risk vendors (e.g., sensitive data, large volume, core systems, broad access, or cross‑border complexity) should require deeper diligence, stronger contractual controls, and periodic reassessments. Low‑risk vendors should not take 30 days to approve. If your process is too heavy for low‑risk, business teams will route around you. That’s how shadow IT happens, and we don’t like that one bit! The goal of your vendor review program should be to say ‘yes’ consistently but safely.

A practical tiering model often uses a few high-signal inputs: data sensitivity, volume, access method (API vs file transfers vs admin access), whether the vendor is customer-facing, cross‑border processing, and whether the vendor has AI features that could create new data uses. Focus on consistency in scoring rather than perfection. Consistency is what makes your decisions defensible.

In an ideal world, every contract has perfect privacy clauses. In the real world, you need a clear stance on non‑negotiables and acceptable fallbacks. You also need to be willing to stick to your guns on what’s non-negotiable, or everything becomes a policy exception, and when everything is an exception, the rule is useless, and regulators don’t believe you when you say you have a policy.

Non‑negotiables for higher-risk vendors often include incident notification within a defined time, restrictions on using data for the vendor’s own purposes (including AI training), subprocessors transparency and controls, and a clear deletion/return obligation at termination. You may also choose to have floors for cyberinsurance coverage, limitations on liability, and other more complex contract stances. Fallback positions might include accepting vendor security reports instead of annual audit rights, accepting a shorter list of security measures if equivalent controls exist, or accepting deletion within a longer window if backups are involved, so long as the vendor can credibly explain how data is suppressed and not restored into production. The key with contract negotiation (which is basically the same key I tout all over this article and my other Fieldnotes articles) is that you should have the defined and documented and when an exception is made, go through a risk acceptance process to prove it internally.

Vendor reviews got weirder in the last two years because many ‘normal’ SaaS tools now include AI features. A tool that used to store customer tickets now offers “AI summarization.” A CRM now offers “AI insights.” A support tool now offers “AI agent replies.” These features can change data flows and data uses even if the vendor insists nothing changed.

The privacy questions to ask are straightforward:

If you don’t ask these questions at onboarding, you’ll be asking them later, after the tool is embedded, and it will be even less fun then. Also be sure to watch for ‘agentic’ features. If a vendor tool can take actions (e.g. send emails, generate contracts, modify records), your risk isn’t limited to privacy. It’s business risk, auditability, and potential privilege issues.

Vendor risk doesn’t end at signature. It’s ongoing but for many businesses impractical to be 100% keyed into what every vendor is doing all the time. That’s what makes a review at vendor renewal a convenient point to ask if anything changed, if any incidents occurred, if they added any new subprocessor, if AI features got added. It’s also a good time to ask the internal business unit whether your use of the tool expended and whether the vendor met their contractual commitments. You may also have an opportunity to tighten terms. A vendor that wouldn’t budge on notification timelines during onboarding might budge when renewal is on the line and they have to explain why they lost a good customer.

Create a simple trigger list for reassessment, including material change notices, new product modules, new subprocessors, new regions, incidents, and high-severity customer complaints.

For higher-risk vendors, you should expect a baseline set of documents, including security attestations or reports (e.g., SOC 2), a privacy policy or trust center materials, an incident response overview, subprocessors list, data processing addendum, and information on data retention and deletion. Not every vendor will have everything. That’s fine. The point is to identify gaps early, decide whether you accept the risk, and document the decision. A program is defensible when it can explain its decisions.

On the privacy side, you may also want to request a data retention schedule (or at least deletion timelines), a description of how DSR requests are handled, whether data is used for analytics beyond providing the service, and what monitoring or logging the vendor performs on your data.

On the contracting side, even a lightweight DPA should cover purpose limitation, confidentiality, security measures, subprocessors controls, incident notification, DSR assistance, cross‑border transfer mechanisms where relevant, audit/assessment rights (or alternatives like third‑party reports), and deletion/return at end of service. For more important contracts, also make sure the main agreement includes provisions for insurance, indemnification, and liability caps (or lack of caps is really more like it).

Cross‑border risk can seem amorphous, but your vendor review should capture where data is stored, where it is accessed, where support is located, and whether data is transferred onward to subprocessors. If cross‑border transfers are relevant for your organization, your toolkit should include a transfer assessment step and a place in your vendor register to track it Even if you don’t negotiate detailed transfer clauses for every vendor, you should at least know the facts. You can’t govern what you can’t see.

The micro‑tool below is a quick vendor tiering triage and contracting checklist. It’s designed for the moment when procurement says, “We need an answer by Friday,” and you need to decide what level of diligence is reasonable. Use it to classify tier, identify non‑negotiables, and capture a short decision record.

If you want to mature beyond triage, create a vendor review summary memo for every medium/high vendor. It doesn’t need to be long, but it should outline what they do, what data they touch, key risks, required controls, contract status, and whether residual risk is accepted. That memo becomes gold at renewal time.

If you want your vendor program to be credible to leadership, auditors, and customers, track a few simple metrics, including percentage of vendors tiered, percentage of high-risk vendors with completed due diligence, renewal review completion rate, and average time to approve low-risk vendors.

Also track evidence. Keep a consistent ‘vendor packet’ for each medium/high vendor that includes intake, questionnaire or diligence notes, key documents (SOC 2, subprocessors list), executed DPA, and decision memo. This makes audits and due diligence much faster.

Finally, reminder that the opinions expressed in this article are the opinion of The Privacy Design Lab. They are not legal advice, and no attorney-client relationship is formed by reading this article or downloading the Vendor Tiering & Must-Have Clauses Quick Check. If you need to consult legal counsel, you can book a consult with ARLA Strategies or other legal counsel you trust!

If you’re tired of privacy advice that only works in theory, you’re in the right place.

The Privacy Design Lab exists for people who want to practice privacy, not just talk about it. It focuses on practical, repeatable ways teams actually learn. We offer hands-on workshops, downloadable systems, and the Design Studio community where teams and practitioners can go deeper. Paid Fieldnotes subscribers get access to our full archive, plus supporting materials you can actually use.

If that sounds like your kind of work, we’d love to have you.