Vendor Risk
All vendors and third parties are recorded in an approved inventory with owner, service description, data access, customer impact, contract status, review dates, and risk tier.
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
The company can identify every active vendor and third party, what service each provides, who owns the relationship, what data or access is involved, how customers could be affected, and when review is due.
First SOC 2 program
Build one vendor inventory by reconciling accounting payments, company cards, cloud accounts, identity applications, contracts, and team interviews. Require a business owner, service description, data and access profile, contract status, risk tier, and next review date before a vendor is considered complete.
As the company scales
Make procurement the front door for new vendors and integrate purchasing, identity, contract, privacy, service catalog, and vendor-risk systems so additions, ownership changes, renewals, and terminations update the inventory through governed workflows.
Set inclusion rules for paid and unpaid third parties, cloud services, contractors, subprocessors, data recipients, managed services, and providers embedded in the product.
You should end up with: A documented inventory scope and accountable inventory owner.
Compare accounting, company-card, contract, identity, browser or software, cloud, privacy, and engineering records to find active third parties.
You should end up with: A reconciled candidate list with source and discovery date.
For each active vendor, record legal and product names, business owner, service, data handled, system access, customer impact, integration, contract dates, risk tier, status, and review dates.
You should end up with: A normalized inventory with required fields and links to supporting records.
Ask business and technical owners to confirm that the vendor is active, the service and data flows are accurate, and the recorded access and customer dependency reflect current use.
You should end up with: Dated owner attestations and resolved discrepancies.
Require vendor intake before purchase or technical connection and update records when scope, data use, access, owner, tier, contract, or service dependency changes.
You should end up with: Intake and change records linked to updated inventory entries.
Repeat source comparisons, investigate unmatched vendors and unused accounts, and remove or mark terminated providers only after offboarding is complete.
You should end up with: A dated reconciliation with additions, corrections, terminations, and documented follow-up.
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
Active vendors and third parties are centrally recorded with ownership, service, data, access, customer impact, contract, risk tier, and review status.
Include this context
vendor legal and product names
Include this context
service and business owner
Include this context
data and system access
Include this context
customer or product impact
Include this context
risk tier and status
Include this context
contract and review dates
Weak evidence to avoid
An accounts-payable vendor export containing names and spend but no service description, owner, data, access, customer dependency, tier, or review date.
Confirm what the record proves
A current business owner accepts responsibility for each vendor’s use, inventory facts, periodic review, renewal, incidents, and eventual termination.
Include this context
vendor identifier
Include this context
primary business owner
Include this context
technical or service owner
Include this context
assignment date
Include this context
owner confirmation
Include this context
last review date
Weak evidence to avoid
A vendor assigned to IT after the original requester left, with no named accountable person, confirmation, technical owner, or assignment review date.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
New vendors entered the governed intake process before purchase or connection and completed the required ownership, classification, review, contract, and approval steps.
Include this context
intake and vendor identifier
Include this context
requester and business owner
Include this context
service and intended use
Include this context
request and approval dates
Include this context
required review status
Include this context
activation or purchase date
Weak evidence to avoid
A procurement ticket opened after a cloud service was already paid for and connected, with no data profile, risk review, approvals, or activation date.
Type 1
The current vendor inventory with required-field configuration, active owner assignments, current intake workflow, and the latest reconciliation result as of the examination date.
Type 2
Every vendor active at any point during the review period, every vendor intake or purchase initiated during the period, and every vendor added, changed, reactivated, or terminated in the inventory during the period.
Reconcile the inventory to vendor payments, company-card merchants, active contracts, identity applications, cloud accounts, and known subprocessors; investigate every unmatched source record and every inventory entry with no current-use signal.
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: The company can identify every active vendor and third party, what service each provides, who owns the relationship, what data or access is involved, how customers could be affected, and when review is due.
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 the inventory to vendor payments, company-card merchants, active contracts, identity applications, cloud accounts, and known subprocessors; investigate every unmatched source record and every inventory entry with no current-use signal.
The current vendor inventory with required-field configuration, active owner assignments, current intake workflow, and the latest reconciliation result as of the examination date.
Every vendor active at any point during the review period, every vendor intake or purchase initiated during the period, and every vendor added, changed, reactivated, or terminated in the inventory during the period.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates Active vendors and third parties are centrally recorded with ownership, service, data, access, customer impact, contract, risk tier, and review status.
For each selected record, confirm it demonstrates A current business owner accepts responsibility for each vendor’s use, inventory facts, periodic review, renewal, incidents, and eventual termination.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates New vendors entered the governed intake process before purchase or connection and completed the required ownership, classification, review, contract, and approval steps.
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.