A recurring vendor review workflow is the routine by which a Data Protection Officer (DPO) re-verifies, on a defined schedule and on defined triggers, that each vendor relationship still is what the paperwork says it is: the same service, the same data, the same subprocessors, the same transfer position, the same contract. It exists because the alternative — checking vendors thoroughly once, at onboarding, and never formally again — describes most organizations' actual practice, and it quietly stops being true within a year.
The General Data Protection Regulation (GDPR) leans on the controller to keep this current. Article 24 of the GDPR requires controllers to implement appropriate measures to ensure and demonstrate compliance, and to review and update those measures where necessary — review is in the text, not implied. Article 28 requires that processing by vendors rest on a contract with specific commitments, which is only meaningful if someone periodically confirms the vendor's practice still matches the contract.
This article lays out a workflow a DPO can actually run: why decay happens, the triggers that should start a review, a concrete agenda for the review itself, the division of labor, the evidence to keep, and how to scale the whole thing down for a small team.
Why one-time onboarding checks decay
Onboarding diligence is a snapshot taken on the day the relationship begins. Every element of it has a shelf life, and they expire at different speeds.
The vendor changes: it ships new features that touch new data categories, moves infrastructure, gets acquired, and swaps subprocessors — routinely and lawfully, usually announced only through an updated page. Your usage changes: the tool bought for one team spreads to three, a field intended for business contacts fills with customer data, an integration is switched on that nobody mentioned to privacy. The legal environment changes: transfer mechanisms are invalidated or introduced, guidance shifts, contract templates are superseded.
None of these events re-runs your onboarding checklist by itself. So the gap between documented reality and actual reality widens silently, and it typically becomes visible at the worst moments: during an incident, a customer audit, or a supervisory authority inquiry. A review workflow is simply the decision to find these gaps on your own schedule instead of someone else's.
Review triggers
A workable workflow mixes two kinds of triggers: the calendar, which guarantees a floor of coverage, and events, which catch what the calendar misses.
Time-based cadence
Tier vendors by criticality — sensitivity and volume of personal data, importance to your service — and attach a review frequency to each tier. A pattern that works for most mid-sized organizations: critical vendors quarterly, standard vendors annually, and peripheral low-data vendors every one to two years with a lightweight confirmation that they still belong in that tier. The tiering itself should come from your vendor and subprocessor inventory; the review calendar is then just the inventory's review-date column made real.
Event-based triggers
Certain events should start a review immediately, regardless of where the vendor sits in the calendar.
- A subprocessor change notice or a detected change to the vendor's subprocessor list, Data Processing Agreement (DPA) page, or trust center.
- A security incident at the vendor, or at one of its subprocessors, that could touch your data.
- Contract renewal or renegotiation — the one moment you have maximum leverage to fix gaps the review finds.
- A new or changed international transfer: a processing location moved, or a transfer mechanism changed validity.
- A material change in your own use of the vendor: new data categories, new departments, new integrations.
Event-based triggers only fire if the events are noticed, which is why continuous change monitoring feeds this workflow rather than replacing it — the mechanics of noticing are covered in our guide to monitoring subprocessor changes.
The review agenda
A review needs a fixed agenda, both so it can be delegated and so its output is comparable across vendors and across years. Six items cover the ground; for a standard vendor the pass takes well under an hour when the inputs are maintained.
- Confirm current usage. What service do we actually receive today, which teams use it, and what categories of personal data does it touch? Compare against the inventory entry and note drift — this is where scope creep surfaces.
- Verify the DPA still matches practice. Is the signed DPA the vendor's current version, does it cover the services now used, and do its commitments — security measures, assistance obligations, deletion terms — still reflect how the vendor operates?
- Check subprocessor deltas since the last review. Compare the vendor's current subprocessor list against the version recorded at the previous review, and confirm every change in between was seen, triaged, and either accepted or objected to. Unexplained deltas are findings.
- Verify transfer mechanisms. For each transfer outside the European Economic Area (EEA), confirm the claimed mechanism — an adequacy decision, the Standard Contractual Clauses (SCCs), or another safeguard — is still in place and still matches where processing actually happens.
- Refresh linked records. Update the affected Records of Processing Activities (RoPA) entries and revisit the Transfer Impact Assessment (TIA) where anything in items 1-4 moved. The review is the natural maintenance point for both.
- Record the outcome. Result (satisfactory, satisfactory with actions, or escalate), the findings, the actions with owners and dates, the reviewer, and the date. Set the next review date before closing.
The agenda deliberately ends with actions rather than a grade. The purpose of the review is not to score vendors; it is to converge documentation and reality, and each finding is one step of that convergence.
Who does what
The workflow crosses three roles, and reviews stall when the boundaries are fuzzy.
The DPO — or the privacy lead wearing that hat — owns the workflow: the tiering, the calendar, the agenda, and the quality of the outcomes. The DPO personally reviews the high-criticality vendors, handles anything involving regulatory interpretation, and reports on the program. What the DPO should not do is personally execute every review; that model caps the program at the size of one person's spare time.
The vendor owner — the person in the business who manages the relationship — supplies ground truth for agenda item 1, executes the routine checks for standard-tier vendors using the fixed agenda, and owns remediation actions that live in their domain, like renegotiating at renewal or turning off an unapproved integration.
Legal counsel is pulled in on exceptions, not routine: objection decisions, DPA renegotiations, transfer questions without an obvious answer, and any review finding that suggests a compliance gap with real exposure. Keeping counsel out of the routine passes is what keeps counsel available for the exceptions.
In practice the handoffs are the fragile part. A named backup for the DPO role and a rule that every review has exactly one accountable reviewer prevent the two standard failures: reviews nobody finishes, and reviews everybody assumed someone else was doing.
Keeping evidence of reviews
Under Article 24, the controller must be able to demonstrate that its measures are in place and reviewed; under Article 5(2) accountability is a standing obligation. For vendor reviews, demonstration means artifacts, and the artifact standard is simple: could a person who was not there reconstruct what was checked, what was found, and what was done?
Keep, per review: the completed agenda with the reviewer and date, the dated subprocessor-list comparison, the DPA version examined, findings and their resolutions, and the resulting updates to inventory, RoPA, and TIA entries. Keep the routine no-findings reviews too — a program that can only evidence its interesting reviews looks, from outside, like a program that rarely runs. Store everything centrally and exportably rather than in personal folders; audits ask for the file, not the memory. What that evidence pack should look like from the auditor's side is the subject of our piece on audit-ready vendor evidence.
The same records compound internally: two or three review cycles build a per-vendor history that tells you which relationships drift fastest, and that history is better input for your tiering than any onboarding questionnaire was.
Right-sizing for smaller teams
Everything above scales down; what must not be scaled away is the loop itself. For small and mid-sized enterprises (SMEs) with a part-time privacy function, three simplifications keep the workflow honest without making it a second job.
First, shrink the tiers, not the coverage. Two tiers suffice: the five to ten vendors that really matter, reviewed twice a year, and everyone else, reviewed annually on a lightweight version of the agenda — items 1, 3, and 6 as the floor.
Second, let events do the scheduling where you can. For the long tail, a detected subprocessor change plus contract renewal may be the only reviews a vendor gets — acceptable, provided change detection is actually running and renewals reliably trigger the pass.
Third, cut the artifact, not the record. A single page per review — agenda, findings, actions, dates — is entirely defensible. What is not defensible is the review that provably happened only as a calendar entry.
The one investment worth making early even at small scale is automating the noticing: the review workflow consumes change signals, and a small team has no spare capacity to generate those signals by hand.
Where DPAFlow fits in
DPAFlow supplies this workflow's two hungriest inputs: triggers and evidence. It monitors your vendors' subprocessor lists, DPA pages, and trust-center pages on a scheduled, recurring basis and sends email alerts when something changes — feeding the event-based triggers — and its dated captures and change diffs give agenda item 3 its comparison material without any archaeology. Review decisions land in a documented workflow, and the accumulated history exports as proof and report documents when someone asks you to show the program ran.
For a closer look at how DPOs run this loop day to day, see the privacy and DPO use-case page.