Most privacy reviews do not fail because the reviewer missed a clause. They fail because the review happened at the wrong moment, or because nobody could say who was allowed to let the vendor go live. This article is about the process rather than the substance: the stages a privacy review passes through during vendor onboarding, who owns each one, and what has to be true before data moves.
The substantive checks belong elsewhere. What to examine about the vendor is in our GDPR vendor due diligence checklist, and how to score what you find is in the SaaS vendor risk assessment workflow. Here we are concerned with sequencing, ownership, and gates.
Why timing decides the outcome
A privacy review that starts after the contract is signed can only produce two results: approval, or an expensive problem. By that point the commercial terms are agreed, the budget is committed, and a launch date has usually been promised to someone. The reviewer has responsibility without leverage.
The fix is structural. Make the privacy review a precondition of two things that the business genuinely cares about: signature, and access to production data. Reviews attached to milestones people need get done. Reviews attached to good intentions do not.
The five stages
Stage 1: intake and triage
Someone requests a new tool. The intake step captures enough to decide how much review is warranted, and no more. In practice five questions suffice:
- What is the tool for, and which business process does it support?
- Will it process personal data, and if so, whose and what categories?
- Will it involve special category data under Article 9 of the General Data Protection Regulation (GDPR)?
- Roughly how many people's data is involved?
- Is there an existing approved tool that already does this?
That last question resolves a surprising share of requests without any review at all. Intake should be a short form owned by the requesting business unit, not an interview conducted by privacy.
Triage then assigns a tier, which determines the depth of everything that follows. The criteria are covered in prioritizing vendors for privacy review.
Stage 2: assessment
Privacy and security run their checks in parallel rather than in series, because sequencing them doubles the elapsed time for no gain. Privacy establishes the role, the lawful basis for the flow, the sub-processor position, and the transfer position. Security examines the technical and organizational measures.
The output of this stage is a set of findings, not a verdict. Findings should be specific enough to act on: not "transfers are unclear" but "vendor lists two sub-processors in a third country with no mechanism named for either".
Stage 3: contract review
Legal reads the data processing terms against Article 28(3) and negotiates what can be negotiated. Our Data Processing Agreement review checklist covers the sequence, and the wider legal process is in vendor legal review.
Running this in parallel with Stage 2 is tempting and usually a mistake for higher tiers, because the assessment findings change what you need from the contract. If the vendor uses sub-processors in third countries, the transfer clauses matter far more than they would otherwise.
Stage 4: decision and conditions
A named owner records one of three outcomes: approved, approved with conditions, or not approved. Conditions must each have an owner, a deadline, and a definition of what closes them.
This is the gate. Nothing moves to production data until the decision is recorded and blocking conditions are closed.
Stage 5: registration and handover
The approved vendor is added to the records that have to stay accurate: the processing record under Article 30, the vendor inventory, and the monitoring watchlist. Our article on RoPA accuracy when vendors change covers why this step is the one that quietly decays.
Handover matters because onboarding ends but the relationship does not. The vendor now belongs to a review cycle, and someone owns it.
Who owns what
Ambiguous ownership is the second most common failure after bad timing. A workable split:
- The requesting business owner: intake accuracy, the description of what data will flow, and closing business-side conditions.
- Privacy: role determination, transfer position, lawful basis, and the final privacy decision.
- Security: technical and organizational measures, and the security decision.
- Legal: contract terms and negotiation.
- Procurement: the commercial process, and enforcement of the gate.
Procurement holding the gate is what makes the process real, because procurement controls signature. The interaction between these functions is covered in cross-functional vendor review.
What "approved" should actually mean
Approval is scoped, not general. An approval covers a defined processing purpose, a defined data set, and a defined configuration. If the business later wants to push a new category of data into the same tool, that is a new review, not an extension of the old one.
Write the scope into the decision record. Without it, approval drifts, and the tool that was approved for anonymous product analytics ends up holding customer support transcripts.
Common failure modes
- Reviews triggered by contract value rather than by data sensitivity, so a low-cost tool holding sensitive data escapes scrutiny.
- Trials with production data starting before any review, on the theory that a trial is not really live.
- Conditions recorded without owners, which are never closed and never revisited.
- Approvals with no scope, which quietly expand.
- Onboarding that ends at signature, leaving no monitoring owner.
Frequently asked questions
How long should the process take?
Set a published target by tier and measure against it. The specific number matters less than having one, because an unbounded review is what drives teams to route around the process.
Can low-risk vendors skip the review?
They should skip most of it. A tool that processes no personal data needs a recorded determination to that effect and nothing more. Proportionality is what keeps the process credible for the cases that matter.
What about tools already in use that never went through this?
Run the same triage over the existing population and work down by tier. Most organizations find that the largest risks are in vendors that were adopted before any process existed.
Does a trial need a review?
If it uses real personal data, yes. If it uses synthetic or test data, a recorded determination is usually enough.
Where DPAFlow fits in
Stage 5 is where this process most often breaks: the vendor is registered, and then the facts move without anyone noticing. DPAFlow checks vendor sub-processor lists, Data Processing Agreement pages, and trust-center pages on a scheduled, recurring basis, records changes with dated evidence including captured page text and change differences, and sends email alerts so a change reaches the owner assigned at handover. Detected changes enter a review workflow where the team documents its assessment.
DPAFlow does not make the approval decision and does not provide legal advice. It keeps the post-onboarding record honest. The workflow for privacy teams is described on the privacy and data protection officer use case page.
This article describes a process design. It is not legal advice, and the substantive determinations belong to your privacy function and counsel.