Most organizations discover, somewhere between the two hundredth and the five hundredth supplier, that reviewing every vendor to the same depth on the same cycle is not possible. The response that follows determines whether the programme becomes useful or ceremonial. Reviewing everything shallowly produces a tidy spreadsheet and no assurance. Reviewing everything deeply produces a backlog.
The workable answer is triage: decide which vendors deserve depth, which deserve a light touch, and how often each group comes round again. This article sets out criteria that hold up when someone asks why a particular vendor was not reviewed.
Start from processing, not from spend
Contract value is the most common prioritization criterion and the worst one. The relationship between what a supplier costs and what happens if it mishandles personal data is close to arbitrary. A modest analytics tool can hold behavioural data on every customer you have; an expensive infrastructure contract may involve no personal data at all.
Prioritize on the processing. Four inputs are enough to separate the population sensibly.
Data sensitivity
Special category data under Article 9 of the General Data Protection Regulation (GDPR), criminal offence data under Article 10, financial details, authentication credentials, precise location, and data about children all raise the stakes. So does any data set whose exposure would harm the individuals concerned rather than merely embarrass you.
Population and volume
Whose data is it, and how many people? Data about employees and customers who had no realistic choice about the relationship deserves more care than data about business contacts who chose to engage. Volume matters, but a small data set about a vulnerable population can outrank a large one about business email addresses.
Depth of access
Distinguish between vendors that store data, vendors that transmit it, and vendors whose staff can read it. A supplier whose support engineers can open a record is in a different category from one that processes an encrypted payload it cannot interpret.
Chain complexity
A vendor with a long sub-processor chain, particularly one crossing into third countries, is harder to keep accurate and changes more often. Chain opacity is itself a prioritization signal: a vendor that will not tell you who it uses should be reviewed sooner, not later.
A workable three-tier model
Three tiers are usually enough. More tiers create classification debates without changing behaviour.
- Tier 1, critical: special category or financial data, large populations, staff-readable access, or a complex third-country chain. Full diligence at onboarding, deep re-review annually, and continuous watching of published disclosures.
- Tier 2, standard: ordinary personal data, moderate populations, limited access depth. Standard diligence at onboarding, lighter re-review every eighteen to twenty-four months, and continuous watching of disclosures.
- Tier 3, minimal: little or no personal data, or fully aggregated data. A recorded determination at onboarding and periodic confirmation that the position has not changed.
Assigning the tier is the decision. Everything downstream, including review depth, evidence expectations, and cadence, follows from it.
Escalation criteria that override the tier
Tiering is a starting position, not a cage. Several events should pull a vendor forward regardless of its tier:
- A new sub-processor, particularly in a third country.
- A change of transfer mechanism.
- A publicly reported security incident at the vendor or in its chain.
- A change in what the business sends the vendor.
- An acquisition, restructuring, or change of control.
- Any material change to the vendor's published data protection terms.
These are the triggers that matter operationally, because they arrive between scheduled reviews. Our article on monitoring sub-processor changes covers how to catch them, and why sub-processor lists change explains why they arrive more often than teams expect.
Building the initial list
Most organizations do not have a reliable vendor list when they start, which is the real reason prioritization stalls. Three sources together produce a workable population:
- The accounts payable ledger, which finds anything being paid for.
- Identity and single sign-on logs, which find tools people actually use.
- The processing record maintained under Article 30, which finds what has already been documented.
The gaps between those three sources are informative in themselves. A tool that appears in single sign-on but not in the ledger is often a free tier that nobody reviewed. Our guide to building a vendor sub-processor inventory covers the assembly in more detail.
Cadence without theatre
Annual review of everything is a common policy and a rare practice. It is better to write down a cadence you will actually meet than an aspirational one you will not, because an unmet policy is worse evidence than a modest one that is honoured.
Two habits make cadence realistic. First, separate the deep periodic review from continuous watching: most change between reviews is visible on vendor pages and does not require a full reassessment to detect. Second, let the tier drive the interval, so review effort concentrates where consequences are largest. The mechanics of a repeatable cycle are covered in our recurring vendor review workflow.
Frequently asked questions
How do we justify not reviewing a vendor deeply?
By recording the tiering decision and its reasoning at the time. Accountability under Article 5(2) of the GDPR is about demonstrating a considered approach, and a documented, risk-based allocation of effort is defensible. An undocumented one is not.
Should sub-processors be tiered too?
You contract with the vendor, not its sub-processors, so the vendor carries the tier. But a vendor whose chain includes entities in higher-risk destinations should inherit a higher tier because of it.
What if the business disputes a tier?
Make the criteria explicit and the assignment reviewable. Most disputes are really disputes about the scope description, which is worth resolving because everything else depends on it.
How does this relate to risk assessment?
Tiering decides how much assessment a vendor gets. The assessment itself, once you run it, is covered in our SaaS vendor risk assessment workflow.
Where DPAFlow fits in
Tiering only reduces work if the lighter tiers are still watched. DPAFlow checks vendor sub-processor lists, Data Processing Agreement pages, and trust-center pages on a scheduled, recurring basis regardless of tier, records what changed with dated evidence including captured page text and change differences, and sends email alerts so an escalation trigger reaches a person. Detected changes enter a review workflow where your team decides whether to pull the vendor forward.
The tiering and the judgments stay with your team, and DPAFlow does not provide legal advice. The evidence model is described on the evidence page.
This article proposes a prioritization method. It is not legal advice, and the allocation of review effort should be agreed with your own privacy function.