Vendor risk management vs vendor risk assessment
Vendor risk management is the ongoing program: inventory, tiering, assessment, contracting, monitoring and exit. A vendor risk assessment is one step inside it: the structured evaluation of a specific vendor’s risks and controls at onboarding and at each reassessment.
The assessment is where most work happens, and where quality varies most. A strong assessment does not just collect answers; it checks them.
For a ready-to-use checklist covering each step of the assessment, see Vendor Risk Assessment Checklist: A Third-Party Risk Template with Scoring. For a step-by-step checklist for reviewing a vendor’s SOC 2 report, see How to Review a Vendor SOC 2 Report: A 10-Point Checklist for 2026.
For the security side of vendor assessments in detail, see Vendor Security Assessment: Process, Evidence and Software.
Step 1: Tier the vendor
Depth should follow risk. Rate inherent risk before looking at the vendor’s controls:
| Factor | Higher risk when |
|---|---|
| Data access | Sensitive personal, financial, health or regulated data |
| System access | Network, privileged or production access |
| Criticality | Outage would stop a critical process |
| Regulatory relevance | Vendor performs a regulated activity on your behalf |
| Customer impact | Vendor touches customers directly |
| Substitutability | Hard or slow to replace |
A common outcome is three tiers, with the top tier getting full document review and possibly an audit, and the bottom tier a short questionnaire.
Step 2: Send the right questionnaire
Standard questionnaires save time on both sides. Examples include the Shared Assessments SIG and the Cloud Security Alliance’s Consensus Assessment Initiative Questionnaire (CAIQ). The CAIQ is a set of yes/no questions built on CSA’s Cloud Controls Matrix that provides “an industry-accepted way to document what security controls exist in IaaS, PaaS, and SaaS services”; its STAR Level 1 version is a self-assessment published to CSA’s STAR Registry.
The weakness of every questionnaire is the same: it is self-reported. Treat answers as claims to verify.
Step 3: Verify against evidence
| Claim in questionnaire | Evidence to request |
|---|---|
| ”We have an independent audit” | SOC 2 Type 2 report or ISO/IEC 27001 certificate with scope |
| ”Data is encrypted” | Policy, architecture description, SOC 2 control descriptions and test results |
| ”We test incident response” | Plan and records of the latest test |
| ”We have business continuity plans” | Plan, test results, recovery objectives |
| ”We manage our subcontractors” | Subcontractor list and oversight procedure |
| ”We have cyber insurance” | Certificate of insurance |
| ”Staff are background checked and trained” | Policy and attestation |
Step 4: Read the SOC 2 report properly
A SOC 2 report is often the most valuable document in the file and the least carefully read. PYA, a CPA firm, sets out the key checks in a July 2026 guide:
- Scope. Does the report cover the service and system you actually use?
- Type and period. A Type 1 report reflects a point in time; a Type 2 covers a period, typically 6 to 12 months, and supports conclusions about whether controls operated effectively.
- Opinion. Language such as “except for” signals a qualified opinion that needs follow-up.
- Exceptions. Do control deviations affect processes you rely on? Have they been remediated?
- Complementary user entity controls (CUECs). Controls the report assumes you perform. Map them to your own controls.
- Bridge letters. If the period ended months ago, ask the vendor to represent any significant control changes since.
Also check which subservice organizations (for example cloud hosting) are excluded from the report’s scope and whether you need their reports too.
Step 5: Score residual risk and decide
| Inherent risk | Control evidence | Typical outcome |
|---|---|---|
| High | Strong, verified | Approve; monitor per tier |
| High | Gaps with remediation plan | Approve with conditions and contract terms; follow up |
| High | Significant unverified gaps | Escalate; decline or require remediation first |
| Low | Adequate | Approve; light monitoring |
Record the rationale, not just the score. US banking guidance asks organizations to “identify and document any limitations of its due diligence,” which is good practice everywhere.
Vendor risk ratings and outside-in monitoring
Security rating services score vendors from external data such as exposed services and known vulnerabilities. They are useful for monitoring large vendor populations between assessments. They do not see inside the vendor, so they complement rather than replace document-based assessment. Verizon’s 2026 DBIR found 31% of breaches started with vulnerability exploitation, which is one reason external signals are worth watching.
Common weaknesses
- Questionnaires accepted without evidence
- SOC 2 reports filed without reading exceptions or CUECs
- Out-of-scope services assumed to be covered
- Expired certificates and stale reports
- Findings not carried into contracts or follow-up
- Every vendor assessed at the same depth
Vendor risk assessment checklist
- Inherent risk tier assigned with rationale
- Questionnaire matched to tier
- Key answers verified against documents
- SOC 2 scope, type, period, opinion, exceptions and CUECs reviewed
- Bridge letter obtained where the report period is stale
- Subservice organizations identified
- Residual risk scored with documented rationale and limitations
- Conditions carried into contract and follow-up
- Reassessment date set
Verify vendor evidence with AskDona
Vendor assessments are mostly reading and cross-checking. AskDona reads the questionnaire, SOC report, certificates, policies and contract together against your criteria, flags answers the evidence does not support, out-of-scope services, SOC exceptions and missing CUEC mappings, and links each finding to the page it came from. Run a sample vendor assessment on one high-tier vendor. AskDona shows the evidence; your risk team decides.
FAQ
What is a vendor risk assessment? A structured evaluation of a vendor’s risks and controls, scaled to how much risk the relationship carries, done before onboarding and at reassessment.
What should a vendor risk assessment include? Inherent risk tiering, a questionnaire, verification against documents such as SOC 2 reports and certificates, residual risk scoring and a documented decision.
Is a SOC 2 report enough? Not alone. Check that it covers your service, read the exceptions and CUECs, and confirm the period is current.
What is the difference between vendor risk management and TPRM? They overlap. TPRM covers all third parties (including agents, distributors and partners); vendor risk management focuses on suppliers of goods and services.
How often should vendors be reassessed? By tier: often annually for the highest tier, less often for low-risk vendors, and whenever something significant changes.
References
All pages opened and checked by October 14, 2026.
| Source | Type | Used for |
|---|---|---|
| CSA, STAR Level 1: Security Questionnaire (CAIQ v4) | Industry body | CAIQ description |
| PYA, How to Review a SOC Report for TPRM (July 2026) | CPA firm guide | SOC report review steps |
| Federal Register, Interagency Guidance on Third-Party Relationships | US guidance | Documenting limitations |
| Verizon, 2026 DBIR release (May 19, 2026) | Industry report | Vulnerability exploitation statistic |