Which SOC 2 criterion covers vendor management?

Vendor management is primarily addressed by CC9.2, which requires the entity to assess and manage risks associated with vendors and business partners. CC9.1 (business continuity) and CC6 (access control) are also relevant when vendors hold customer data or have system access.

Do I need a SOC 2 report from every vendor?

No. You need to assess every in-scope vendor, but the depth of assessment should be tiered to the risk. A vendor that processes customer data warrants a SOC 2 or equivalent report. A vendor that hosts a static marketing site does not.

How often should vendors be reassessed?

Most SOC 2 programs reassess high-risk vendors annually. Medium-risk vendors are typically reviewed every eighteen to twenty-four months. The key is that reassessments are documented and tied to risk tier, not performed ad hoc.

What counts as a vendor for SOC 2 purposes?

Any third party that has access to your systems, handles customer data, or provides services that support your in-scope environment. This includes SaaS tools, cloud infrastructure providers, contractors with production access, and managed service providers.

What evidence do auditors expect for vendor management?

Auditors typically review a vendor inventory with risk ratings, completed assessments for a sample of vendors, executed contracts with security clauses, evidence of ongoing monitoring, and the process for onboarding and offboarding vendors.

SOC 2 Vendor Management (2026): CC9.2 Third-Party Risk

Vendor risk is where SOC 2 programs often get caught off guard

A SOC 2 audit does not stop at your firewall. If a vendor has access to your systems, handles your customer data, or provides critical infrastructure, their control failures can create your exceptions. CC9.2 — the Trust Services Criteria control for vendor and business partner risk — is consistently one of the higher-effort categories in first-time SOC 2 engagements. Organizations that treat vendor management as a procurement task rather than a security control usually underestimate what the auditor expects.

A mature SOC 2 vendor management program answers four questions at any moment: who are our vendors, what risk do they pose, what assessments have we done, and what are we doing to monitor them between assessments.

What CC9.2 requires

CC9.2 is the direct Trust Services Criteria reference for vendor management. The criterion requires that the entity "assesses and manages risks associated with vendors and business partners." The points of focus expand this into concrete expectations.

Establish requirements for vendor and business partner engagements
Assess vendor and business partner risks
Assign responsibility and accountability for managing vendor relationships
Establish communication protocols for vendors
Address risks through vendor selection, contracting, and monitoring
Implement procedures for terminating vendor relationships

CC6 is also relevant — if a vendor has logical access to your systems, that access is in scope for access management controls. CC9.1 addresses business continuity, which extends to vendors that provide critical services.

The five elements of a SOC 2 vendor management program

A vendor management program that holds up to auditor scrutiny has five elements. Each generates evidence that maps to CC9.2 and adjacent controls.

1. Vendor inventory

The inventory is the foundation. It lists every third party that has access to systems, data, or services in your SOC 2 scope. Each entry should capture:

Vendor name and primary service
Data the vendor handles (customer data, PII, credentials, none)
Criticality to operations
Assigned risk tier
Contract status and renewal date
Owner inside your organization

A common mistake is to keep a procurement list and call it a vendor inventory. Procurement usually misses contractors, free tools, and shadow SaaS. Sync the inventory with identity provider data, expense reports, and DNS records to catch gaps.

2. Risk tiering

Not every vendor requires the same scrutiny. Most programs use three tiers.

Tier	Description	Example
High	Hosts customer data, has production access, or is critical to uptime	Cloud infrastructure, primary database host, authentication provider
Medium	Holds sensitive internal data or supports core operations	CRM, HRIS, code repository, payroll
Low	Limited access, no sensitive data, easily replaceable	Marketing tools, scheduling apps, static hosting

Tiering drives the depth of assessment and the frequency of reassessment. High-risk vendors warrant a full security review, a current SOC 2 or equivalent report, and annual reassessment. Low-risk vendors may only need basic documentation.

3. Assessment process

For each in-scope vendor, document the assessment you performed. Typical artifacts include:

The vendor's current SOC 2 Type II report
ISO 27001 certificate or other attestations
Completed security questionnaire (SIG, CAIQ, or proprietary)
Data processing agreement (DPA) if PII is involved
Subprocessor lists with locations

Auditors sample vendor assessments from across the observation period. If an assessment was performed before the period began, that is fine — but reassessments during the period must have documentation. For related definitions, see third-party risk and risk register.

4. Contractual controls

Security requirements belong in the contract. Standard clauses include:

Confidentiality and data handling obligations
Breach notification timelines
Right to audit or to receive attestation reports
Subprocessor notification requirements
Data return and destruction on termination
Security minimums (encryption, MFA, logging)

The auditor may review a sample of executed contracts and look for consistent application of these clauses. Contracts signed before your SOC 2 program existed may be grandfathered, but new vendors should follow the current template.

5. Ongoing monitoring

Between assessments, vendors change. New subprocessors are added. Breaches happen. Certifications lapse. Monitoring catches these events without waiting for the next annual review.

Practical monitoring activities:

Subscribe to vendor status pages and security advisories
Track SOC 2 and ISO 27001 certificate expiration dates
Review vendor breach disclosures and public incident reports
Monitor for changes in subprocessor lists
Revisit risk tier when the vendor adds new features or data flows

How this fits into SOC 2

Vendor management generates some of the most audit-ready evidence in a SOC 2 program. Assessments, contracts, and monitoring artifacts are naturally documented and easy to produce on request. It also connects to several other Trust Services Criteria domains: continuous monitoring extends to vendor-related alerts, incident response includes vendor-initiated incidents, and change management covers changes to vendor integrations.

Weak vendor management often surfaces as exceptions in CC6 (access control) when offboarded vendors still hold credentials, or in CC9 (risk mitigation) when a vendor incident affected customer data and the response was unstructured.

Common mistakes

Procurement list as inventory. Procurement tracks contracts. It misses tools added via expense reports, personal credit cards, or free tiers. Reconcile against identity provider and network data.
One-time assessments. The vendor you assessed last year may have changed. Without a reassessment cadence, the evidence goes stale.
Missing DPAs. If a vendor processes personal data, a DPA is usually required by GDPR, CCPA, or equivalent. Auditors may not enforce this but your regulators will.
No offboarding. Vendors whose contracts expired still hold access or data. Build a decommissioning checklist and use it.
Ignoring subprocessors. Your vendor's vendors may also be in scope. Enterprise buyers will ask about them, and some HIPAA contexts require it.

Implementation tips

Build the vendor inventory once and treat it as a living system of record. Update it on every new contract signing and offboarding.
Use risk tier to drive process. A high-risk vendor triggers a full assessment; a low-risk vendor triggers a lightweight check. Tiered processes scale.
Require a SOC 2 or ISO 27001 report as part of procurement for any vendor that handles customer data. This shifts the security burden upstream.
Centralize vendor evidence in one place. Contracts, assessments, and monitoring reports should all be linked to the vendor record.
Revisit the vendor inventory quarterly with owners to catch drift.

How episki helps

episki manages the vendor inventory, risk tiering, assessment workflows, and contract repository in a single workspace mapped directly to CC9.2 and related SOC 2 controls. Start a free trial or explore the full SOC 2 framework guide to see how vendor management fits into the broader program.

SOC 2 Vendor Management