SOC 2 Vendor Risk Management: What Auditors Check and How to Prepare
Understand what vendor risk management means in a SOC 2 context, which vendors fall in scope, what documentation auditors require, and how to build a simple vendor review process that holds up during the audit.
Introduction
When organizations prepare for a SOC 2 audit, vendor risk management is one of the controls they most consistently underestimate. The access controls get attention. The change management process gets built. The logging infrastructure gets configured. But the vendor review program — the documented process for identifying which third parties touch your environment, assessing their security posture, and monitoring them over time — often gets assembled in the weeks before the audit rather than built as an ongoing operational discipline.
Auditors notice this pattern immediately. A vendor inventory that was clearly compiled for the audit rather than maintained throughout the year. Review records that all share the same date. Documentation of vendor security assessments that describes what vendors say they do rather than what you have independently verified. These are the hallmarks of a vendor program that exists for compliance rather than security — and they are among the most common sources of control exceptions in first-time SOC 2 programs.
This guide explains what vendor risk management actually means in the SOC 2 context, which vendors belong in scope and how to identify them, what documentation auditors specifically look for, and how to build a vendor review process that is simple enough to operate year-round and rigorous enough to hold up when the auditor arrives.
What Vendor Risk Management Means in a SOC 2 Context
Vendor risk management in SOC 2 is not a general business practice about getting good pricing or ensuring delivery timelines. It is a specific security control category that addresses a particular risk: when you outsource functions to third parties, you extend your trust boundary — and if those third parties have weak security controls, your commitment to protect customer data may be undermined by a vendor whose controls you cannot directly observe or enforce.
The AICPA addresses this through the Common Criteria, specifically CC9.2, which requires that organizations identify, assess, and manage the risks that arise from the use of vendors and business partners that could affect the achievement of the organization's service commitments. The requirement is not that your vendors be perfectly secure — it is that you have a defined, documented, and operating process for understanding and managing their security posture.
This means three things in practice.
First, you need to know which vendors are relevant to the security of your in-scope systems and customer data. A vendor that provides office supplies is not relevant. A vendor that hosts your production database infrastructure is critically relevant. The process of identifying which vendors fall in scope is the foundation of the entire program.
Second, you need to assess those vendors' security controls at onboarding and on a recurring basis. The form of that assessment varies — reviewing a vendor's SOC 2 report is the most common approach — but the substance is the same: you need documented evidence that you evaluated the vendor's security posture rather than simply assuming it is adequate.
Third, you need to respond to vendor-related risks when they surface. A vendor that cannot produce a current SOC 2 report. A vendor whose SOC 2 report contains significant exceptions. A vendor that notifies you of a security incident. Your program needs documented processes for each of these scenarios.
That is the full scope of what auditors examine: identification, assessment, and response. Each element needs to be demonstrable through evidence that covers the observation period, not just the weeks before the audit.
Which Vendors Fall In Scope
Determining which vendors belong in your SOC 2 vendor risk program is a scoping decision with the same logic as audit scoping generally: if a vendor has a meaningful connection to the security of your in-scope systems or the protection of customer data, they belong in scope.
The practical test is one of three conditions.
The vendor has access to customer data. A vendor whose systems process, store, or transmit customer data on your behalf is the clearest case for scope inclusion. This includes cloud infrastructure providers, managed database services, data processing platforms, customer support tooling with access to customer records, and analytics platforms that receive customer data.
The vendor's service is integral to the delivery of your in-scope system. Some vendors do not touch customer data directly but provide services without which your production environment could not function securely. Your identity provider. Your secrets management platform. Your logging and monitoring infrastructure. Your CDN. If this vendor's service fails or is compromised, the security of your customer-facing system is materially affected.
The vendor can affect the confidentiality, integrity, or availability of your in-scope system through the access or influence they have. Penetration testing firms with network-level access to production. Managed security service providers monitoring your environment. Incident response firms with access to your logs. These vendors do not process customer data in the course of normal operations, but they have access that, if misused or compromised, could affect customer data.
Vendors That Are Commonly Missed
Certain vendor categories appear in-scope more frequently than organizations initially recognize.
Subprocessors that handle customer data on behalf of a customer request. If your application sends customer data to a third-party service — an email delivery provider, an SMS platform, a payment processor, a data enrichment service — in response to normal product functionality, that vendor is a subprocessor. Their handling of that data is part of your data protection obligation, and auditors look for evidence that you have assessed and monitor their security.
Development and deployment tooling with production access. CI/CD platforms, code hosting services, and deployment tools that have credentials to deploy to production infrastructure are vendors with meaningful security relevance. A compromised CI/CD platform that can push arbitrary code to your production environment is a significant supply chain risk. Auditors who understand modern cloud architectures increasingly examine these vendors specifically.
Infrastructure-as-a-Service providers at the component level. Many organizations correctly identify their primary cloud provider — AWS, GCP, Azure — but do not separately identify the individual services within that provider that have different security characteristics. A managed Kubernetes service, a serverless compute platform, and an object storage service from the same cloud provider may each warrant separate assessment documentation because their security models differ and auditors may want to see that you assessed each one relevant to the data it handles.
AI and machine learning service providers. Organizations integrating AI APIs into their products — sending customer data to large language model APIs or AI platform services for processing — have added vendors with specific data handling characteristics that were not present in prior compliance cycles. Auditors are increasingly attentive to how AI vendor data handling commitments are assessed and documented, particularly regarding training data use and data retention by the vendor.
Vendors That Are Typically Out of Scope
Understanding which vendors do not belong in scope is as important as knowing which do. Including every vendor your organization uses creates a program that is impossible to maintain and generates noise that obscures the vendors that actually matter.
Vendors with no access to in-scope systems or customer data — office supply vendors, travel management platforms, recruiting tools — are out of scope. Corporate productivity tools that are segregated from production systems — email, calendar, project management tools for non-technical teams — are typically out of scope unless they have specific integrations that create data access. Physical security vendors for office locations are out of scope for most SaaS organizations whose SOC 2 scope does not include physical office infrastructure.
Document the rationale for exclusion decisions the same way you document inclusion decisions. Auditors do not just verify that your in-scope vendor list is adequate — they sometimes ask why certain vendors are not included. A documented rationale for each significant exclusion prevents that question from becoming a discussion that delays the audit.
What Documentation Auditors Require
Auditors examining vendor risk management are looking for a specific evidence profile. Knowing exactly what they want to see — and building your program around producing that evidence naturally — eliminates most of the last-minute scrambling that characterizes poorly designed vendor programs.
The Vendor Inventory
The starting point is a vendor inventory: a documented list of in-scope vendors that identifies who they are, what service they provide, what customer data they access or process, and their risk classification. The inventory should reflect the state of your vendor relationships throughout the observation period, not just at audit time.
An inventory that was clearly assembled in the weeks before the audit — vendors added in a batch, uniform review dates, no history of changes — does not demonstrate ongoing monitoring. An inventory that shows vendors added when onboarded, removed when relationships ended, and reviewed on a documented schedule demonstrates a living process.
A practical format for the vendor inventory includes: vendor name, service category, data types accessed, criticality classification (critical, high, standard), review frequency, last review date, next review date, and the outcome of the most recent review.
Vendor Assessment Documentation
For each in-scope vendor, auditors expect to see evidence that you assessed their security posture. The most common form of evidence is a review of the vendor's SOC 2 report — and this is where many vendor programs produce documentation that does not hold up.
Simply collecting a vendor's SOC 2 report and filing it is not a vendor assessment. An assessment requires evidence that someone reviewed the report, understood its scope and findings, and formed a conclusion about the vendor's suitability and any residual risks. Auditors look for review documentation that demonstrates: who reviewed the vendor's report, when the review was completed, what the scope of the vendor's SOC 2 covered and whether it aligns with the service they provide to you, whether the vendor's report contained exceptions, and what your conclusion was about the vendor's security posture.
A one-page assessment summary per critical vendor — written by the person who reviewed the documentation, signed or dated, describing what was reviewed and what was found — is a significantly stronger evidence artifact than a folder of collected PDFs.
Contractual Security Terms
Auditors also look for evidence that vendor relationships are governed by contracts that include security obligations. At minimum, in-scope vendor contracts should include: confidentiality or data protection provisions, an obligation to notify you of security incidents within a defined timeframe, the right to audit or review the vendor's security posture (even if you do not exercise it), and data handling and disposal requirements appropriate to the data the vendor accesses.
For vendors that process personal data on your behalf, data processing agreements (DPAs) are required under major privacy regulations — GDPR, CCPA, and others — and auditors will look for them as part of the vendor risk control evidence.
Keep executed copies of relevant contract sections or full agreements organized and retrievable. An auditor asking for the data processing agreement with your primary cloud logging vendor should produce a document in minutes, not a multi-day search through legal archives.
Ongoing Monitoring Evidence
The ongoing monitoring requirement is where vendor programs most commonly produce insufficient evidence. Auditors reviewing a Type II report expect to see that vendor security posture was not just assessed at onboarding but monitored throughout the observation period.
For critical vendors, this typically means an annual review — at minimum — with documented evidence of the review. For vendors with significant data access, more frequent monitoring may be appropriate when they publish security updates, notify you of incidents, or release new SOC 2 reports.
Evidence of ongoing monitoring can take several forms: records of your annual review dates with review documentation, a log of vendor-initiated security notifications and your response to them, records of quarterly or semi-annual check-ins with critical vendors on security topics, and evidence that you obtained and reviewed updated SOC 2 reports when vendors renewed their audits.
What does not constitute evidence of ongoing monitoring: the fact that you have a vendor contract, the fact that the vendor has a SOC 2 report that you downloaded once, or the fact that you have not received any security incident notifications from the vendor.
Incident and Risk Response Records
If any vendor notified you of a security incident during the observation period, auditors will look for evidence of how you responded: your initial assessment of the impact, any notification obligations you fulfilled to customers, the remediation steps the vendor took and your evaluation of their adequacy, and the outcome of your review of whether the vendor relationship should continue unchanged.
Similarly, if a vendor failed to produce a current SOC 2 report or if their report contained significant exceptions, auditors will look for evidence of a risk acceptance or risk treatment decision — documentation that you were aware of the gap and made a deliberate decision about how to manage it.
Risk acceptance is a legitimate outcome of vendor assessment. A vendor with an important service that does not have a SOC 2 report can still be an acceptable vendor if you have documented compensating controls — contractual security terms, the ability to audit the vendor, alternative evidence of their security posture. What is not acceptable is simply ignoring the gap.
How to Build a Vendor Review Process That Holds Up
The common failure mode in SOC 2 vendor programs is building a process that is too complex to maintain consistently. A vendor program with elaborate risk scoring matrices, multi-stage approval workflows, and quarterly business reviews for every vendor is theoretically rigorous but practically unsustainable for most organizations. When the process is too burdensome, people stop following it — and the result is a program that looks good on paper and has no evidence of operation in practice.
The right design principle is minimum viable rigor: the simplest process that produces the evidence auditors require, that the team will actually operate year-round, and that scales as your vendor footprint grows.
Step 1: Build and Maintain Your Vendor Inventory
Assign ownership of the vendor inventory to a specific person or team. It does not need to be a dedicated role — it can be the security team, the compliance team, or a designated member of operations or legal. What matters is that someone is responsible for keeping it current.
Establish a trigger-based update process: the inventory gets updated when a new vendor is onboarded, when a vendor relationship ends, and when a material change occurs in an existing vendor relationship. Do not rely on periodic audits of the inventory — rely on process triggers that occur naturally as vendor relationships change.
At minimum quarterly, the inventory owner reviews the list for completeness and flags any vendor that is approaching their next review date. This is a 30-minute task if the inventory is current. It becomes a multi-day project if it has been neglected.
Step 2: Classify Vendors by Risk Tier
Not all vendors require the same level of assessment effort. A risk-tiered classification system allows you to focus your assessment resources on the vendors whose security posture matters most.
A simple three-tier model works for most organizations.
Critical vendors are those whose compromise or failure would have a direct and immediate impact on the security or availability of customer data. Primary cloud infrastructure providers, production database services, identity providers, and core application dependencies fall here. These vendors receive the most thorough assessments, the most frequent reviews, and the most detailed documentation.
High-risk vendors are those with access to customer data or in-scope systems but whose compromise or failure would have a bounded rather than systemic impact. Sub-processors with limited data access, monitoring and alerting services, and support tooling with access to customer records typically fall here.
Standard vendors are those with indirect relevance to in-scope systems — no direct customer data access but services that are part of the broader operational environment. These receive a lighter-touch assessment focused primarily on confirming that appropriate contractual terms are in place.
Step 3: Define the Assessment Standard for Each Tier
For each risk tier, define explicitly what evidence you require before approving the vendor and what the recurring review will examine. Write this down in a vendor management policy or procedure document.
For critical vendors, a reasonable standard is: current SOC 2 Type II report (or equivalent) with scope covering the services they provide, a documented review of that report including exceptions and your assessment of them, executed contract with data protection and incident notification terms, and an annual review that repeats this process with the updated report.
For high-risk vendors, the standard can be lighter: a current SOC 2 report or equivalent security documentation, a brief documented assessment confirming scope adequacy, and appropriate contractual terms.
For standard vendors, the minimum is confirming that appropriate confidentiality and data handling terms are in contract.
Having this standard written down means that when a new vendor is onboarded, the team knows exactly what to collect and document — and when an auditor asks how you assess vendors, you have a process document to show them rather than a verbal description of what you try to do.
Step 4: Implement the Review Calendar
Vendor reviews should happen on a scheduled cadence, not reactively. Build your review calendar into your compliance tracking system — whether that is a dedicated compliance platform, a project management tool, or even a well-maintained spreadsheet.
For critical vendors, schedule reviews annually, timed to coincide with when vendors typically renew their SOC 2 audits. Most SOC 2 reports cover a 12-month observation period and are issued in the first quarter of the following year. Scheduling your vendor reviews in Q1 and Q2 means you are likely to have current reports available when you conduct them.
Assign each review to a named owner with a completion deadline. Reviews that are owned by a team rather than a person consistently get deferred when they compete with other priorities.
Step 5: Document Assessments as You Complete Them
Each completed vendor review should produce a record that answers four questions: what did you review, when did you review it, what did you find, and what is your conclusion.
This documentation does not need to be elaborate. A one- to two-page assessment summary per vendor per review cycle — saved in your vendor documentation repository with a consistent naming convention and the date of completion — is adequate evidence of a functioning review process for most audit purposes.
If the vendor's report contained exceptions, add a fifth element: what is your assessment of the significance of those exceptions for the services they provide to you, and what if anything are you doing to manage the residual risk.
The total time investment for a well-organized vendor review should be two to four hours per critical vendor per year: time to obtain and read the updated report, time to write the assessment summary, and time to confirm that contractual terms remain current. If it is taking significantly longer, the process has unnecessary friction that will cause people to deprioritize it.
Reading Vendor SOC 2 Reports: What to Actually Look For
Collecting vendor SOC 2 reports is not the same as reviewing them. An assessment that documents "vendor has SOC 2 Type II report" without any analysis of its contents provides minimal security value and is not what auditors mean when they require evidence of vendor assessment.
When reviewing a vendor's SOC 2 report, focus on four things.
Scope alignment. Does the vendor's SOC 2 scope cover the services they provide to you? A cloud vendor whose SOC 2 covers their data center operations but not the specific managed services you use has a scope gap that is worth documenting. A payment processor whose SOC 2 covers transaction processing but not the fraud detection service you also use has a similar issue.
Observation period currency. Is the report current? A SOC 2 report that covers an observation period ending 18 months ago is significantly less useful than one covering the past 12 months. For critical vendors, push for current reports — most audit firms issue updated reports annually and vendors with mature compliance programs can provide them.
Exceptions and qualified opinions. Read the test results section for exceptions. Identify whether any exceptions affect controls relevant to the services you use. An exception in the vendor's change management controls is relevant to you if the vendor is making changes to services you depend on. An exception in a control area unrelated to your use case may be less material.
Complementary user entity controls. Many vendor SOC 2 reports include a section on complementary user entity controls — controls that the vendor's system assumes you, the customer, are implementing. If a vendor's report assumes that customers enforce MFA and you are not enforcing MFA on your accounts with that vendor, you have a gap in your own control environment that the vendor's SOC 2 does not cover.
Document your findings from each of these four areas in your assessment summary. This analysis is what distinguishes a genuine vendor assessment from a document collection exercise.
Handling Vendors That Cannot Produce a SOC 2 Report
Not every vendor will have a SOC 2 report, particularly smaller vendors, recently founded companies, and vendors in markets where SOC 2 has not yet become the baseline expectation. This is a real operational challenge for vendor programs, and auditors understand that you cannot refuse to use any vendor that lacks a SOC 2.
What auditors do expect is that you have a documented process for managing the additional risk these vendors present.
When a vendor cannot produce a SOC 2 report, the appropriate response depends on the vendor's risk tier. For standard vendors, strong contractual terms and a vendor security questionnaire are typically adequate. For high-risk vendors, add a more detailed security questionnaire, ask for any available security certifications or penetration test results, and document your assessment of the responses. For critical vendors, the absence of a SOC 2 report is a significant risk factor that warrants either escalating to the vendor with a request for a timeline toward SOC 2 certification, engaging directly with the vendor's security team for a more thorough technical assessment, or seriously evaluating whether the vendor is appropriate for the function they are performing.
In all cases, document the gap, your assessment of the risk it creates, and the compensating measures you have implemented. An auditor seeing a critical vendor without a SOC 2 report and no documented risk assessment will flag it as a finding. An auditor seeing the same gap with documented risk acceptance, a security questionnaire on file, enhanced contractual terms, and a note that you have requested a timeline for the vendor's SOC 2 certification demonstrates a functioning risk management process.
The Vendor Risk Management Conversation Auditors Are Actually Having
Auditors assessing vendor risk management in 2026 are asking more sophisticated questions than they were five years ago, driven by changes in how cloud-native organizations use third-party services and by the supply chain security incidents that have affected the industry.
They are specifically asking about AI vendor data handling — particularly whether organizations that use AI APIs have assessed how those vendors handle data submitted through their APIs, whether training data use is contractually restricted, and whether the vendor's data retention and deletion commitments are documented and reviewed.
They are asking about CI/CD pipeline security more thoroughly, treating deployment infrastructure as a critical component of the production change management control rather than as out-of-scope developer tooling.
They are asking about how organizations identify and respond to new vendor risks that emerge during the observation period — not just the scheduled annual reviews, but the process for responding when a vendor publishes a security advisory, discloses an incident, or when a major supply chain event affects a dependency your vendors use.
Building your vendor program to address these questions specifically — not just the baseline CC9.2 requirements — puts you in a significantly stronger position in the audit conversation and better positions your security program for the actual risks that third-party relationships create.
Conclusion
Vendor risk management is one of the SOC 2 control categories where the gap between a compliant program and an effective program is most visible. A compliant program has a vendor list, some collected documentation, and contracts with security terms. An effective program has a living inventory, documented assessments that demonstrate real analysis, a review calendar that operates year-round, and processes for responding when vendor security posture changes.
Auditors can tell the difference. More importantly, a vendor program that functions as a real security control actually reduces the risk that a third-party relationship undermines the customer data protection commitments you have made.
Build the inventory now, before the audit. Define the review standard before you need to execute it. Run the assessments on a schedule rather than a sprint. Document what you find and what you decided. And when the auditor asks how you manage vendor risk, your answer will be a process that has been operating all year rather than a program assembled in response to the question.