Vendor Risk Management for SaaS Companies: The SOC 2 Control Most Teams Ignore Until It's Too Late
Every SaaS company relies on third-party vendors: Cloud infrastructure. Payment processing. Customer support tooling. HR platforms. Identity providers.
The average growth-stage SaaS company has somewhere between 40 and 100 active SaaS tools touching some part of their environment.
SOC 2 knows this. And it has a control for it.
CC9.2 requires that organizations identify, assess, and manage the risks introduced by vendors and business partners who have access to, or affect the security of, your systems and data. It is one of the most consistently under-built controls in SaaS SOC 2 programs, and one of the most reliably tested by auditors.
Here is what the control actually requires and how to build a vendor risk program that passes.
What CC9.2 Actually Requires
The control is not asking you to audit every vendor. It is asking you to demonstrate that you have a systematic process for evaluating the risk that vendors introduce and that you make access and procurement decisions based on that evaluation.
In practice, that means three things:
A vendor inventory. You need a documented list of vendors who have access to your systems or customer data, or whose availability affects your service delivery. This does not need to be every tool your company uses. It needs to cover the vendors whose failure or compromise would create a security or availability risk.
A risk assessment process. For each vendor in scope, you need evidence that you evaluated their security posture before granting access and that you revisit that evaluation periodically. For most vendors, this means reviewing their SOC 2 report, their security documentation, or their responses to a security questionnaire. For critical vendors, it may mean contractual security requirements.
Contractual protections. Vendors who process your customer data should have data processing agreements or security addenda in place. An auditor who asks for your DPA with a major sub-processor and finds none will flag it.
Where SaaS Teams Consistently Break Down
The vendor inventory is almost always incomplete. Teams think of their AWS or Azure environment as their infrastructure and forget that their customer support platform, their analytics tool, and their error monitoring service all have access to production data. If a vendor can read, write, or transmit data that is in scope for your SOC 2, they belong in your vendor inventory.
The review cycle stalls after the initial assessment. A vendor assessment conducted at procurement and never revisited is not a vendor risk program. It is a one-time checkbox. SOC 2 auditors look for evidence that vendor risk is reviewed on a defined schedule, not just at onboarding.
Security questionnaires are sent but never evaluated. Many teams send a questionnaire as a procedural step and file the response without actually reviewing it against a risk threshold. An auditor who asks what your process is for acting on questionnaire responses — and finds no documented evaluation — will note the gap.
The Sub-Processor Question
If your product processes customer data, your customers care about who else touches that data. Enterprise buyers frequently ask for a list of sub-processors as part of procurement. SOC 2 auditors test whether your sub-processor relationships are governed. Both of those pressures converge on the same requirement: you need to know who your sub-processors are, what data they access, and whether they meet your security requirements.
This is not just a compliance exercise. A sub-processor that experiences a breach can trigger your breach notification obligations. Knowing your sub-processor landscape is operational risk management, not just audit preparation.
Building a Program That Is Actually Sustainable
Vendor risk management fails in most SaaS companies not because the requirement is unclear but because no one owns it. Engineering owns the tools. Finance owns the contracts. Legal owns the DPAs. No one owns the risk view that connects them.
A functional vendor risk program requires a single owner, often whoever owns the compliance program, with a defined process for onboarding new vendors, an annual review cycle, and a clear threshold for what level of risk triggers escalation or contract remediation.
It does not need to be complex. It needs to be documented, executed, and evidenced. Our compliance program services include building vendor risk governance into your broader control environment so it does not exist in isolation.
Book a discovery call to discuss where your vendor program currently stands.
