Skip to content
AuditFront
CC9.2 SOC 2

SOC 2 CC9.2: Risk Mitigation - Vendor and Business Partner Risk Management

What This Control Requires

The entity assesses and manages risks associated with vendors and business partners. The entity evaluates the risks that vendors and business partners may introduce to the entity's system and implements controls to mitigate those risks.

In Plain Language

A breach at your critical vendor hits you just as hard as one in your own environment. CC9.2 is about understanding and managing the security risk that comes with every third-party relationship - cloud providers, SaaS tools, contractors, business partners, and everyone else with access to your data or systems. You need a structured vendor risk management programme: evaluate security posture before engagement, set clear security requirements in contracts, monitor compliance throughout the relationship, and manage vendor access tightly. The depth of assessment should match the risk each vendor poses. Auditors look for a comprehensive vendor management programme with risk-based assessments, contractual security protections, and ongoing monitoring. A vendor inventory that's incomplete or due diligence that only happened at onboarding are common findings. So are contracts missing breach notification clauses.

How to Implement

Build a vendor risk management programme with a defined methodology. Create a vendor inventory cataloguing every third party with access to your systems, data, or facilities. Classify vendors by risk tier based on the sensitivity of data they touch, how critical their services are, and their level of access to your environment. Run due diligence before engaging any new vendor. Review security certifications (SOC 2, ISO 27001), send a security questionnaire, evaluate their practices against your requirements, and for high-risk vendors, consider on-site assessments or detailed technical reviews. Put security requirements into contracts. Key provisions: security standards the vendor must maintain, data protection and privacy obligations, breach notification requirements with specific timelines, right-to-audit clauses, insurance requirements, data handling and return/destruction at contract end, and regulatory compliance obligations. Monitor vendor risk on an ongoing basis. Reassess high-risk vendors annually, medium-risk vendors every two years. Watch for material changes - security incidents, ownership changes, financial instability. Subscribe to threat intelligence that might flag vendor compromises. Manage vendor access with the same rigour as employee access. Apply least privilege, use dedicated vendor accounts (never share employee credentials), set time limits for project-based access, monitor vendor activity in your systems, and review access logs regularly. Have a vendor offboarding process. When a relationship ends, revoke all access, get your data returned or destroyed, and confirm that surviving obligations (like confidentiality clauses) are understood by both parties.

Evidence Your Auditor Will Request

  • Vendor inventory with risk classification and assessment status for each vendor
  • Vendor due diligence assessment records including security questionnaires and certification reviews
  • Vendor contracts with security requirements, breach notification clauses, and right-to-audit provisions
  • Ongoing vendor monitoring records including reassessment results and risk tier reviews
  • Vendor access management records showing least privilege implementation and regular access reviews

Common Mistakes

  • No comprehensive vendor inventory exists, leaving the organization unaware of all third-party relationships
  • Vendor due diligence is performed only for large contracts, ignoring smaller vendors with significant data access
  • Contracts lack essential security clauses such as breach notification requirements and right-to-audit provisions
  • Vendor assessments are performed at onboarding but never repeated, missing changes in vendor risk posture
  • Vendor access is not monitored or reviewed, allowing excessive or stale access to persist

Related Controls Across Frameworks

Framework Control ID Relationship
ISO 27001 A.5.19 Equivalent
ISO 27001 A.5.20 Related
ISO 27001 A.5.21 Related
ISO 27001 A.5.22 Related
nist-csf GV.SC-01 Equivalent

Frequently Asked Questions

How do we assess cloud service providers like AWS or Azure?
The big cloud providers won't fill out your security questionnaire, and that's fine. They publish extensive compliance documentation instead. Review their SOC 2 reports, ISO 27001 certificates, and compliance programme docs. Understand the shared responsibility model so you know what you're responsible for versus what they manage. Focus your assessment on how you configure and use their services securely - that's where the real risk lives.
How many vendors do we need to assess?
All of them, but proportional to risk. High-risk vendors (sensitive data access, critical services) get thorough assessments. Medium-risk vendors get standard questionnaires and certification reviews. Low-risk vendors (no data access, non-critical services) need only basic due diligence. The point is having a risk-based approach rather than treating every vendor the same or skipping small ones that actually touch sensitive data.
What if a vendor refuses to complete our security questionnaire?
Look for alternative evidence. Many established vendors publish compliance certifications (SOC 2, ISO 27001) and security documentation that can satisfy your assessment. Evaluate whether publicly available information is enough for your risk level. If a vendor handles sensitive data and refuses to provide any security assurance at all, that should factor heavily into whether you engage them.

Track SOC 2 compliance in one place

AuditFront helps you manage every SOC 2 control, collect evidence, and stay audit-ready.

Start Free Assessment