A practical seven-step vendor risk assessment process with an inherent risk tiering matrix, a weighted control scoring model, a worked payroll vendor example and a map of what GDPR, DORA, NIS2, POPIA…
Last updated: 27 October 2026
A vendor risk assessment is a structured review of a supplier before you sign, and at set intervals afterwards, to decide whether the risk it brings to your data, systems and operations is acceptable. In practice it has seven steps: build an inventory, score inherent risk, tier the vendor, collect evidence, score the controls, decide on treatment, and monitor until offboarding. This guide gives you a tiering matrix, a weighted scoring model and a worked example you can copy into your own programme.
What a vendor risk assessment covers
A vendor risk assessment answers three questions:
- What could this vendor affect? The data it will hold, the systems it can reach and the business processes that depend on it. This is inherent risk, measured before you look at any of the vendor's controls.
- How well does the vendor manage that exposure? Its security, privacy, resilience and governance controls, backed by evidence rather than self-assertion.
- What is left, and is it acceptable? Residual risk after controls and any contract terms, compared with your risk appetite.
It is one part of a wider third-party risk management (TPRM) programme, which also covers vendor onboarding, contract management, ongoing monitoring and exit. Most teams run the assessment at onboarding, at renewal and whenever something material changes, such as a breach, an acquisition or a new use of personal data.
Why regulators expect it
Several laws and standards require you to assess suppliers before relying on them. The table below summarises the most common ones. It is not exhaustive, and sector rules (financial services, health, government) often add more.
| Requirement | What it asks for | Primary source |
|---|---|---|
| GDPR Article 28(1) | Controllers may only use processors "providing sufficient guarantees to implement appropriate technical and organisational measures". Article 28(3) lists the terms the processing contract must contain, including audit and information rights. | Regulation (EU) 2016/679, EUR-Lex |
| DORA Article 28 | EU financial entities must keep a register of information on all ICT service arrangements, and before contracting must assess whether the service supports a critical or important function, identify and assess all relevant risks including concentration risk, carry out due diligence and assess conflicts of interest. Exit strategies are required for critical or important functions (Article 28(8)). DORA has applied since 17 January 2025. | Regulation (EU) 2022/2554, EUR-Lex; Central Bank of Ireland |
| NIS2 Article 21(2)(d) and 21(3) | Essential and important entities must address "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers", taking into account each supplier's specific vulnerabilities and the quality of its cybersecurity practices, including secure development. | Directive (EU) 2022/2555, EUR-Lex |
| POPIA section 21 | A responsible party must, through a written contract, ensure that an operator processing personal information on its behalf establishes and maintains the security measures in section 19. The operator must notify the responsible party immediately if it has reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person. | Information Regulator, Condition 7: Security safeguards |
| ISO/IEC 27001:2022 Annex A | Controls 5.19 to 5.23 cover information security in supplier relationships, supplier agreements, the ICT supply chain, monitoring and change management of supplier services, and the use of cloud services. | ISO/IEC 27001:2022 |
If you operate in South Africa, our POPIA compliance guide explains how operator agreements fit into the wider POPIA programme.
The vendor risk assessment process, step by step
Step 1: Build and maintain a vendor inventory
You cannot assess what you have not listed. Pull vendors from accounts payable, procurement, expense reports, SSO and identity logs, and your data map. For each vendor, record at minimum:
- Legal entity name and country
- Business owner and the service provided
- Data categories shared (personal, special category, payment, confidential business data)
- System access (none, user-level, admin, network or API)
- Business processes that depend on it
- Contract dates and annual spend
- Known sub-processors or fourth parties
A spreadsheet works to start. Our free vendor risk register template gives you the columns above.
Step 2: Score inherent risk with an intake questionnaire
Before sending a long security questionnaire, the business owner completes a short intake form (10 to 15 questions) so you can score inherent risk. Score each factor from 0 to 3:
| Factor | 0 | 1 | 2 | 3 |
|---|---|---|---|---|
| Data sensitivity | No data shared | Business contact data only | Customer or employee personal data | Special category, financial, health or children's data, or large volumes |
| System access | None | Read-only, no internal network | User-level access to internal systems | Admin, privileged, network or production access |
| Operational criticality | Easily paused for weeks | Outage tolerable for days | Outage disrupts a key process within a day | Supports a critical function; outage stops revenue or regulated services |
| Regulatory exposure | None | General contract obligations | Processor or operator under a privacy law | In scope of DORA, NIS2, sector rules or cross-border transfer rules |
| Substitutability | Many alternatives, switch in days | Alternatives, switch in weeks | Few alternatives, switch in months | Sole or dominant provider, hard to exit |
Add the five scores for an inherent risk score out of 15.
Step 3: Assign a tier and match the depth of review
Tiering keeps effort proportionate. Use the total score, with two override rules: any vendor scoring 3 on data sensitivity or operational criticality is at least Tier 2, and any vendor supporting a critical or important function under DORA is Tier 1.
| Tier | Inherent score | Typical examples | Assessment depth | Reassessment |
|---|---|---|---|---|
| Tier 1: Critical | 11 to 15 | Core cloud hosting, payroll, payment processing, core banking | Full questionnaire, independent assurance (SOC 2 Type II or ISO 27001 certificate with Statement of Applicability), penetration test summary, business continuity evidence, contract review, exit plan | Annually, plus continuous monitoring |
| Tier 2: High | 7 to 10 | CRM, HR systems, marketing platforms holding customer data | Standard questionnaire, assurance report or certificate, data processing agreement review | Every 2 years |
| Tier 3: Moderate | 4 to 6 | Collaboration tools with limited data, niche SaaS | Short questionnaire, privacy and security policy review | Every 3 years or at renewal |
| Tier 4: Low | 0 to 3 | Office supplies, catering, no data or access | Intake form only | At renewal |
The reassessment frequencies are common practice rather than legal requirements. Set your own in your TPRM policy and apply them consistently.
Step 4: Collect evidence, not just answers
Send the questionnaire that matches the tier. Industry-standard question sets such as the Shared Assessments SIG or the CSA CAIQ reduce friction because many vendors have already completed them. Whatever you use, cover these domains:
- Governance: security and privacy ownership, policies, staff vetting and training
- Access control: MFA, privileged access, joiner-mover-leaver process
- Data protection: encryption at rest and in transit, retention and deletion, data location and transfers
- Application and infrastructure security: vulnerability management, patching, secure development, penetration testing
- Incident response: detection, notification timelines to customers, past incidents
- Resilience: backups, business continuity and disaster recovery testing, recovery time objectives
- Fourth parties: sub-processor list, how the vendor assesses its own suppliers
- Privacy: lawful role (processor, operator or controller), assistance with data subject requests, cross-border transfer mechanisms
Ask for documents that prove the answers: an in-date SOC 2 Type II report (check the period it covers and any exceptions), an ISO 27001 certificate together with its scope, the latest penetration test summary, the sub-processor list and a sample incident notification clause.
Step 5: Score control effectiveness
Rate each domain on a 1 to 4 scale and weight it according to what matters for this vendor:
| Rating | Meaning |
|---|---|
| 4: Strong | Control in place, independently verified, no material exceptions |
| 3: Adequate | Control in place and evidenced by the vendor; minor gaps |
| 2: Weak | Partial control, unevidenced, or exceptions in the assurance report |
| 1: Missing | No control, or answer contradicts the evidence |
Default weights: access control 20%, data protection 20%, incident response 15%, resilience 15%, application and infrastructure security 15%, fourth parties 10%, governance 5%. Shift weight towards resilience for operationally critical vendors and towards data protection for vendors holding sensitive personal data.
Control score = sum of (rating x weight). A result of 3.0 or more is generally acceptable; 2.5 to 2.9 needs remediation conditions; below 2.5 needs senior sign-off or rejection.
Step 6: Decide on treatment and record it
Combine inherent tier and control score into a residual risk decision:
| Control score 3.0 or more | 2.5 to 2.9 | Below 2.5 | |
|---|---|---|---|
| Tier 1 | Accept with monitoring | Remediate before go-live or accept with time-bound conditions | Reject or escalate to executive risk owner |
| Tier 2 | Accept | Accept with conditions | Remediate before go-live |
| Tier 3 and 4 | Accept | Accept | Accept with conditions |
Treatment options are the standard four: accept, mitigate (contract terms, compensating controls on your side, remediation plan), transfer (insurance, indemnities) or avoid (choose another vendor). Record every condition as a tracked issue with an owner and due date, not as a comment in an email.
Use the contract to close gaps the questionnaire found: breach notification timelines, audit rights, sub-processor approval, data return and deletion at exit, and for DORA-scope services the provisions in Article 30.
Step 7: Monitor, reassess and offboard
An assessment is a snapshot. Between reviews, watch for:
- Expiry of SOC 2 reports and ISO certificates
- Breach disclosures, regulator actions and negative news
- Changes in ownership, sub-processors or data location
- Scope creep: the vendor now holds more data or supports more processes than when it was assessed
Any of these should trigger an early reassessment. At exit, confirm data return or deletion in writing and revoke all access.
Worked example: a payroll SaaS provider
A 400-person company is onboarding a cloud payroll provider.
Inherent risk: Data sensitivity 3 (salary, bank details, tax numbers), system access 1 (no access to internal network; HR uploads files), operational criticality 3 (staff must be paid on time), regulatory exposure 2 (processor under GDPR and operator under POPIA), substitutability 2 (switching takes a quarter). Total 11: Tier 1.
Control ratings: access control 4 (SSO, MFA enforced, SOC 2 Type II with no exceptions), data protection 3 (encryption verified; retention policy vague), incident response 2 (contract offers notification "without undue delay" but no fixed timeline), resilience 3 (DR tested annually, RTO 24 hours), application security 4, fourth parties 2 (sub-processor list provided but no evidence of how they are assessed), governance 3.
Weighted score: (4 x 0.20) + (3 x 0.20) + (2 x 0.15) + (3 x 0.15) + (4 x 0.15) + (2 x 0.10) + (3 x 0.05) = 0.80 + 0.60 + 0.30 + 0.45 + 0.60 + 0.20 + 0.15 = 3.10.
Decision: Tier 1 with a score of 3.10, so accept with monitoring. Two conditions still go into the issue register: a fixed incident notification timeline in the contract, and written confirmation of how the provider assesses its sub-processors, both due before the first payroll run. Reassessment is set for 12 months, with an alert when the SOC 2 report expires.
Common mistakes
- One questionnaire for every vendor. Sending 300 questions to a catering supplier wastes everyone's time and teaches the business to route around you. Tier first.
- Accepting answers without evidence. "Yes, we encrypt data" is not evidence. Ask for the assurance report and read the exceptions section.
- Ignoring the SOC 2 scope. A report that covers the vendor's corporate IT but not the product you are buying tells you little.
- No owner for conditions. Remediation items that live in email threads are never closed.
- Assess once, never again. Vendors change. Without reassessment dates and triggers, your inventory drifts from reality within a year.
- Forgetting fourth parties. Your payroll provider's hosting company is part of your risk too.
Vendor risk assessment checklist
- Vendor added to inventory with owner, data, access and spend
- Intake form completed and inherent risk scored
- Tier assigned, including override rules
- Tier-appropriate questionnaire sent and evidence received
- Assurance reports checked for scope, period and exceptions
- Control score calculated and residual risk decision recorded
- Conditions logged as issues with owners and due dates
- Contract includes security, breach notification, audit, sub-processor and exit terms
- Reassessment date and monitoring triggers set
- Exit and data deletion steps documented
Frequently asked questions
What is the difference between a vendor risk assessment and third-party risk management?
A vendor risk assessment is a point-in-time evaluation of one supplier. Third-party risk management is the ongoing programme around it: inventory, tiering, assessments, contracts, monitoring, issue tracking and offboarding across all suppliers.
How often should you reassess vendors?
Base it on tier. A common pattern is annually for critical vendors, every two years for high-risk vendors and at renewal for the rest, with early reassessment after a breach, acquisition or change in services. Frameworks such as DORA and ISO 27001 expect ongoing monitoring of supplier services, so document whatever cadence you choose.
What should a vendor risk assessment questionnaire include?
Governance, access control, data protection, application and infrastructure security, incident response, resilience, fourth-party management and privacy. Scale the length to the vendor's tier and always request evidence for the answers that matter most.
Is a SOC 2 report enough on its own?
Rarely. A SOC 2 Type II report is strong evidence for the controls and period it covers, but you still need to check that its scope includes the service you are buying, review any exceptions, and assess areas it may not address in depth, such as privacy obligations, data location and exit.
Who should own vendor risk assessments?
Usually a TPRM, security or risk team runs the process, with procurement triggering it, the business owner completing the intake and accepting residual risk, and privacy and legal reviewing data processing terms. The key is that each decision has a named owner.
Do small companies need a vendor risk assessment process?
Yes, if they share personal data or rely on suppliers for critical services. GDPR Article 28 and POPIA section 21 apply regardless of company size. A lightweight version (inventory, intake scoring and evidence for your top vendors) covers most of the risk.
Run vendor assessments in one place
Core GRC's Privacy, Risk & Compliance Suite includes third-party risk management: a vendor register, tiered assessment templates, risk and issue registers for tracking conditions, and data mapping that shows which vendors hold which personal data. Core IQ, our AI assistant, helps review vendor responses and evidence so your team can focus on decisions. See how to add your first vendor or talk to our team.
