What does CC9.1 require for vendor management?

CC9.1 requires you to identify, assess, and monitor vendors that affect the security, availability, or confidentiality of your systems. This means maintaining a vendor inventory, assigning risk tiers, collecting security documentation from critical vendors (SOC 2 reports, ISO 27001 certs), and reviewing vendors on a defined schedule. You must also have a process for assessing new vendors before onboarding them.

Which vendors need to be in my SOC 2 vendor inventory?

Any vendor that has access to your systems or customer data, or whose failure would materially affect your service. This typically includes: cloud providers (AWS, GCP, Azure), identity providers (Okta, Google Workspace), code repositories (GitHub), monitoring tools (Datadog, PagerDuty), payment processors (Stripe), CRM and support tools with customer data (Salesforce, Intercom), and AI tools that receive company or customer data.

How often do I need to review vendors for SOC 2?

Annual reassessment is the standard for critical vendors. This means collecting their latest SOC 2 report or ISO 27001 cert once per year, reviewing it for new exceptions or scope changes, and documenting the review. High-risk vendors (those with direct access to customer data in production) warrant more frequent review. New vendors should be assessed before they are onboarded.

What if a vendor does not have a SOC 2 report?

Not every vendor will have a SOC 2 report, especially smaller tools. For vendors without SOC 2, you can use alternative evidence: an ISO 27001 certificate, a security questionnaire response, a review of their published security page, or a contractual security addendum. Document what evidence you collected and why it was sufficient. For critical vendors with no security documentation at all, consider whether the risk is acceptable.

Do AI tools like ChatGPT and GitHub Copilot need to be in my vendor inventory?

Yes. AI tools that receive company or customer data are vendors under CC9.1 and must be in your vendor inventory. This includes OpenAI, Anthropic, Microsoft (for Copilot), GitHub (for Copilot), and any other AI provider your team uses. Each should have a Data Processing Agreement on file, a current SOC 2 or ISO 27001 report, and a risk tier assigned. This is one of the most commonly cited gaps in 2026 SOC 2 audits.

SOC 2 vendor management: how to satisfy CC9.1

Vendor management is the SOC 2 control that surprises founders most often. You expect to be asked about your own security posture. You do not expect to be asked about every third-party tool your team uses. CC9.1 makes that expectation explicit, and it is one of the easier controls to fail if you do not have a process in place before audit fieldwork begins.

SOC 2 vendor management checklist: 5 controls auditors test

What CC9.1 actually requires

CC9.1 falls under the Risk Mitigation criteria. The control text says the entity identifies, selects, and develops risk mitigation activities for risks arising from potential business disruptions, including those arising from vendor relationships. CC9.2 then extends this to ongoing assessment, requiring the entity to assess and manage risks associated with vendors and business partners.

In practice, the auditor wants to see four things. A complete inventory of vendors with access to your systems or customer data. A documented assessment of each vendor performed at onboarding. An annual or risk-based reassessment of those vendors. A defined process for offboarding vendors when relationships end.

The threshold for inclusion is generous. Any vendor that touches customer data, processes authentication, hosts your code, or holds the credentials needed to do any of these is in scope. Marketing tools, accounting software, and snack delivery services are usually out of scope. The grey area in the middle is where most companies underscope and get findings.

Which vendors are in scope

A vendor lands in scope if any of the following are true. The vendor processes, stores, or transmits customer data on your behalf. The vendor has authenticated access to a production system. The vendor has access to source code. The vendor has access to employee credentials, identity systems, or single sign-on infrastructure. The vendor handles payments, financial data, or sensitive personal information.

Common vendors that almost always fall in scope for SaaS startups include cloud infrastructure providers like AWS, GCP, or Azure, source control like GitHub or GitLab, identity providers like Okta or Google Workspace, payment processors like Stripe, observability and logging tools like Datadog or Sentry, customer support platforms like Zendesk or Intercom, and any analytics provider that receives event data.

Less obvious but commonly in scope are tools like Notion, Slack, and Linear. If your team puts customer data, security incident notes, or production credentials into a shared workspace, that workspace vendor is now in your assessment scope. This is the most common gap auditors find.

Building the vendor inventory

Start with a spreadsheet listing every paid SaaS subscription. Pull this from your finance system, your single sign-on dashboard, and your expense reports. Add free tools your team actually uses, especially those tied to engineering or operations.

For each vendor, capture the vendor name, the data classification of what they touch, the business owner internally, the criticality tier, the contract or subscription start date, the most recent assessment date, the outcome, and the next reassessment date. This spreadsheet is your primary evidence artifact for CC9.1. Auditors will request it directly.

A complete inventory for a fifteen-person startup typically lands between twenty and fifty vendors. If your list has fewer than fifteen, you are probably missing some.

The assessment process

For each in-scope vendor, perform an assessment at onboarding and at least annually. The assessment depth should scale with the vendor's risk tier.

For critical vendors handling production data or core authentication, request and review a current SOC 2 Type II report or an equivalent independent attestation such as ISO 27001 certification. Read the report, note any exceptions or qualifications, check the audit period covers a recent window, and verify the scope includes the services you actually use. Save the report and your review notes.

For standard vendors with access to less sensitive data, a security questionnaire from the vendor or a review of their published trust center is usually sufficient. If neither exists, escalate the vendor to critical-tier review or replace it.

For low-risk vendors with no data access, a brief justification noting why no further review is needed is enough.

Document the outcome of every assessment. The outcome is not just pass or fail. It includes any compensating controls you rely on, any contractual terms that mitigate residual risk, and any tracking items that need to be revisited.

Risk tiers

A simple two-tier or three-tier model works well for most companies under one hundred employees. Critical vendors require a SOC 2 or equivalent attestation, an executed data processing agreement, and an annual reassessment. Standard vendors require a questionnaire or trust center review and an annual confirmation that nothing has materially changed. Optional low-risk vendors get a one-line justification at onboarding and no recurring review.

Define the tiers in your vendor management policy and apply them consistently. Auditors compare your defined process to the actual evidence, so a stated process you do not follow is worse than no process at all.

What evidence auditors want

The vendor inventory spreadsheet is the primary artifact. Alongside it, expect to provide the underlying assessment evidence for at least a sample of vendors, typically the critical-tier ones and a random selection of standard-tier ones. That sample evidence includes the SOC 2 reports themselves, your review notes, the executed data processing agreements, and any communications with the vendor about security questions.

Auditors also want to see your vendor management policy, the process for adding new vendors, and proof that procurement or engineering actually follows the process. If your policy says new vendors require a security review before onboarding, the auditor may sample recent vendor additions to confirm reviews happened in time.

The most common mistake

Common gap

The single most common CC9.1 finding is incomplete vendor inventory. Companies focus on the obvious infrastructure providers like AWS and forget the workspace tools where engineers paste credentials into a Notion page or share customer data in a Slack DM. These tools have access by virtue of what your team puts into them, even if no formal integration exists.

Audit your team's actual data flow, not just your formal integrations. If a tool can read customer information, it is a data processor and it belongs in scope.

Making this sustainable

Vendor management is a recurring operational burden if you treat it as a spreadsheet you update by hand. The pattern that works is automated discovery from your single sign-on system and expense data, automated reminders when reassessment dates approach, and a single source of truth for assessment evidence that auditors can access directly.

This is one of the workflows that compliance automation handles natively, replacing the spreadsheet plus ad-hoc folder structure with a system that already knows which vendors are in scope and when each was last reviewed.

Next steps

A fractional CISO owns vendor discovery and assessment tracking for you, so CC9.1 stays covered as your vendor list grows. Read the full SOC 2 control requirements to understand how CC9.1 connects to the rest of the framework, or book a call.

Want a security leader to run this?

Xorabyte is a fractional CISO for startups who can answer a blocked security questionnaire, so a blocked deal or an audit stops being your problem to carry alone. Book a call and you will leave with a clear path, not a sales pitch.