Compliance
How to Automate SOC 2 CC9.2 Vendor Risk Assessments Beyond Questionnaires
Build vendor assessment records that link source material, risk decisions, and follow-up. Includes a review template for missing or restricted SOC 2 reports, the limits of public trust-center evidence, and questions to resolve before upgrading a plan or migrating infrastructure.

Sending 50 vendor security questionnaires is the easy part of SOC 2 compliance. The hard part is getting 50 replies, reviewing 50 distinct audit reports, and generating the evidence documentation that proves you actually read them.
While GRC platforms like Drata and Vanta have automated the sending of questionnaires, the collection of evidence for vendor risk management often remains a manual chase. Major vendors like AWS, Slack, and GitHub will not fill out your questionnaire; they will point you to a public trust center. Your auditor doesn't just want to see that you have their SOC 2 report, they want proof you assessed the third-party risk and documented your review.
Automation now exists to bridge this gap, capturing trust center screenshots and recording internal review workflows to satisfy SOC 2 CC9.2 without the spreadsheet fatigue.
What Evidence Do Auditors Actually Require for CC9.2?
The common misconception about SOC 2 CC9.2 is that "having the vendor's SOC 2 report" is the control. It isn't. The control is the management of the risk, which implies a process.
Build a review record appropriate to each vendor's risk and your approved vendor management process. Useful components include:
- The Artifact: The vendor's SOC 2 Type II report, ISO 27001 certificate, or a completed security questionnaire.
- The Review: Documentation showing a qualified person on your team reviewed the artifact, evaluated relevant exceptions, reviewed Complementary User Entity Controls (CUECs), and documented the decision to use the vendor. CUECs describe controls the customer is expected to operate; they are not audit exceptions.
- The Risk Ranking: Evidence that you classified the vendor (e.g., Critical, High, Low) based on the data they access.
If you simply dump 50 PDFs into a folder, you will likely receive an observation or a deficiency. The auditor needs to see the review workflow.
Where Traditional Vendor Risk Management Tools Stop
Most GRC platforms handle the "happy path" of vendor management well: you enter a vendor's email, the system sends a questionnaire, the vendor replies, and the system flags it as complete.
Check how your actual platform handles gated reports, vendors with no report, and the review decision. Available features and support depend on the service and contract.
| Vendor Type | Standard GRC Approach | The Automation Gap |
|---|---|---|
| Enterprise SaaS (AWS, Slack, GitHub) | System sends questionnaire. Vendor ignores it or auto-replies with a link. | You must manually visit their Trust Center, download the report, take a screenshot of the validity period, and upload it manually. |
| Micro-SaaS (New AI tools) | System sends questionnaire. Vendor has no SOC 2 and answers vaguely. | You need to capture their Terms of Service or Security Page as "best effort" evidence, which requires manual screenshots. |
| The "Review" Step | Platform provides a text box to type "Reviewed." | Auditors often prefer a timestamped ticket (Jira/Asana) showing the review was assigned and completed, rather than just a metadata tag in a tool. |
This is where third-party risk automation often fails: it assumes every vendor is a cooperative human willing to fill out a form. Real-world automation needs to handle public URLs and internal review tickets.
How Can You Automate Evidence for Public Trust Centers?
For vendors like Salesforce, Atlassian, or AWS, the "evidence" is a public-facing URL or a gated download portal. You cannot automate this via API because there is no standardized "Download SOC 2" API across the internet.
Instead of manually visiting these sites every year, you can use browser-based automation tools or AI agents to capture the evidence.
The Automated Workflow
- Identify the URL: Map your "Critical" vendors to their security URLs (e.g.,
trust.salesforce.com). - Scheduled Capture: Configure a tool (like Screenata) to visit that URL annually.
- Evidence Generation: The tool captures a full-page screenshot showing the current compliance status (e.g., "SOC 2 Type II - Valid through Dec 2026").
- Timestamping: The screenshot is timestamped and converted into a PDF evidence pack.
A public status capture records what the vendor claimed at the time. It does not reveal the audit scope, opinion, exceptions, or CUECs in a gated report. Use it as one input to a risk-based assessment, and document the limits rather than marking it equivalent to the report.
How Do You Document the "Review" Phase Automatically?
The most tedious part of vendor risk management is the "Review Memo." Auditors want to see that you checked the vendor's Complementary User Entity Controls (CUECs), the things you are supposed to do, like setting up MFA on your account.
Creating a separate Word doc for every vendor review is overkill. Instead, move the review process into your existing ticketing system (Jira, Linear, Asana) and automate the evidence collection of that ticket.
Step-by-Step Implementation
- Create a Ticket: When a vendor is due for review, create a ticket: "Security Review: [Vendor Name]".
- Use a Template: In the ticket description, paste a simple checklist:
- Report covers the correct period?
- Opinion is unqualified (clean)?
- CUECs reviewed?
- Risk Rating: [Low/Med/High]
- Complete the Work: An engineer or security manager checks the boxes and closes the ticket.
- Automate the Proof: Use an evidence automation tool to snapshot the closed ticket.
This approach is superior to GRC platform checkboxes because it preserves the chain of custody. It shows exactly who reviewed it, when they finished, and any comments they left during the process. It turns your normal work (closing tickets) into audit-ready evidence.
Handling vendors whose SOC 2 report is missing or unavailable
A vendor may have no report, restrict access to certain plans, or require an NDA. Distinguish these cases. An inaccessible report is not evidence that the vendor lacks controls, and a public compliance badge does not establish what the report covers.
Before upgrading a subscription or migrating infrastructure, ask which evidence your assessment needs. Confirm the vendor's current access terms, then discuss possible alternatives with your auditor. Requirements in a customer contract need their own resolution with the customer.
Copy this vendor review record
Vendor and service: [name and product used]
Data and access: [data processed, privileges, business dependency]
Risk classification: [rating and rationale]
Report status: [not issued, restricted access, or request pending]
Access request: [date, vendor response, and access conditions]
Sources reviewed: [documents or URLs, versions, dates, reviewer]
Findings: [controls evidenced, gaps, and unanswered questions]
Our responsibilities: [configuration and operational safeguards]
Limitations: [what the available material cannot establish]
Decision: [approve with conditions, request more evidence, or decline]
Decision-maker: [authorized owner and date]
Follow-up: [action, owner, due date, next review]
Possible sources include security documentation, a relevant certification and its scope, completed questionnaires, contractual commitments, and your own configuration evidence. They provide different levels of assurance. Do not present a screenshot of a security page as equivalent to an independent examination of operating effectiveness.
If the evidence is insufficient for a critical dependency, escalate the gap and options to the authorized risk owner. An internal approval does not bind the auditor or the buyer to accept the arrangement. Record any restrictions and follow-up, rather than silently marking the vendor complete.
For a concrete access restriction, the Supabase and PlanetScale answer links Supabase's current report-access policy.
Automating the Annual Re-Assessment Loop
Set reassessment dates from your vendor management process and the vendor's risk. Include reviews triggered by material changes in the service, data use, incidents, or contractual commitments.
The failure mode for most companies is forgetting to review vendors in Year 2. By the time the audit comes, you have 12-month-old evidence.
To solve this, set your automation tool to run on a recurring schedule. If you use Screenata or similar agentic tools, you can configure a "Vendor Health Check" frequency. The system will revisit the Trust Center URLs or check for new Jira review tickets every 12 months automatically.
Automated collection can preserve current source material, but an owner still needs to evaluate it and resolve findings. Keep the review decision and its rationale linked to the sources collected.
Learn More About SOC 2 Evidence Automation
For a complete guide to automating SOC 2 evidence collection, see our guide on automating SOC 2 evidence collection, including how to handle application-level controls and manual workflows.
Connect and see
See your SOC 2 with your real systems.
Connect GitHub and cloud read-only. Vera shows your control matrix, policy gaps, and prioritized next actions before you commit to anything.