A vendor risk assessment determines what a supplier can affect, how credible and severe the resulting risk is, whether proposed controls and contract terms are adequate, and who accepts any residual risk. The assessment should be proportionate to access, data, service impact, concentration and substitutability—not a fixed questionnaire sent to every supplier.
Regulatory relevance depends on context. GDPR Article 28 applies when a vendor is a processor and requires sufficient guarantees plus specified contract terms. NIS2 Article 21 requires in-scope entities to address supply-chain security, including relationships with direct suppliers or service providers. DORA contains specific ICT third-party risk rules for covered financial entities. None makes every vendor subject to the same review.
1. Define the relationship and inherent risk
Before sending questions, document:
- the service, business owner and legal entities involved;
- information types, processing purposes and locations;
- network, system, facility and privileged access;
- availability, safety, integrity and recovery dependencies;
- subcontractors and material fourth parties;
- concentration, lock-in and viable alternatives;
- legal, regulatory and contractual requirements; and
- the effect of failure, compromise or exit.
Use this inherent-risk view to select the depth of evidence, approval and monitoring. A supplier with no sensitive access can still be critical because its outage stops an essential service.
2. Request evidence that answers the risk
Combine targeted questions with independent evidence where justified:
| Risk area | Examples of useful evidence |
|---|---|
| Governance | Named owners, risk process, policy approval, exceptions |
| Access | Authentication scope, privileged access, reviews, termination |
| Security operations | Asset coverage, vulnerability handling, logging, incident process |
| Resilience | Dependency map, backup and restore evidence, continuity tests |
| Privacy | Roles, instructions, subprocessors, transfers, deletion support |
| Development | Change control, secure development, vulnerability disclosure |
| Assurance | Relevant audit report or certificate with scope and validity |
| Exit | Data return, deletion, portability, credential removal, assistance |
Read assurance evidence critically. For a SOC 2 report, review report type, period, system boundary, opinion, exceptions, subservice organisations and complementary user-entity controls. For ISO/IEC 27001, verify the certified entity, standard edition, scope, sites, validity, certification body and accreditation relevance.
3. Validate, score and decide
Score risk, not presentation quality. Define likelihood and impact criteria in advance and record confidence in the evidence. Separate:
- inherent risk before vendor controls;
- control design and implementation findings;
- residual risk after current controls and contract terms; and
- planned risk after agreed remediation.
A total numeric score can hide a critical single issue. Use decision gates for unacceptable conditions such as unapproved privileged access, no workable recovery, prohibited data location or refusal to notify material incidents.
Each finding needs evidence, affected requirement, risk, action, owner, due date and decision authority. Risk acceptance should expire or be reviewed when facts change.
4. Put controls into the contract
Contract requirements may cover permitted use and access, security measures, confidentiality, subprocessors, material changes, incident timing and cooperation, evidence or audit access, vulnerability handling, continuity, recovery objectives, data return and deletion, termination assistance and allocation of responsibility. Qualified counsel should adapt terms to the relationship and jurisdiction.
Do not promise that a right to audit will solve weak pre-contract due diligence. It must be usable, proportionate and supported by meaningful evidence access.
5. Monitor by trigger and risk
Set review cadence from criticality, change rate, evidence expiry, incidents and obligations. Trigger reassessment for major architecture, ownership, location, subprocessor, product, control, contract or threat changes. Monitor service performance, reported incidents, unresolved findings and changes to relevant assurance.
There is no universal “annual for critical, every three years for low risk” legal rule across all vendors. Document why the selected cadence is proportionate.
6. Prepare for incidents and exit
Add supplier incidents to internal response exercises. Confirm contacts, information flow, evidence preservation, customer or authority support and decision rights when facts are incomplete. Your own legal reporting deadline may start before a supplier finishes its investigation.
Maintain exit plans for material dependencies: alternatives, data export, transition time, knowledge transfer, credentials, deletion evidence, licences and continuity arrangements. Test portability where switching would be difficult.
For programme design and high-risk assessments, see our vendor-risk services.
Sources and review
This guide was substantively reviewed on 8 August 2026. It removes breach anecdotes and universal review frequencies and qualifies GDPR, NIS2 and DORA applicability.
Ivana Ludiga, mag. iur., is an Associate at Vision Compliance focused on data protection, GDPR implementation, and regulatory advisory. She supports compliance projects for organizations across healthcare, financial services, and technology sectors.