The Vendor Problem Every SOC 2 Organization Faces
Your SOC 2 report covers your controls. But your infrastructure runs on other companies' platforms. Your customer data flows through third-party APIs. Your employees use SaaS tools that you do not control. And your auditor knows all of this.
Third-party risk management is one of the most consistently challenging areas of SOC 2 compliance, not because the requirements are complex but because the operational burden scales with every vendor you add. A typical SaaS company with 100 employees uses 80 to 120 SaaS tools. Sending security questionnaires to all of them is not just impractical -- it is the wrong approach entirely.
The good news is that SOC 2 does not require you to assess every vendor with equal rigor. It requires you to have a risk-based vendor management program that focuses your attention on the vendors that actually matter to your security posture. This guide covers exactly how to build that program and what your auditor will expect to see.
Key insight: SOC 2 vendor management is not about eliminating vendor risk. It is about demonstrating that you understand your vendor risk, have a process for managing it, and can show evidence that the process works.
What SOC 2 Actually Requires for Vendor Management
Vendor management requirements in SOC 2 are spread across multiple Trust Services Criteria, but the primary controls sit under CC2 (Communication and Information) and CC9 (Risk Mitigation). Here is what each requires in the context of vendor oversight.
CC2.3 -- Communication with Third Parties
This control requires that your organization communicates its security commitments, system requirements, and responsibilities to external parties including vendors. In practice, this means:
- Vendor contracts include security requirements and data protection obligations
- Vendors are informed of your security policies that apply to them
- There is a defined process for communicating changes that affect vendor relationships
CC9.2 -- Risk Mitigation Through Vendor Management
CC9.2 is the core vendor management control. It requires that your organization assesses and manages risks associated with vendors and business partners. The AICPA expects:
- A vendor inventory that identifies all third parties with access to your systems or data
- A risk assessment process that classifies vendors by the risk they pose
- Due diligence procedures performed before onboarding new vendors
- Ongoing monitoring of vendor security posture
- Documented procedures for vendor offboarding and data retrieval or destruction
Complementary Subservice Organization Controls
When a vendor provides services that are integral to your control environment -- your cloud hosting provider is the most common example -- they are classified as a subservice organization. This is where vendor management gets more nuanced and where auditors pay the most attention.
Inclusive vs. Carve-Out: Understanding Your Options
When your SOC 2 report references subservice organizations, you have two options for how their controls are presented. This decision has significant implications for your audit scope and cost.
| Aspect | Inclusive Method | Carve-Out Method |
|---|---|---|
| Definition | Subservice organization's controls are included in your SOC 2 report and tested by your auditor | Subservice organization's controls are excluded from your report; their own SOC 2 report is referenced instead |
| Auditor Access | Your auditor needs direct access to test the subservice organization's controls | Your auditor reviews the subservice organization's own SOC 2 report |
| Cost Impact | Significantly higher audit fees due to expanded scope | Lower cost; you only need to obtain and review their SOC 2 report |
| Vendor Cooperation | Requires extensive cooperation from the subservice organization | Minimal cooperation needed; just their SOC 2 report |
| Common Usage | Rare; typically only when you and the subservice organization share the same parent company | Used in the vast majority of SOC 2 reports |
| User Responsibility | Fewer complementary user entity controls (CUECs) for your customers to implement | Your report lists CUECs that your customers must implement |
In practice, nearly every organization uses the carve-out method. AWS, Azure, GCP, Stripe, Twilio -- none of these companies will allow your auditor to test their controls directly. They publish their own SOC 2 reports, and your auditor references those reports in your audit.
What your auditor will verify with the carve-out method: That you have obtained and reviewed the subservice organization's most recent SOC 2 report, that you have evaluated any exceptions or qualified opinions in that report, that you have identified and implemented any Complementary User Entity Controls (CUECs) described in their report, and that you monitor for any changes in their service that could affect your controls.
Building a Risk-Based Vendor Classification System
The foundation of an efficient vendor management program is classification. Not all vendors carry the same risk, and your program should reflect that reality. Sending a 200-question security questionnaire to the company that provides your office plants is a waste of everyone's time.
Step 1: Build Your Vendor Inventory
Start with a complete list of every vendor that touches your business. Include:
- Infrastructure providers (AWS, GCP, Azure, Cloudflare, etc.)
- SaaS tools used by employees (Google Workspace, Microsoft 365, Salesforce, etc.)
- Development and DevOps tools (GitHub, CircleCI, Datadog, etc.)
- Payment and billing processors
- Communication tools (Microsoft Teams, Zoom, etc.)
- Security tools (endpoint protection, SIEM, vulnerability scanners)
- Professional services (consultants, contractors, outsourced development)
- Physical infrastructure (data centers, ISPs, office facility providers)
Step 2: Classify by Risk Tier
Assign each vendor to a risk tier based on two primary factors: data access and service criticality.
| Risk Tier | Criteria | Assessment Frequency | Assessment Depth |
|---|---|---|---|
| Critical | Stores or processes customer data, or provides infrastructure that hosts your production environment | Annually (minimum) | SOC 2 report review + CUEC validation + contract review + ongoing monitoring |
| High | Has access to internal systems or employee data, or provides services that could impact availability | Annually | SOC 2 or ISO 27001 review + security questionnaire + contract review |
| Medium | Has limited access to non-sensitive data, or provides non-critical business services | Every 2 years | Security questionnaire or self-attestation + contract review |
| Low | No access to sensitive data, no system access, non-critical service | At onboarding only | Basic due diligence (website review, business verification) |
This tiered approach is exactly what auditors expect. They do not want to see that you sent identical 200-question questionnaires to both your cloud hosting provider and your catering company. They want to see that you understand the risk each vendor poses and have proportionate oversight measures in place.
Vendor Due Diligence: What to Actually Assess
Once you have classified your vendors, you need a practical assessment methodology for each tier. Here is what to evaluate and what evidence to collect.
For Critical and High-Risk Vendors
- SOC 2 Type II report review -- Obtain and review their most recent report. Check for qualified opinions, exceptions, and the scope of their report versus the services you use
- CUEC validation -- Identify all Complementary User Entity Controls in their SOC 2 report and document how your organization fulfills each one
- Data processing agreement -- Verify contractual obligations around data handling, breach notification, data deletion, and subprocessor management
- Insurance verification -- Confirm they carry adequate cyber liability insurance
- Business continuity review -- Understand their disaster recovery and business continuity capabilities
- Incident history -- Check for any publicly disclosed breaches or security incidents
When a Vendor Does Not Have a SOC 2 Report
Not every vendor will have a SOC 2 report, especially smaller or newer companies. This does not automatically disqualify them, but you need alternative evidence of their security posture:
- ISO 27001 certification -- Provides comparable assurance for information security management
- Completed security questionnaire -- Use a standardized format like SIG Lite, CAIQ, or your own risk-weighted questionnaire
- Penetration test report -- A recent third-party penetration test report demonstrates proactive security testing
- SOC 3 report -- A public version of SOC 2 that provides general assurance without detailed control descriptions
- Trust center or security page -- Many modern SaaS companies publish their security certifications, policies, and practices online
Document your rationale: If a critical vendor lacks a SOC 2 report and you decide to proceed with them, document your risk acceptance decision. Include what alternative evidence you reviewed, what compensating controls you implemented, and who approved the vendor onboarding. Auditors are reasonable -- they want to see that you made an informed decision, not that you ignored the risk.
The Vendor Security Questionnaire: Making It Work
Security questionnaires are the most common assessment tool for vendor due diligence, and also the most despised. Both sides hate them -- the sender because responses are slow and unreliable, and the recipient because they are repetitive and time-consuming. Here is how to make them actually useful.
Designing an Effective Questionnaire
Avoid the temptation to send a 300-question behemoth. A well-designed vendor security questionnaire should be:
- Risk-weighted -- Questions should align with the risk tier. A critical vendor gets deeper questions about encryption, access controls, and incident response. A medium-risk vendor gets questions about basic security hygiene.
- Evidence-based -- Ask for proof, not just assertions. "Do you encrypt data at rest?" is a yes/no question. "Provide your encryption policy and describe the key management process" requires actual evidence.
- Scoped to your relationship -- Only ask questions relevant to the services they provide to you. If a vendor does not store your data, do not ask about their data retention policies.
Core Questions That Matter for SOC 2
For critical and high-risk vendors, these are the questions that directly map to SOC 2 requirements and produce useful information:
- Certifications and reports -- Do you have a current SOC 2 Type II report, ISO 27001 certification, or equivalent? Can you provide a copy?
- Data handling -- Where is our data stored geographically? Is it encrypted at rest and in transit? What encryption algorithms and key lengths are used?
- Access controls -- Who within your organization has access to our data? How is access granted, reviewed, and revoked? Do you enforce MFA for privileged access?
- Incident response -- What is your breach notification timeline? Who is our point of contact for security incidents? Can you provide your incident response policy?
- Subprocessors -- Do you use subprocessors that have access to our data? Who are they and where are they located?
- Business continuity -- What is your RTO and RPO? How often do you test backups and disaster recovery procedures?
- Security testing -- Do you conduct regular penetration testing? Can you provide a summary of your most recent test results?
- Employee security -- Do you perform background checks? What security awareness training do employees receive?
Continuous Vendor Monitoring: Beyond the Annual Questionnaire
An annual security questionnaire is the minimum. For critical vendors, your auditor will expect to see evidence of ongoing monitoring between formal assessments. This ties directly into your continuous monitoring program.
Practical Continuous Monitoring Approaches
- SOC 2 report renewals -- Set calendar reminders to obtain updated SOC 2 reports when vendors renew theirs (typically annually). Review for new exceptions or scope changes
- Security advisory monitoring -- Subscribe to your critical vendors' security advisories, status pages, and incident notifications
- Breach monitoring -- Use services like SecurityScorecard, BitSight, or even Google Alerts to monitor for disclosed breaches or security incidents at your vendors
- Contract renewal reviews -- Use contract renewals as a trigger to re-assess vendor risk and update security requirements
- Access reviews -- Periodically verify that vendor access to your systems is still appropriate and that terminated vendor personnel have been offboarded
For organizations using compliance automation platforms, many of these monitoring tasks can be partially automated. Platforms like Vanta and Drata integrate with vendor risk management tools to track SOC 2 report expiry dates, flag vendors without current certifications, and centralize questionnaire responses.
What Auditors Actually Look For in Vendor Management
Based on our experience supporting organizations through SOC 2 audits, here is what auditors consistently focus on during vendor management review. Understanding this helps you prioritize your efforts and avoid common audit findings.
Evidence Auditors Request
- Vendor inventory -- A current list of all vendors with risk classifications, data access descriptions, and assessment dates
- Vendor management policy -- A documented policy that describes your classification methodology, assessment procedures, and ongoing monitoring approach
- Assessment records -- Evidence of completed assessments for a sample of vendors across risk tiers during the audit period
- Subservice organization SOC 2 reports -- Copies of SOC 2 reports from your critical subservice organizations with evidence that you reviewed them
- CUEC mapping -- Documentation showing how you implement the Complementary User Entity Controls from your subservice organizations' reports
- Vendor contracts -- Sample contracts showing security requirements, data protection clauses, and breach notification obligations
Common Findings That Trip Organizations Up
- Incomplete vendor inventory -- Shadow IT is the biggest culprit. Teams adopt new SaaS tools without going through procurement, and those tools never make it into your vendor inventory
- Stale SOC 2 reports -- Your critical vendor's SOC 2 report expired 8 months ago and you never obtained the updated version. Auditors will check dates
- CUECs not implemented -- Your cloud provider's SOC 2 report lists 12 Complementary User Entity Controls. You have not documented which ones apply to you or how you fulfill them
- No evidence of assessment review -- You have vendor SOC 2 reports on file but no documentation showing that someone actually read and evaluated them
- Inconsistent classification -- Two vendors with identical risk profiles are classified differently, or a vendor that stores customer data is classified as low risk
- No offboarding process -- A vendor relationship ended 6 months ago but there is no evidence of data retrieval, access revocation, or account termination
Building Your Vendor Management Program: Step by Step
Here is a practical implementation guide for organizations building a vendor management program from scratch or significantly improving an existing one before their next SOC 2 readiness assessment.
Phase 1: Foundation (Weeks 1-2)
- Draft your vendor management policy covering classification criteria, assessment procedures, and monitoring requirements
- Build your vendor inventory by surveying department heads, reviewing expense reports, and auditing SSO/identity provider integrations
- Classify all vendors into risk tiers using the framework described above
- Identify your subservice organizations -- these are your highest priority
Phase 2: Assessment (Weeks 3-6)
- Request SOC 2 reports from all critical and high-risk vendors
- For vendors without SOC 2 reports, send your risk-weighted security questionnaire
- Review all received reports and questionnaire responses, documenting findings in your vendor risk register
- Map CUECs from subservice organization reports and document your implementation status
- Identify any vendors that require risk acceptance decisions and escalate to appropriate management
Phase 3: Contracts and Controls (Weeks 7-8)
- Review contracts with critical vendors for security requirements, breach notification clauses, and data protection obligations
- Negotiate contract amendments where existing agreements lack required security terms
- Implement any missing CUECs identified during the assessment phase
- Set up ongoing monitoring -- calendar reminders for annual reassessments, subscriptions to vendor security advisories
Phase 4: Operationalize (Ongoing)
- Integrate vendor assessment into your procurement process so new vendors are evaluated before onboarding
- Schedule annual reassessments for critical and high-risk vendors
- Maintain your vendor inventory as a living document, updating it when vendors are added or removed
- Conduct quarterly reviews of your vendor risk register with management
Vendor Management for Startups: Right-Sizing Your Program
If you are a startup pursuing SOC 2, the vendor management requirements can feel overwhelming. You are a 30-person company being asked to assess the security of Amazon Web Services. The key is proportionality.
For early-stage companies, focus on these essentials:
- Identify your top 5-10 critical vendors -- These are almost certainly your cloud provider, identity provider, code repository, monitoring tool, and any service that stores customer data
- Obtain their SOC 2 reports -- Most major SaaS vendors make these available through their trust centers or upon request under NDA
- Document your review -- A simple spreadsheet tracking vendor name, risk tier, SOC 2 report date, report findings, and your review date is sufficient for an initial audit
- Handle CUECs -- Read the CUECs in your cloud provider's SOC 2 report and document how you meet each one. This is the single most common vendor management gap in startup SOC 2 audits
Startup tip: Most major cloud providers, SaaS platforms, and infrastructure vendors publish SOC 2 reports. Check their trust center, compliance page, or security documentation first. If you cannot find it, email their security team directly. Requesting a SOC 2 report is a standard practice and they will have a process for sharing it.
As your company grows and your vendor ecosystem expands, you can mature your program by adding formal questionnaires, automated monitoring tools, and dedicated vendor risk management resources. But for your first SOC 2 audit, the basics done consistently will pass.
Connecting Vendor Management to Your Broader SOC 2 Program
Vendor management does not exist in isolation. It connects to nearly every other area of your SOC 2 compliance program:
- Risk assessment -- Vendor risks should be included in your organization's overall risk assessment and risk register
- Access controls -- Vendor access to your systems must follow the same user access review processes as employee access
- Incident response -- Your incident response plan should include procedures for vendor-related incidents and vendor breach notification
- Change management -- Changes to vendor services or new vendor integrations should go through your change management process
- Monitoring -- Vendor-related events (API failures, authentication anomalies, data transfer volumes) should be included in your monitoring program
The organizations that handle vendor management most efficiently are those that integrate it into existing processes rather than treating it as a separate compliance workstream. When vendor assessment is part of procurement, vendor monitoring is part of your security operations, and vendor risk is part of your risk register, the program runs itself.
Need Help with SOC 2 Vendor Management?
Lorikeet Security helps organizations build practical vendor management programs that satisfy SOC 2 requirements without creating unnecessary operational overhead. From readiness assessments to ongoing compliance support.
