SOC 2 Vendor Management: The Minimum Viable Process
Auditors do not expect a full-time vendor risk team at a 20-person company. What they do expect, at minimum, is that you know who your key vendors are, understand what access or data they have, and review them on some regular, documented basis.
This guide covers exactly what that minimum looks like, grounded in the actual AICPA requirement, plus a vendor register template you can start using today. If you want this handled for you rather than built from scratch, our SOC 2 compliance services cover vendor management as part of a broader readiness engagement.
Where This Requirement Actually Comes From
Vendor management in SOC 2 is not a vague best practice, it is a specific requirement under AICPA Common Criteria CC9.2, which states that your organisation must assess and manage risks associated with vendors and business partners. The AICPA breaks this down into 13 Points of Focus, example controls that could satisfy the requirement, not a mandatory checklist where you need all 13.
Two of the 13 only apply if you have Confidentiality in your SOC 2 Trust Services Criteria scope, confidentiality commitments from vendors, and two more only apply if you have Privacy in scope, privacy commitments from vendors. If you are running a Security-only report, as most companies starting out do, you do not need those four at all.
That leaves 9 Points of Focus relevant to most companies, and realistically, a genuinely minimum viable process covers the core of all 9 without needing 9 separate documented procedures.
Vendor Register Template
Start with a single register. A spreadsheet is genuinely fine at small scale, with these columns.
| Column | What goes here |
|---|---|
| Vendor name | The company providing the service |
| Service provided | Plain description, for example cloud hosting, or payroll processing |
| Data/access level | What data they can see, and what systems they can access |
| Risk tier | High, Medium or Low, based on data sensitivity and access level |
| Contract/SLA reference | Where the agreement lives, and any service-level commitments |
| Confidentiality/Privacy agreement in place? | Yes/No, only relevant if those criteria are in your SOC 2 scope |
| Last review date | When you last checked their SOC report or security posture |
| Next review due | Based on their risk tier |
| Termination/offboarding notes | What happens to data and access if the relationship ends |
Fill this out for every vendor with access to your systems or data, even ones that feel obviously low-risk. The exercise of listing them is often what reveals gaps.
Review Cadence by Vendor Risk Tier
Not every vendor needs the same level of scrutiny. Tier vendors by risk and set review frequency accordingly.
High Risk
Vendors with access to sensitive data or core infrastructure, such as your cloud host or payment processor. Review annually at minimum, request their current SOC report every cycle, and reassess immediately if anything material changes on their end, a breach, an ownership change, a service disruption.
Medium Risk
Vendors with limited data access or non-critical service dependency. Review annually, lighter-touch than high-risk, confirming their SOC report exists and skimming for major issues is often sufficient.
Low Risk
Vendors with no meaningful data access, such as an office supplies vendor. A lighter check at onboarding is usually enough, ongoing formal review is not necessary unless something changes.
This tiering is also what makes the minimum viable framing honest rather than just less-effort. You are not skipping oversight, you are applying it proportionate to actual risk, which is exactly what CC9.2’s Points of Focus describe when they reference risk-based, as-frequently-as-warranted review.
The Minimum Viable Process, Step by Step
List every vendor with system or data access using the register template above. Do not skip ones that feel obviously fine.
Tier each vendor by risk and set a review date accordingly, using the tiers above.
For high and medium risk vendors, request their most recent SOC 1 or SOC 2 report, or equivalent security documentation if they do not have one, and do a basic check: is the opinion clean, is the report current, are there any exceptions relevant to what you use them for. SANS Institute’s guide to reviewing SOC 2 reports is a solid reference if this is your first time reading one.
Document who is responsible for each vendor relationship, ideally someone who actually understands what that vendor does technically, not just a name on a spreadsheet for compliance’s sake.
Set a communication and exception process, what happens if a vendor has an incident, a missed SLA, or a report comes back with exceptions relevant to you.
Document an offboarding procedure for when a vendor relationship ends, covering data return or deletion and access revocation.
That is the genuinely minimum version. It will not cover every one of the 13 Points of Focus in full enterprise depth, but it satisfies the actual intent of CC9.2 for a smaller organisation, and it is a real, defensible process an auditor can review rather than an aspirational one that exists only on paper.
FAQs
Do I need a formal vendor management tool, or is a spreadsheet enough?
A spreadsheet is genuinely fine at small scale. What matters to an auditor is that the process exists, is followed consistently, and is documented, not which tool you use.
How many vendors is too many to track manually?
There is no fixed number, but once tracking and review start slipping because there are too many vendors to manage manually, that is the signal to consider a dedicated GRC tool rather than a specific vendor count.
Do I need to review every single vendor annually?
No, review frequency should match risk tier. Low-risk vendors with minimal data access do not need the same annual formal review as a vendor holding your core infrastructure or sensitive customer data.
What happens if a vendor won’t share their SOC report with us?
Document the request and their response. If a high-risk vendor consistently will not share security documentation, that is worth factoring into whether the relationship continues, and worth noting in your own risk assessment regardless.
Content Reviewed By
Ketki Tidke
Cyber Security and GRC Lead Auditor
ISO 27001 Lead Auditor
Ketki is a certified ISO 27001 Lead Auditor specialised in Governance, Risk and Compliance, with experience consulting public, private, and government clients. She evaluates threats, risk impacts, and regulatory requirements across multiple industry frameworks.
Let a vCISO help with your vendor management
If keeping this register updated and vendors reviewed on schedule is not realistic for your team alone, talk to us about how our vCISO service could support this, alongside your broader SOC 2 programme.
Talk to a vCISOCall Us
1300 507 668Email Us
[email protected]Our Office
Lvl 1, 206 Lorimer St, Port Melbourne, Australia
