Vendor Risk
Subprocessors and data-processing vendors are approved, tracked, and governed according to customer commitments and data protection obligations.
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 knows which external providers process customer or company data, approves their use before processing begins, governs them according to applicable commitments, and communicates changes when required.
First SOC 2 program
Maintain one internal subprocessor list that states the service, processing purpose, data categories, product use, location, relationship owner, and agreement status. Review additions with security, privacy, legal, and product owners before data is shared.
As the company scales
Connect procurement, privacy, data mapping, architecture, contracts, public disclosures, and customer-notice workflows so new providers and material processing changes cannot enter production without approval and required communication.
Review product architecture, data flows, cloud services, integrations, support tools, analytics, contractors, and vendor-provided external providers to identify organizations that receive or process relevant data.
You should end up with: A reconciled internal subprocessor and data-processing inventory.
Record legal entity, service, purpose, data categories, data subjects, product scope, processing and storage locations, onward providers, owner, and active dates.
You should end up with: A complete provider record linked to architecture and data-flow evidence.
Have security, privacy, legal, product, and service owners assess safeguards, intended data use, locations, transfer considerations, customer terms, and technical integration before processing begins.
You should end up with: A dated approval or rejection with required safeguards and conditions.
Execute applicable data and security terms, address external-provider flow-downs, allocate responsibilities, and record deletion, incident, access, and change-notification duties.
You should end up with: Executed agreements and an obligation record linked to the provider.
Keep customer-facing disclosures consistent with the internal inventory and issue advance or event-based notices according to applicable commitments and approved communication rules.
You should end up with: Versioned disclosure content and proof of required customer notification.
Reassess new purposes, data types, products, locations, external providers, transfers, incidents, and termination, updating records and customer communications as needed.
You should end up with: Change history, approvals, notices, and completed offboarding evidence.
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
External providers that process relevant customer or company data are identified with their legal entity, purpose, data, product scope, location, owner, and active status.
Include this context
provider legal and product names
Include this context
processing purpose
Include this context
data categories and subjects
Include this context
product or service scope
Include this context
processing and storage locations
Include this context
owner and active dates
Weak evidence to avoid
A public list of vendor logos with no legal entities, processing purposes, data categories, locations, affected products, owners, or active dates.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
Security, privacy, legal, product, and service owners approved the processing relationship and applicable data terms before the provider received data.
Include this context
provider and processing activity
Include this context
data and location scope
Include this context
security and privacy review
Include this context
required approvers
Include this context
approval and first-use dates
Include this context
agreement status
Weak evidence to avoid
A data addendum stored after integration launch with no internal approval, data-flow scope, security review, execution status, or comparison of approval and first-use dates.
Confirm what the record proves
Relevant cross-border or onward data transfers were evaluated using the actual parties, locations, data, purpose, legal mechanism, safeguards, and residual considerations.
Include this context
exporter, importer, and onward parties
Include this context
data and processing purpose
Include this context
origin and destination locations
Include this context
transfer mechanism
Include this context
risk and safeguards
Include this context
reviewer and decision date
Weak evidence to avoid
A country name marked approved with no data categories, exporter or importer, transfer mechanism, onward providers, safeguards, reviewer, or decision rationale.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
Affected customers received required notice of a new or changed subprocessor through the correct channel and timing, with the final content and recipient population retained.
Include this context
provider change and effective date
Include this context
applicable customer population
Include this context
notice requirement and deadline
Include this context
final message
Include this context
send timestamp and channel
Include this context
delivery or response status
Weak evidence to avoid
A blog post announcing a provider after processing began with no contract-based audience, required lead time, send record, delivery status, or customer response handling.
Type 1
The current internal subprocessor list, current customer-facing disclosure, configured provider-approval workflow, applicable executed data terms, and a current transfer assessment as of the examination date.
Type 2
Every data-processing provider active at any time during the period and every provider addition, removal, new purpose, new data category, location change, onward-provider change, approval, or customer-notice event during the period.
Reconcile providers in product architecture, data flows, vendor records, and executed data terms to the internal list, compare the internal list to customer-facing disclosures, and trace each change to prior approval and any required timely notice.
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 knows which external providers process customer or company data, approves their use before processing begins, governs them according to applicable commitments, and communicates changes when required.
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 providers in product architecture, data flows, vendor records, and executed data terms to the internal list, compare the internal list to customer-facing disclosures, and trace each change to prior approval and any required timely notice.
The current internal subprocessor list, current customer-facing disclosure, configured provider-approval workflow, applicable executed data terms, and a current transfer assessment as of the examination date.
Every data-processing provider active at any time during the period and every provider addition, removal, new purpose, new data category, location change, onward-provider change, approval, or customer-notice event during the period.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates External providers that process relevant customer or company data are identified with their legal entity, purpose, data, product scope, location, owner, and active status.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates Security, privacy, legal, product, and service owners approved the processing relationship and applicable data terms before the provider received data.
For each selected record, confirm it demonstrates Relevant cross-border or onward data transfers were evaluated using the actual parties, locations, data, purpose, legal mechanism, safeguards, and residual considerations.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates Affected customers received required notice of a new or changed subprocessor through the correct channel and timing, with the final content and recipient population retained.
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.