The entity assesses and manages risks associated with vendors and business partners

To meet the the entity assesses and manages risks associated with vendors and business partners requirement (SOC 2 TSC-CC9.2), you need a repeatable third-party risk management process that identifies in-scope third parties, evaluates their security and operational risks before onboarding, sets contractual and control expectations, and monitors performance and risk through the relationship lifecycle. Auditors will look for consistent decisions and retained evidence.

Key takeaways:

• Build a lifecycle workflow: intake → risk tiering → due diligence → contracting → ongoing monitoring → offboarding.
• Tie each third party to systems/data/processes they touch, then scale diligence to risk.
• Evidence wins SOC 2: approvals, reviews, contracts, SOC reports, issues, and follow-ups must be easy to produce.

CC9.2 is where SOC 2 stops being “internal controls” and starts being “supply chain controls.” If a third party stores customer data, supports your production environment, processes payments, runs customer support, or has privileged access, their failures become your failures. This requirement expects you to prove two things: (1) you consistently assess third-party risk in a way that matches your actual exposure, and (2) you manage that risk through contracts, technical controls, and ongoing oversight.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to operationalize CC9.2 as a lightweight but enforceable program. You need a clear scope definition, a tiering model that drives how much diligence happens, a standard set of security/compliance questions and evidence requests, and a contract workflow that prevents “security later” deals. Then you need monitoring: not “annual check-the-box,” but event-based reviews and tracking of findings to closure.

This page gives requirement-level implementation guidance you can implement quickly, with a focus on what SOC 2 auditors typically expect to see in design and operating effectiveness.

Requirement: The entity assesses and manages risks associated with vendors and business partners

Control objective (plain English): You must identify third parties that could affect your security, availability, confidentiality, processing integrity, or privacy commitments, assess the risk they introduce, and actively manage that risk throughout the relationship.

## Regulatory text

SOC 2 Trust Services Criteria states: “The entity assesses and manages risks associated with vendors and business partners.” ¹

What the operator must do:

• Assess: Determine which third parties matter, what they can impact, and how risky they are (based on access, data sensitivity, criticality, and control reliance).
• Manage: Reduce risk to an acceptable level through selection decisions, contract terms, compensating controls, and ongoing monitoring, and keep evidence that you did it ¹.

---

Plain-English interpretation (what auditors actually mean)

Auditors are not looking for “a vendor list” or a questionnaire folder. They are looking for a decision system that you can explain and defend:

1. You know who your third parties are (including contractors, consultants, subprocessors, affiliates, and “partners” that touch sensitive workflows).
2. You tier them by risk using criteria tied to your environment (production access, data types, business criticality).
3. You perform diligence before access/data is granted, and you can show approvals and remediation steps when gaps are found.
4. You translate diligence into enforceable requirements (security addendum, DPAs, breach notice, audit rights where appropriate, flow-down to subprocessors).
5. You monitor for changes: renewals, incidents, scope changes, expiring SOC reports, and performance issues.

If your process exists but is not followed consistently, CC9.2 will still fail on operating effectiveness.

---

Who it applies to (entity and operational context)

Applies to: Service organizations pursuing a SOC 2 report where third parties could impact the Trust Services Criteria commitments ¹.

Operationally in-scope third parties commonly include:

• Cloud hosting and infrastructure providers
• Managed service providers (MSPs), endpoint management, SOC providers
• SaaS handling customer data (CRM, support platforms, analytics if it processes sensitive data)
• Payment processors and billing platforms
• Contractors with VPN/admin access or access to sensitive repositories
• Business partners with shared environments, integrations, or delegated operations

Scope trigger: If a third party can materially affect a system boundary, a control, or a customer commitment, treat them as in scope for CC9.2.

---

What you actually need to do (step-by-step)

Use this lifecycle workflow. Keep it simple, enforce it through procurement and access controls, and produce evidence at each gate.

1) Build and maintain a third-party inventory (system-of-record)

• Define “third party” for your organization (include vendors, contractors, partners, and subprocessors).
• Create an inventory with: legal name, service description, business owner, renewal date, data types accessed, system access, integration points, and whether they are customer-facing.
• Map each third party to the systems/processes in your SOC 2 scope.

Practical tip: If procurement is decentralized, pull from AP spend, SSO app catalog, contract repository, and IAM privileged access lists, then reconcile.

2) Classify third parties using a risk tiering model

Create a tiering decision tree that produces a tier such as High / Medium / Low, driven by:

• Access: production admin access, network connectivity, code contribution, privileged credentials.
• Data: regulated data, customer confidential data, authentication data, encryption keys.
• Criticality: outage impact, RTO/RPO dependency, customer deliverables dependency.
• Control reliance: whether you rely on their controls to meet your commitments.

Output: a tier label plus required diligence actions per tier.

3) Perform pre-onboarding due diligence proportional to tier

For each tier, define a minimum diligence package. Examples:

• High risk: security questionnaire + SOC 2 report review (if available) + pen test summary (if available) + incident history questions + privacy assessment + business continuity evidence + data flow confirmation.
• Medium risk: questionnaire + policy/controls evidence + targeted follow-ups.
• Low risk: lightweight intake + confirm no sensitive access/data, record rationale.

Operational rule: No contract signature, no production access, and no data transfer until diligence is approved (or an exception is approved).

4) Decide and document: approve, reject, or approve-with-conditions

Create a one-page Vendor Risk Assessment (VRA) decision record:

• Tier and rationale
• Risks noted (e.g., missing MFA, weak logging, no SOC report)
• Required mitigations (contract clauses, technical controls, or roadmap commitments)
• Approval, approver, date, and any exception ticket link

This is where many programs fail: teams do diligence but never record the decision and risk acceptance.

5) Contract for control: bake risk requirements into agreements

For in-scope third parties, standardize contract language and ensure it is actually used:

• Security requirements (access controls, encryption, logging, vulnerability management)
• Incident notification and cooperation
• Confidentiality and data handling restrictions
• Subprocessor/4th-party flow-down expectations (where applicable)
• Right to audit or to receive assurance reports (often via SOC 2 reports)
• Termination assistance and data return/destruction

Practical tip: Maintain approved templates (MSA + DPA + security addendum) and require Legal/InfoSec review for deviations.

6) Implement compensating technical controls where contracts can’t fix risk

Examples:

• Put the vendor behind SSO + MFA, least privilege, time-bound access
• Tokenize or minimize data shared
• Segment network access; restrict API scopes; rotate keys
• Monitor vendor activity (logs, alerts, periodic access recertification)

Auditors accept compensating controls when they are documented and operating.

7) Ongoing monitoring: keep the assessment current

Define monitoring events:

• Contract renewal or scope expansion
• Material change in data types, integration, or access
• Vendor security incident or major outage
• Expiring assurance reports (SOC reports, ISO certs) if you rely on them
• Performance failures against SLAs that could affect Trust Services commitments

Track issues to closure with owners and deadlines. Keep evidence of follow-up.

8) Offboarding and termination controls

When a third party relationship ends:

• Revoke access (SSO, VPN, API keys, shared accounts)
• Confirm data return/destruction where relevant
• Archive contracts, risk decisions, and final attestations

---

Required evidence and artifacts to retain (SOC 2-ready)

Auditors typically request evidence that shows both design and operation:

Core artifacts

• Third-party risk management policy/standard (scope, tiers, workflow)
• Third-party inventory (system-of-record export)
• Tiering methodology and decision tree
• Due diligence templates: questionnaire, evidence request list, review checklist
• Completed assessments for sampled vendors/partners
• Security reviews of SOC reports (where received), including noted exceptions and your disposition
• Contracts: MSA/DPA/security addendum, and records of negotiated exceptions
• Risk acceptances/exceptions with approvals and compensating controls
• Ongoing monitoring records: renewal reviews, incident follow-ups, performance reviews
• Offboarding checklists and access removal evidence

Evidence quality rules (what makes evidence “pass”)

• Dated, attributable (who did it), and tied to the specific third party
• Shows follow-through (issues tracked, not just identified)
• Matches your written process (no “paper policy” drift)

Daydream fit (earned mention): Teams often lose time assembling evidence across procurement, ticketing, and contract storage. Daydream can act as the control workspace that links vendor inventory, review tasks, exceptions, and evidence files to the CC9.2 control narrative so audit sampling becomes retrieval, not archaeology.

---

Common exam/audit questions and hangups

Auditors tend to probe these areas for CC9.2:

1. “Show me your complete vendor/third-party population.”
   Hangup: inventory misses contractors, “free” SaaS, or partners outside procurement.

2. “How do you decide which vendors are high risk?”
   Hangup: tiering is subjective, undocumented, or not tied to access/data/criticality.

3. “For this sampled vendor, show the assessment, approval, and contract terms.”
   Hangup: diligence exists but approval is missing; contracts don’t reflect required controls.

4. “How do you monitor vendors after onboarding?”
   Hangup: no event-based reassessment, no tracking of findings, no renewal workflow.

5. “What happens when a vendor can’t meet your requirements?”
   Hangup: exceptions are informal (Slack/email) and lack risk acceptance and compensating controls.

---

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Treating “vendor management” as procurement paperwork

Fix: Put security gates in the workflow: procurement intake triggers risk tiering, tiering triggers diligence, diligence triggers contract requirements.

Mistake 2: Over-relying on SOC 2 reports without reviewing them

Fix: Document a SOC report review checklist: scope period, carve-outs, subservice orgs, exceptions, and whether the report covers the services you use.

Mistake 3: One questionnaire for every vendor

Fix: Tier first, then right-size diligence. Low-risk vendors need a documented rationale, not a 200-question form.

Mistake 4: No operational linkage to access control

Fix: Require evidence that access was granted only after approval, and recertify privileged access for high-risk third parties.

Mistake 5: Exceptions become the default path

Fix: Track exceptions with expiration dates, compensating controls, and a clear owner. Require re-approval if the scope changes.

---

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. For SOC 2, the immediate “enforcement” mechanism is the audit outcome: weak third-party risk management commonly results in control failures, qualified opinions, or scope limitations when third parties materially affect in-scope systems ¹. Operationally, unmanaged third-party access and data handling increases incident likelihood and can create downstream contractual and customer trust issues.

---

A practical 30/60/90-day execution plan

First 30 days: establish scope, inventory, and minimum gates

• Publish a short third-party risk standard: definitions, tiering factors, required steps.
• Build your inventory baseline from AP spend + SSO app list + contract repository + IAM privileged access.
• Implement a basic tiering form and approval workflow (ticket-based is fine).
• Define minimum contract clauses for in-scope third parties and align with Legal.

Deliverables: inventory v1, tiering rubric, assessment template, contract addendum template, exception process.

Days 31–60: operationalize diligence and contract enforcement

• Run assessments for your highest-risk third parties first (production access, sensitive data, critical services).
• Create a centralized evidence folder per third party (assessment, SOC report review, contract, issues).
• Start an issues register for vendor findings and exceptions with owners and tracking.
• Train procurement/business owners on the new intake and “no approval, no access” rule.

Deliverables: completed VRAs for top-risk third parties, issues register, documented approvals, contract updates in flight.

Days 61–90: monitoring, metrics, and audit readiness

• Implement renewal and change triggers (renewals, incidents, scope changes).
• Add ongoing monitoring steps: assurance refresh requests, access recertification, performance/SLA reviews where relevant.
• Perform an internal audit-style sample: pick several third parties across tiers and confirm you can produce end-to-end evidence quickly.
• Tighten gaps: missing approvals, inconsistent tiering, contract deviations without exceptions.

Deliverables: monitoring calendar/triggers, sample-ready evidence packages, updated narratives for SOC 2 audit fieldwork.

---

Frequently Asked Questions

Do we have to assess every single vendor, including low-risk tools?

You need to assess and manage risks across vendors and business partners, but you can scale the depth. For low-risk third parties, document the rationale for low impact (no sensitive data, no privileged access) and keep it in your inventory ¹.

What counts as a “business partner” under this requirement?

Treat any external party that can affect your service delivery, security posture, or customer commitments as a third party. Partners with integrations, shared workflows, or access to your environments typically require the same risk process as vendors ¹.

Is a SOC 2 report enough due diligence for a critical vendor?

A SOC 2 report helps, but auditors expect you to review it and document whether its scope and results cover the services you rely on. If there are exceptions or carve-outs, record your response (accept, mitigate, or select another provider) ¹.

How do we handle a vendor that won’t sign our security addendum?

Treat it as an exception: document the gap, the business justification, compensating controls (technical restrictions, data minimization), and formal risk acceptance by an appropriate approver. Track it for revisit at renewal or when scope changes ¹.

What evidence is most likely to be sampled in a SOC 2 audit?

Auditors commonly sample the inventory population, tiering decisions, completed assessments, approvals, SOC report reviews, and the executed contract package for selected third parties. They also ask for proof of follow-up on identified issues ¹.

We use subcontractors through a prime vendor. Are we responsible for them too?

You are responsible for managing the risk that enters your environment through that chain. Contractually, require your prime vendor to manage and flow down relevant obligations to their subprocessors, and document how you gain assurance ¹.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. AICPA TSC 2017