Vendor Risk
Vendors provide timely notification of incidents, security events, data exposure, and material service disruptions that may affect the organization.
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 security incidents, data exposures, and material service disruptions reach the right company responders in time to assess impact, coordinate response, meet the company’s own obligations, and preserve a complete record.
First SOC 2 program
Put current security and operational contacts in critical-vendor records, route vendor notices and status subscriptions to monitored team channels, and require every material notice to create an incident or service ticket with an owner and impact decision.
As the company scales
Integrate vendor alerts with incident management, map contractual notice requirements and service dependencies to response playbooks, maintain round-the-clock escalation for critical providers, and exercise vendor-notification scenarios with legal, privacy, support, and resilience teams.
Identify applicable incident, data-exposure, security-event, availability, and recovery notice duties by vendor risk, contract, data use, and service dependency.
You should end up with: A vendor-notification requirement record with event types, timing, content, and channels.
Record vendor security, privacy, support, and escalation contacts; provide the vendor with company contacts; and subscribe monitored channels to relevant status and advisory sources.
You should end up with: Current contact and subscription records with periodic verification.
Log the notice, confirm receipt, identify affected services and data, assign severity using company criteria, and bring in security, privacy, legal, engineering, support, and business owners as needed.
You should end up with: A timestamped incident or service record with owner, severity, scope, and responders.
Request missing facts, examine integrations and data flows, validate the vendor’s stated scope against company records, take protective actions, and monitor vendor containment and recovery.
You should end up with: An impact assessment, decision log, protective-action evidence, and vendor updates.
Use the company’s incident process to decide and complete any required customer, regulator, insurer, law-enforcement, or internal communication based on applicable facts and obligations.
You should end up with: Approved communication decisions and proof of completed notifications where applicable.
Document recovery, lessons, vendor corrective actions, contract or monitoring changes, continuity improvements, and final closure approval.
You should end up with: A completed incident record and tracked vendor or internal follow-up actions.
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
Contracts define which vendor security, data, and service events require notice, the timing and content expected, and the working channels for escalation and cooperation.
Include this context
covered event types
Include this context
notice trigger and timing
Include this context
required notice content
Include this context
notification channels
Include this context
cooperation and update duties
Include this context
applicable agreement and service
Weak evidence to avoid
A clause requiring prompt notice of material events without defining the covered service, notice trigger, contact channel, expected facts, updates, or cooperation.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
The company received and preserved the vendor’s original incident or exposure communications, timestamps, affected scope, updates, and recovery statements.
Include this context
vendor and notice identifier
Include this context
received timestamp and channel
Include this context
event type and vendor severity
Include this context
affected services, systems, or data
Include this context
vendor timeline and updates
Include this context
containment or recovery status
Weak evidence to avoid
A forwarded message saying vendor had an issue with no original timestamp, affected product, data scope, event dates, vendor updates, or recovery status.
Confirm what the record proves
Material vendor outages and degradation were identified, mapped to dependent company services, assessed for customer impact, escalated, and tracked through restoration.
Include this context
vendor event and affected service
Include this context
start, detection, and restoration times
Include this context
company dependency and impact
Include this context
severity and owner
Include this context
customer impact decision
Include this context
disposition and follow-up
Weak evidence to avoid
A status-page screenshot showing an outage resolved with no company detection time, dependent service, customer impact, incident owner, or follow-up action.
Confirm what the record proves
Vendor events entered the company’s response process and were independently scoped, investigated, mitigated, communicated, and closed with accountable decisions.
Include this context
company and vendor incident identifiers
Include this context
received and triage timestamps
Include this context
company severity and affected scope
Include this context
responders and decisions
Include this context
protective and notification actions
Include this context
closure and lessons
Weak evidence to avoid
A ticket that links to the vendor status page and closes when service returns without company impact analysis, data scope, communication decision, or lessons.
Type 1
Current vendor-notification requirements and contact routes for critical providers, configured alert intake, and the current response procedure as of the examination date. Include an applicable vendor-event record through triage and closure when one exists; if a complete query across monitored notice channels, status alerts, support records, and incident records returns no occurrence, retain the zero-result query and conduct a tabletop that carries a representative vendor notice through impact, communication, escalation, and closure decisions.
Type 2
Every vendor security notice, data-exposure notice, material service disruption, status alert crossing the company threshold, and vendor-originated incident ticket received or opened during the review period.
Reconcile monitored vendor notice channels, status alerts, support records, and vendor-risk alerts to company incident and disruption records, then verify all threshold-crossing events have impact, communication, and closure decisions.
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 security incidents, data exposures, and material service disruptions reach the right company responders in time to assess impact, coordinate response, meet the company’s own obligations, and preserve a complete record.
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 monitored vendor notice channels, status alerts, support records, and vendor-risk alerts to company incident and disruption records, then verify all threshold-crossing events have impact, communication, and closure decisions.
Current vendor-notification requirements and contact routes for critical providers, configured alert intake, and the current response procedure as of the examination date. Include an applicable vendor-event record through triage and closure when one exists; if a complete query across monitored notice channels, status alerts, support records, and incident records returns no occurrence, retain the zero-result query and conduct a tabletop that carries a representative vendor notice through impact, communication, escalation, and closure decisions.
Every vendor security notice, data-exposure notice, material service disruption, status alert crossing the company threshold, and vendor-originated incident ticket received or opened during the review period.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates Contracts define which vendor security, data, and service events require notice, the timing and content expected, and the working channels for escalation and cooperation.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates The company received and preserved the vendor’s original incident or exposure communications, timestamps, affected scope, updates, and recovery statements.
For each selected record, confirm it demonstrates Material vendor outages and degradation were identified, mapped to dependent company services, assessed for customer impact, escalated, and tracked through restoration.
For each selected record, confirm it demonstrates Vendor events entered the company’s response process and were independently scoped, investigated, mitigated, communicated, and closed with accountable decisions.
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.