Vendor review is one of the few compliance processes that genuinely requires four functions to agree. Privacy owns the lawfulness question, security owns the control question, legal owns the contract, and procurement owns the commercial relationship and the timeline. Each of them holds a piece of the answer, and none of them holds enough of it to decide alone.
The predictable result is that reviews stall in the handoffs rather than in the analysis. This article covers how to divide the work, where the handoffs fail, and what a shared record has to contain for four functions to work from one view.
Divide by decision, not by document
The most common design error is splitting the work by artifact: privacy reads the privacy policy, security reads the security documentation, legal reads the contract. That produces four parallel readings and no decision, because the interesting questions cross the artifacts.
Split by decision instead. Four decisions, each with one accountable owner:
- Is this processing lawful, and on what basis? Owner: privacy.
- Are the vendor's controls sufficient for this data? Owner: security.
- Do the contract terms allocate responsibility acceptably? Owner: legal.
- Do we proceed, on these terms, at this price, by this date? Owner: procurement, on behalf of the business.
Each owner may need input from the others. What they do not need is joint ownership, which in practice means nobody chases anything.
Who needs what from whom
The handoffs are where reviews lose weeks, and almost all of them are the same three:
The business owner to everyone
Every function depends on an accurate description of what data will flow and for what purpose. When that description is wrong, all four assessments are wrong in the same direction, and the error is usually discovered after go-live.
Make the business owner accountable for the scope description, and make it a written artifact rather than a conversation. Our article on vendor onboarding privacy review treats this as the intake gate.
Privacy to legal
Legal cannot negotiate the right terms without knowing the transfer position and the sub-processor picture. A contract review that begins before the privacy assessment is complete tends to negotiate generic improvements rather than the specific provisions this vendor actually needs.
Sequence these for higher-tier vendors even though it costs elapsed time. For lower tiers, parallel is fine.
Security to privacy
Privacy's sufficiency judgment under Article 28(1) of the General Data Protection Regulation (GDPR) depends on security's assessment of the vendor's measures. Where security reports findings in its own language and severity scale, privacy frequently cannot tell whether a finding is material to the lawfulness question.
The fix is a translation step: security states, in one sentence per finding, what the finding means for the confidentiality, integrity, or availability of the specific data in scope.
One record, four views
Four functions working from four spreadsheets is the state most organizations are actually in, and it is the reason nobody can answer simple questions about a vendor without convening a meeting.
A shared record does not need to be elaborate. It needs to hold, per vendor:
- The scope description and the business owner.
- The role determination and lawful basis.
- The sub-processor position, captured with a date.
- The transfer destinations and mechanisms.
- The security assessment outcome and open findings.
- The contract status and the data protection terms in force.
- The decision, its conditions, the accepting owner, and the date.
- The review tier, the next review date, and the monitoring owner.
The last line is the one most often absent, and it is what turns an onboarding artifact into a lifecycle record.
Where the model breaks
No single accountable owner for the vendor
Functions own decisions; someone must own the relationship. Without a named vendor owner, nothing happens between reviews, and the escalation triggers described in prioritizing vendors for privacy review reach nobody.
Conditions without owners
Approvals with conditions are how most reviews end. A condition with no owner and no date is not a condition. Track them like any other work item, and make the next review check whether they were closed.
Security and privacy duplicating diligence
Both functions send questionnaires; the vendor answers twice; neither reads the other's responses. Merge the instrument, as our vendor privacy questionnaire suggests, and split the reading.
Procurement treated as an obstacle
Procurement holds the gate that makes the process real, because it controls signature. A review process that routes around procurement is a review process that will be routed around itself.
Making it work at renewal
Renewal is the moment the model pays off, because all four functions have a stake and the leverage is temporarily real. A renewal review should ask a short set of questions rather than repeating onboarding:
- Has the scope changed?
- Has the sub-processor chain or transfer position changed since the last review?
- Are there open conditions or findings from last time?
- Have the vendor's published data protection terms changed?
- Is the tier still right?
Three of those five are answerable from the vendor's own published disclosures, provided somebody has been watching them. The recurring cycle itself is covered in our recurring vendor review workflow.
Frequently asked questions
Who should chair the review?
Whoever owns the gate, usually procurement for onboarding and the vendor owner for renewal. The chair coordinates; it does not take the four decisions.
What if functions disagree?
Escalate to the business owner accepting the risk, with each function's position recorded. Documented disagreement resolved by an accountable decision-maker is a healthy outcome; an unrecorded compromise is not.
Do smaller organizations need four functions?
The four decisions still have to be taken, even where two or three of them sit with the same person. Write down which decision is being taken and on what basis, so the reasoning survives a change of staff.
How do we stop this becoming a committee?
Give each decision one owner, give the review a deadline by tier, and let silence past the deadline default to the owner's recommendation rather than to indefinite delay.
Where DPAFlow fits in
Between reviews, the facts all four functions depend on sit on vendor websites. DPAFlow 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 to the people who need them. Detected changes enter a review workflow where the team assesses materiality and documents its decision, which gives the four functions one shared, dated view of what changed and what was decided.
The decisions stay with your team, and DPAFlow does not provide legal advice. The workflows for privacy, legal, and vendor risk functions are described on the privacy use case page, the legal use case page, and the vendor risk use case page.
This article proposes an operating model. It is not legal advice, and the allocation of decisions should reflect your own governance structure.