Vendor Risk
Vendors are classified based on data sensitivity, production access, availability dependency, customer impact, and control reliance.
Use this guide to put the control into operation, decide what records to retain, and check that an auditor can trace the evidence back to the work your team performed.
Maintained by GreenHat Security · Reviewed August 21, 2026
Vendor review depth and frequency reflect the real risk created by data sensitivity, production access, service dependency, customer impact, and reliance on the vendor’s controls.
First SOC 2 program
Use a short scoring rubric with a few observable factors: sensitive data, privileged or production access, outage impact, customer-facing dependency, substitutability, and control reliance. Have security validate the business owner’s answers before assigning a tier.
As the company scales
Automate initial scoring from procurement, data, access, architecture, and contract facts, add risk-specific decision rules, require review of overrides, and trigger reclassification when vendor usage or service criticality changes.
Specify how data sensitivity, production access, availability dependency, customer impact, control reliance, concentration, and recoverability influence classification.
You should end up with: Approved factor definitions with clear answer choices and required supporting facts.
Map factor combinations to risk tiers and define the due-diligence depth, approvers, review frequency, contract terms, and monitoring expected for each tier.
You should end up with: A classification method that leads to distinct, risk-based treatment paths.
Ask the business and technical owners what the vendor does, which data and systems it touches, what happens if it fails, and whether customers or controls depend on it.
You should end up with: A completed vendor profile with source links for material answers.
Apply the method consistently, have security or vendor-risk personnel challenge ambiguous answers, and document any override and its approval.
You should end up with: A dated classification record with score, tier, rationale, reviewer, and approved override where applicable.
Use the tier to assign security review, contract, monitoring, reassessment, access, continuity, and approval requirements.
You should end up with: A vendor review plan and due dates derived from the assigned tier.
Repeat classification when data use, access, integrations, product reliance, ownership, scope, incident history, or customer impact changes.
You should end up with: Versioned classification history and completed follow-up when a tier changes.
Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.
Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.
Documents that define the control, its scope, ownership, and expected way of working.
Confirm what the record proves
Vendor classifications follow approved, observable factors for data sensitivity, production access, service dependency, customer impact, control reliance, and recovery difficulty.
Include this context
risk factor definitions
Include this context
answer choices or thresholds
Include this context
tier calculation rules
Include this context
treatment by tier
Include this context
override authority
Include this context
version and approval date
Weak evidence to avoid
A low-medium-high dropdown with no defined factors, scoring thresholds, treatment differences, override authority, or approved methodology version.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
Each vendor’s tier was calculated from documented current-use facts, validated by an appropriate reviewer, and supported where an override changed the result.
Include this context
vendor and classification identifier
Include this context
factor responses
Include this context
calculated and final tier
Include this context
response evidence or rationale
Include this context
reviewer and decision date
Include this context
override and approval if applicable
Weak evidence to avoid
A vendor marked low risk because it is a well-known company, without factor responses, calculated result, data or access facts, reviewer, or override approval.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
Classification inputs accurately describe the vendor’s service, data, access, integration, availability impact, customer reliance, and current scope of use.
Include this context
service and intended use
Include this context
data categories
Include this context
system and privilege access
Include this context
integration and product scope
Include this context
outage or customer impact
Include this context
profile owner and review date
Weak evidence to avoid
A profile saying productivity software with no data categories, integration, access, affected product, outage impact, or owner validation.
Type 1
The current approved tiering criteria, configured classification workflow, current vendor profiles, and one recent calculation including override handling as of the examination date.
Type 2
Every initial classification and reclassification completed or due during the review period, plus every vendor-use change in data, access, integration, service dependency, or customer impact that required a tier decision.
Reconcile new vendors and material vendor-change events to completed classification records, recompute the tier from retained factor responses, and compare high-impact architecture, data, and access facts to the vendor profile for missed reclassification triggers.
Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.
Determine whether the control is designed to achieve this result: Vendor review depth and frequency reflect the real risk created by data sensitivity, production access, service dependency, customer impact, and reliance on the vendor’s controls.
Compare the documented owner with the intended role (Vendor Risk Owner / CISO / Legal), then compare dated records with the stated cadence: Prior to onboarding; periodic based on risk; at least annually for critical/high.
Reconcile new vendors and material vendor-change events to completed classification records, recompute the tier from retained factor responses, and compare high-impact architecture, data, and access facts to the vendor profile for missed reclassification triggers.
The current approved tiering criteria, configured classification workflow, current vendor profiles, and one recent calculation including override handling as of the examination date.
Every initial classification and reclassification completed or due during the review period, plus every vendor-use change in data, access, integration, service dependency, or customer impact that required a tier decision.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates Vendor classifications follow approved, observable factors for data sensitivity, production access, service dependency, customer impact, control reliance, and recovery difficulty.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates Each vendor’s tier was calculated from documented current-use facts, validated by an appropriate reviewer, and supported where an override changed the result.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates Classification inputs accurately describe the vendor’s service, data, access, integration, availability impact, customer reliance, and current scope of use.
Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.
These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.
Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.