A vendor risk assessment turns what you know about a supplier into a decision you can defend. It sits between diligence, which gathers facts, and approval, which commits the organization. This article covers the assessment itself: how to convert findings into a risk position, what to weigh, and how to record the result so it survives scrutiny.
Two related pieces sit either side of it. The facts you gather are covered in the GDPR vendor due diligence checklist, and the process that carries an assessment from intake to approval is in vendor onboarding privacy review.
Assess the processing, not the company
The most common analytical error is assessing the vendor as an entity. A supplier is not risky or safe in the abstract. The same supplier can be an appropriate home for one data set and an unacceptable one for another.
Anchor the assessment to a specific processing activity: this data, for this purpose, in this configuration. When the business later wants to send a different category of data to the same vendor, that is a new assessment rather than a reuse of the old one.
Inherent risk before controls
Start with the exposure that exists before any mitigation, because that is what determines how much assurance you need.
Four factors carry most of the weight:
- Data sensitivity: special category data under Article 9 of the General Data Protection Regulation (GDPR), criminal offence data under Article 10, financial data, or data about children raise exposure sharply.
- Volume and population: the number of data subjects, and whether they are employees, customers, or members of the public who never chose the relationship.
- Access pattern: whether the vendor stores the data, merely transmits it, or has staff who can read it.
- Consequence of failure: what actually happens to people if this data leaks, is altered, or becomes unavailable.
Rate these consistently. The scale matters less than applying the same scale to every vendor, because the purpose is comparability rather than precision.
Then the control picture
Against that exposure, assess what the vendor actually offers. Three questions do most of the work.
Are the guarantees sufficient?
Article 28(1) permits the use of processors providing sufficient guarantees that processing will meet the regulation's requirements. Sufficiency is relative to the exposure you just rated. Documentation that is adequate for a low-sensitivity marketing tool is not adequate for a system holding health data.
Look for specificity. Security statements that describe measures in testable terms carry weight. Statements that describe intentions do not.
Is the chain visible?
A vendor that publishes a complete, current sub-processor list with locations has given you something to assess. A vendor that names categories without entities, or publishes nothing, has not. The European Data Protection Board's Guidelines 07/2020 treat the controller's duty as extending to how the processor manages its own chain, so opacity at that layer is a finding in itself. Our article on evaluating a sub-processor list covers what completeness looks like.
Is the position maintainable?
Assess whether you will be able to tell when this changes. A vendor that commits to advance notice of sub-processor changes, and publishes a page you can watch, is a lower operational risk than one that reserves the right to change silently, even if today's snapshots look identical.
Residual risk and the decision
Residual risk is what remains after the controls and the contract. Express it as a decision rather than a score:
- Accept: proceed as presented, with the assessment recorded.
- Accept with conditions: proceed once specified changes or compensating steps are in place, each with an owner and a date.
- Mitigate before proceeding: the flow is not permitted until a structural change is made, such as reducing the data set, changing the region, or altering the configuration.
- Reject: the processing cannot be made appropriate on available terms.
A score with no decision attached is an artifact, not an assessment. Whoever accepts residual risk should be named, and should be senior enough that the acceptance means something.
Reassessment triggers
An assessment describes a moment. Define in advance what invalidates it:
- A new sub-processor, particularly one in a third country.
- A change of transfer mechanism.
- A change in the data set or purpose.
- A corporate event such as an acquisition or restructuring.
- A security incident at the vendor or in its chain.
- The elapse of the review interval for the vendor's tier.
The first two are the triggers that occur most often and are noticed least, because they happen on the vendor's website rather than in your systems. Our articles on why sub-processor lists change and monitoring sub-processor changes cover that pattern.
What the record must contain
For each assessment, retain the processing scope, the inherent risk rating with reasoning, the control findings with the evidence they rest on, the residual position, the decision, the accepting owner, and the date. Capture vendor disclosures as they stood rather than linking to pages that will change. The evidence standard is covered in audit-ready vendor evidence.
Frequently asked questions
Should we use a numeric risk score?
Numbers help comparison and hurt when they replace reasoning. If you use a score, keep the narrative alongside it. A reviewer two years from now needs to know why a vendor scored as it did, not merely that it did.
How is this different from a data protection impact assessment?
A vendor risk assessment examines a supplier relationship. A data protection impact assessment under Article 35 examines a processing operation likely to result in high risk to individuals, and may cover several vendors or none. They inform each other but answer different questions.
Who should accept residual risk?
Someone accountable for the business outcome, not the reviewer. Privacy and security advise; the business owner accepts. Blurring that line is how organizations end up with risk accepted by people who cannot bear it.
Do low-risk vendors need this at all?
They need a recorded determination that they are low risk, with the reasoning. That record is short, and it is what makes the tiering defensible.
Where DPAFlow fits in
Reassessment triggers are only useful if they reach you. 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. Detected changes enter a review workflow where your team decides whether the change invalidates the assessment.
The risk judgment stays with your team, and DPAFlow does not provide legal advice. How this fits procurement and vendor risk functions is described on the vendor risk use case page.
This article sets out an assessment method. It is not legal advice, and risk acceptance decisions belong to your organization.