A vendor legal review is the structured examination a legal or privacy function runs over a supplier before the organization commits to it, and again when something material changes. It answers one question: can we lawfully send this data to this vendor, on these terms, and prove later that we thought about it?
In practice the review fails for procedural reasons far more often than legal ones. It arrives too late to change anything, it lands on one person with no defined scope, or it produces an opinion in an email thread that nobody can find eighteen months later. This article sets out a workflow that avoids those failure modes: who starts the review, what legal actually examines, what the decision gates are, and what the durable record should contain.
When the review should start
The single highest-leverage change most teams can make is moving the review earlier. A legal review that begins after a business owner has chosen a vendor, agreed a price, and promised a launch date is not a review; it is a request for approval under time pressure.
Trigger the review at the point a vendor becomes a serious candidate and personal data is in scope, not at contract signature. The practical trigger is usually the first of these to happen:
- A business owner requests a security or privacy assessment for a shortlisted supplier.
- Procurement opens a commercial negotiation.
- Someone asks for a trial that would involve real personal data rather than test data.
- An existing vendor proposes a material change, such as a new module, a new region, or a new sub-processing arrangement.
The last trigger matters as much as the first. Reviews framed purely as an onboarding gate leave the much larger population of already-signed vendors unexamined, which is where most unpleasant surprises actually live.
What legal is actually reviewing
A vendor legal review is not a re-reading of the whole contract. It is a targeted examination of the provisions that determine lawfulness, allocation of responsibility, and your ability to evidence both. Five areas carry most of the weight.
Roles and the processing description
Establish whether the vendor acts as a processor on your instructions, as a controller in its own right, or as a joint controller for some part of the processing. The answer is determined by who decides purposes and means in fact, not by the label in the contract. The European Data Protection Board's Guidelines 07/2020 on the concepts of controller and processor are the working reference here, and misclassification is expensive to unwind after go-live. Our guide to controller, processor, and subprocessor roles covers the distinctions in more depth.
Then check that the contract actually describes the processing: subject matter, duration, nature and purpose, categories of data and data subjects. A vague description is not a drafting nicety. It is the boundary of the vendor's mandate, and everything downstream depends on it.
The data processing terms
Article 28(3) of the General Data Protection Regulation (GDPR) sets out the mandatory content of the contract between controller and processor. Read the vendor's terms against that list rather than against your impression of whether they seem reasonable. The clause-by-clause treatment is in our GDPR Article 28 requirements guide and the practical review sequence is in the Data Processing Agreement review checklist.
Sub-processing
Determine which authorization model applies, what notice you receive before a new sub-processor is engaged, how long you have to object, and what happens if you do object. This is the provision most likely to be quietly unfavourable, and the one whose consequences arrive long after signature.
International transfers
Identify every destination outside the European Economic Area and the mechanism relied on for each. Confirm that the mechanism is named specifically rather than gestured at, and that the vendor commits to giving you the information you need to assess and maintain that position over time.
Security, incidents, audit, and exit
Check that security commitments are specific enough to be tested, that incident notification carries a defined trigger and timescale, that audit rights are workable in practice, and that deletion and return obligations at the end of the relationship have deadlines attached.
Decision gates rather than opinions
A review should end in a decision with a named owner, not a summary of concerns. Three outcomes are usually enough:
- Approved as presented, where the terms and the transfer position are acceptable.
- Approved with conditions, where specific changes must be negotiated or specific compensating steps recorded before data flows.
- Not approved, where the arrangement cannot be made lawful on acceptable terms.
The middle outcome needs discipline, because it is where reviews quietly fail. A condition without an owner and a date is a wish. Record who is responsible for closing each condition and what evidence closes it.
The record the review must leave behind
Accountability under Article 5(2) of the GDPR requires you to be able to demonstrate compliance, not merely to have achieved it. For each review, keep a record that captures:
- The vendor, the service, and the processing in scope.
- The role determination and the reasoning behind it.
- The contract version reviewed, with a date.
- The sub-processor position at the time of review.
- The transfer destinations and mechanisms relied on.
- The decision, its conditions, the owner, and the date.
- The evidence relied on, captured rather than linked, since vendor pages change without notice.
That last point is the one most often missed. A review that cites a vendor's public sub-processor page as evidence has cited something that can change tomorrow, silently, with no notification to you. Dated captures are what make the record defensible later. Our article on audit-ready vendor evidence covers what good evidence looks like.
Keeping the review current
A vendor legal review has a shelf life. The contract stays as signed, but the facts underneath it move: sub-processors are added, workloads relocate, corporate structures change, and transfer mechanisms are swapped. A review that was correct at signature can quietly stop describing reality within months.
Two habits keep the record honest. First, schedule re-review by risk tier rather than reviewing everything annually, so attention lands where it matters; our guidance on prioritizing vendors for privacy review sets out workable criteria. Second, watch the vendor disclosures that change between reviews, so a material change reaches the reviewer inside the objection window rather than at the next annual cycle.
Frequently asked questions
Who owns the vendor legal review?
Legal or privacy usually owns the determination, but the review depends on inputs from security, procurement, and the business owner who knows what data will actually flow. A single named owner for the decision, with defined contributors, works better than shared ownership. The division of labour is covered in our article on cross-functional vendor review.
Does every vendor need a full legal review?
No. Vendors that never process personal data on your behalf need a much lighter touch. The proportionate approach is to tier vendors by the data they handle and the consequences of failure, then match review depth to tier.
What if the vendor refuses to negotiate its standard terms?
That is common with large suppliers and is itself information. Record what you asked for, what was refused, and what compensating steps you took. A documented decision to proceed on standard terms, with the risks identified, is a defensible position; an undocumented one is not.
Where DPAFlow fits in
DPAFlow supports the parts of this workflow that decay between reviews. It checks vendor sub-processor lists, Data Processing Agreement pages, and trust-center pages on a scheduled, recurring basis, records what changed with dated evidence including captured page text and change differences, and sends email alerts when something moves. Detected changes enter a review workflow where your team assesses materiality and documents the decision.
The judgments stay with your team. DPAFlow does not decide whether a change is material, does not negotiate terms, and does not provide legal advice. What it removes is the failure mode where a change lands on a vendor page and nobody sees it until the next review cycle.
You can see how the evidence side works on the evidence page, and how the workflow fits legal teams specifically on the legal use case page.
A closing note: this article describes how to structure a review process. It is not legal advice, and the substantive calls belong to your counsel.