TSC-CC9.2 Guidance

“TSC-CC9.2 guidance requirement” is a SOC 2 Common Criteria expectation focused on third-party risk: how you assess and manage risks created by vendors and business partners that support, connect to, or otherwise influence your services ¹. Auditors typically look for two things: (1) a defined, repeatable process, and (2) proof the process operated throughout the audit period.

For a CCO or GRC lead, the fastest way to meet TSC-CC9.2 is to stop treating third-party due diligence as a one-time procurement step. CC9.2 is lifecycle-based: inventory, risk-tiering, due diligence, contracting, monitoring, and reassessment. The operational target is simple: you should be able to show, for any in-scope third party, what risk they pose, what controls you required, how you verified them, and what you did when gaps were found.

This page translates CC9.2 into requirement-level implementation steps, the evidence auditors ask for, and a practical execution plan you can run with existing procurement, security, privacy, and legal workflows.

Regulatory text

Excerpt (TSC-CC9.2): “The entity assesses and manages risks associated with vendors and business partners” ¹.

Operator interpretation: You must run a documented third-party risk management (TPRM) process that (a) identifies relevant third parties, (b) assesses the risks they create for your services and customers, and (c) manages those risks through controls such as due diligence, contractual requirements, monitoring, and periodic reassessment ¹.

Plain-English interpretation (what this means day to day)

• You need a third-party inventory that matches your SOC 2 scope, not an informal spreadsheet that only procurement sees.
• You need a risk-based method to decide which third parties get deeper review (and which do not).
• You must take action based on results: approve, reject, require remediation, add contract clauses, restrict access, or add monitoring.
• You must retain evidence that the process ran during the audit window, including re-reviews and issue follow-up.

Who it applies to

Entity types: Any organization undergoing a SOC 2 audit against the AICPA Trust Services Criteria where third parties could affect the in-scope system ¹.

Operational context (where CC9.2 usually bites):

• SaaS or platform providers relying on cloud hosting, managed databases, observability, customer support tooling, or payment processors.
• Service organizations with outsourced IT, SOC, help desk, or development contractors.
• Business partners that integrate via APIs, SSO, webhooks, data feeds, or shared administrative consoles.
• Subprocessors that store, process, transmit, or can access customer data.

Scoping rule that auditors expect you to follow: If a third party can materially impact your ability to meet the SOC 2 commitments in your system description, it belongs in the CC9.2 program and inventory.

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

Step 1: Define your third-party population and owners

1. Create a single inventory of third parties relevant to the in-scope system (vendors, subprocessors, contractors, consultants, partners).
2. Assign an internal owner per third party (business owner) plus a control owner for TPRM operations (GRC, Security, or Procurement).
3. Classify relationship type (software, cloud/hosting, professional services, contractor labor, partner integration) and what they touch (data, infrastructure, availability, confidentiality).

Practical tip: If your inventory cannot answer “Which third parties can access production systems or customer data?” it is not audit-ready.

Step 2: Implement a risk-tiering model that drives requirements

Build a tiering model that determines due diligence depth. Keep it explainable.

A workable tiering decision set (examples):

• Data sensitivity: Do they process or access customer data? Is it regulated or confidential?
• System access: Do they have network access, admin access, or production credentials?
• Service criticality: Would failure disrupt your service commitments?
• Change influence: Can they deploy code, manage infrastructure, or alter configurations?

Output: Tier 1 / Tier 2 / Tier 3 (or Critical/High/Medium/Low) with defined control requirements per tier.

Step 3: Standardize due diligence for onboarding

For each risk tier, define minimum due diligence inputs and decision rules.

Common due diligence inputs auditors accept (choose per tier):

• Security and privacy questionnaire aligned to your control environment.
• SOC 2 report review (scope, period, complementary user entity controls, exceptions).
• Pen test summary or vulnerability management attestations where appropriate.
• Data processing terms and subprocessors list (if applicable).
• Business continuity/DR posture statements for critical providers.

Decisioning rules (make them explicit):

• Who can approve onboarding per tier (Security, Privacy, Legal).
• What constitutes a “conditional approval” vs “rejection.”
• When compensating controls are acceptable (e.g., limiting access, encryption, segmentation).

Step 4: Contracting requirements (make the controls stick)

CC9.2 is hard to defend if your contracts do not reflect your risk decisions.

For higher-risk tiers, implement:

• Security requirements (incident notification, access controls, encryption expectations).
• Right to audit / evidence provision (SOC 2, equivalent reports, or attestations).
• Subprocessor controls (flow-down obligations where relevant).
• Data handling terms (confidentiality, retention, deletion, return).
• Termination and transition support for critical services.

Your contracts do not need to be identical across all third parties. They need to match the risk.

Step 5: Ongoing monitoring and periodic reassessments

Define triggers and cadence. Auditors mainly care that you actually do it and can prove it.

Monitoring events to track:

• Expiring SOC reports or stale due diligence packages.
• Material scope changes (new data types, new integrations, new access).
• Security incidents or breach notifications involving the third party.
• Performance failures that affect availability or support obligations.
• Legal/entity changes (acquisitions, sanctions screening if applicable to your risk model).

Periodic reassessments: Run re-reviews for higher-risk third parties and document the outcome, even if the outcome is “no material change.”

Step 6: Track issues to closure (and show governance)

1. Log findings from questionnaires, SOC report exceptions, contract gaps, and monitoring alerts.
2. Assign remediation owners and due dates.
3. Decide on risk acceptance vs remediation vs offboarding.
4. Escalate exceptions per your risk policy.

Evidence auditors want: a visible loop from “identified risk” to “decision” to “follow-up.”

Required evidence and artifacts to retain

Retain artifacts in a central repository with version control and an audit trail. Minimum set:

Governance and process

• Third-party risk management policy/procedure mapped to TSC-CC9.2 ¹.
• Defined tiering methodology and decision matrix.
• Roles and responsibilities (RACI) for onboarding, approvals, monitoring, and exceptions.

Inventory and assessments

• Third-party inventory with tier, scope linkage, and owner.
• Completed due diligence packages per sampled third party (questionnaires, SOC 2 reviews, risk memos).
• Approval evidence (tickets, emails, system approvals) showing required reviewers signed off.

Contracting and controls

• Executed contracts and security addenda for sampled high-risk third parties.
• Documented required clauses and exception approvals where clauses are missing.

Monitoring and reassessment

• Monitoring logs or review records (reassessments, alerts triage, status reports).
• Issue tracker entries with closure evidence.

Testing and effectiveness

• Internal control testing results demonstrating the process operated (sampling plan, test steps, results, exceptions) ¹.

Common exam/audit questions and hangups

Auditors tend to probe the same weak spots:

1. “Show me the complete population.” How do you know your inventory is complete for the in-scope system?
2. “Explain your tiering.” Why is Provider A “low” risk when it touches production logs or customer data?
3. “Prove it operated.” Provide a sample of onboarded third parties with evidence of review, approval, and contracting.
4. “What happens when you find gaps?” Show remediation tracking, risk acceptance approvals, and follow-up.
5. “How do you monitor between reviews?” Evidence of ongoing monitoring, not only point-in-time questionnaires.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails in SOC 2	Fix
Inventory excludes “business partners” and only lists procurement vendors	CC9.2 covers vendors and partners; integrations create risk	Define “third party” broadly and tie inventory to system architecture 1
Same questionnaire for everyone	Risk-based management becomes hard to defend	Tier first, then apply tier-based due diligence
No documented approval workflow	Auditor cannot confirm control operation	Use tickets/workflows with required approvers per tier
Contracts don’t reflect assessed risk	Due diligence becomes performative	Add clause library + exception process with sign-off
Monitoring is informal	Hard to show control ran during audit period	Define monitoring triggers and retain review records
No testing of the control	You cannot support operating effectiveness	Perform periodic internal testing and keep workpapers 1

Enforcement context and risk implications

SOC 2 is an audit framework, not a regulatory enforcement regime. No public enforcement cases are provided for TSC-CC9.2 in the supplied source catalog. The practical risk is commercial and assurance-driven: weak third-party risk management increases the likelihood of audit exceptions, report qualifications, and customer trust friction during security reviews ¹.

Practical 30/60/90-day execution plan

Days 0–30: Stand up the minimum viable CC9.2 program

• Publish a TPRM procedure mapped to CC9.2 language and your audit scope ¹.
• Build the third-party inventory and name owners.
• Implement a tiering model and approval workflow.
• Choose a due diligence pack per tier (questionnaire + SOC review template + contract clause checklist).
• Start collecting evidence in a dedicated audit-ready folder structure.

Deliverable: Auditor-readable narrative + inventory + first wave of completed reviews for critical third parties.

Days 31–60: Make it operational across procurement and engineering

• Integrate TPRM into intake (procurement request or security review ticket).
• Roll out contracting standards and an exceptions process.
• Run due diligence on remaining in-scope third parties; document approvals and any risk acceptances.
• Establish monitoring (calendar-based reassessments, SOC report expiry tracking, incident notification tracking).

Deliverable: Demonstrable lifecycle: onboarding → contract → monitoring → issues closure.

Days 61–90: Prove operating effectiveness and close gaps

• Perform internal testing: sample third parties across tiers; verify required steps occurred; document exceptions and remediation ¹.
• Clean up inventory completeness: reconcile against AP, SSO apps, cloud marketplaces, and architecture diagrams.
• Tighten evidence quality: ensure timestamps, approver identity, and final decisions are clear.
• Prepare an audit PBC package (inventory export, policy, sample packets, monitoring proof, issues log).

Deliverable: Test workpapers + remediation tracker + ready-to-hand PBC set.

Where Daydream fits (without adding process drag)

If you are running CC9.2 in spreadsheets and shared drives, evidence collection becomes the bottleneck. Daydream is a natural fit where you need one place to (1) maintain the inventory, (2) route tier-based workflows and approvals, and (3) produce consistent evidence packets for auditors without rebuilding them every audit cycle.

Frequently Asked Questions

Do we need to assess every vendor for SOC 2 CC9.2?

Assess every third party that can affect the in-scope system, but the depth should be risk-based ¹. Low-risk providers can have lightweight due diligence if your tiering logic supports it.

What counts as a “business partner” under CC9.2?

Treat any external party that integrates with your service, handles customer data, or can affect service delivery as in-scope for CC9.2 purposes ¹. Document your definition and apply it consistently.

Is a vendor’s SOC 2 report enough due diligence?

Often it is a strong input, but you still need to review scope, period, exceptions, and complementary user entity controls, then document your decision. If the report does not cover your risks, add targeted questions or controls.

How do we handle third parties that refuse certain contract clauses?

Use a formal exception process: document the gap, assess impact, add compensating controls where feasible, and record risk acceptance by an authorized approver. Auditors look for governance and consistency.

What evidence is most likely to be sampled by the SOC 2 auditor?

Expect requests for the inventory, tiering rationale, completed due diligence for a sample of high-risk third parties, approval records, executed agreements, monitoring/reassessment proof, and issue remediation tracking ¹.

We have hundreds of SaaS tools. How do we keep this manageable?

Start by scoping to tools that touch customer data, production systems, or critical service delivery, then expand coverage using tiering. A documented method for identifying and triaging tools matters as much as immediate completeness.

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