What SOC 2 expects from vendor risk management
Almost every software company relies on vendors to deliver its service: hosting, email delivery, payments, support tools. Each one can see some of your data or affect whether your service works. Vendor risk management for SOC 2 means knowing who those vendors are, judging how much risk each brings, and checking on them regularly.
The Trust Services Criteria cover this mainly in CC9.2, which asks the organization to assess and manage the risks that come from vendors and business partners. Read in general terms, the points of focus behind it describe a familiar lifecycle:
- set requirements before you engage a vendor, including the security and confidentiality commitments you need from them;
- assess each vendor's risk, and decide who in your company is responsible for each relationship;
- monitor vendors over time, and deal with issues when they come up;
- end relationships in an orderly way, including what happens to your data.
SOC 2 doesn't prescribe a tool, a questionnaire or a frequency. Your vendor management policy says how you do it, and the auditor tests whether you followed it.
Step 1: Build a vendor inventory
You can't assess vendors you don't know about, so the inventory comes first. To find the vendors you actually use, look in a few places:
- Company card and accounts payable records. Anything you pay for regularly is a vendor.
- Your single sign-on directory. Its connected applications show the tools your staff use.
- Your infrastructure and code. Third-party APIs, monitoring and logging services.
- Team leads. Ask which free or self-service tools their teams signed up for.
Here is an inventory template you can copy. The rows are examples only.
| Vendor | Service | Data it holds or touches | Criticality | Tier | Internal owner | Assurance on file | Contract and DPA | Last review | Risk rating |
|---|---|---|---|---|---|---|---|---|---|
| Example: cloud hosting provider | Production infrastructure | All customer data | Service stops without it | 1 | Head of engineering | SOC 2 Type 2, period ending March | Signed, DPA in place | Date of last review | Low |
| Example: support ticketing tool | Customer support | Customer names, emails, ticket contents | Degraded support if down | 2 | Support lead | Security questionnaire | Standard terms, DPA signed | Date of last review | Medium |
| Example: diagram drawing tool | Internal diagrams | No customer data | Low | 3 | Engineering manager | None needed | Online terms accepted | Date of last review | Low |
Give every vendor a named internal owner, or reviews stall.
Step 2: Tier vendors by data access and criticality
Not every vendor deserves the same scrutiny. Two questions sort most vendors quickly:
- Data access: does the vendor store, process or have access to customer data, personal data or production systems?
- Criticality: if the vendor disappeared tomorrow, could you still deliver your service and meet your commitments to customers?
Three tiers are enough for most small companies:
| Tier | Typical vendors | What to collect |
|---|---|---|
| 1: High | Hosting, databases, identity provider, anything with broad access to customer data or production | The vendor's SOC 2 Type 2 report or an equivalent, reviewed in writing; contract with security and breach notification terms; DPA where personal data is involved |
| 2: Medium | Tools that hold limited customer or employee data, or that your service depends on less directly | A SOC 2 report if available, otherwise a short security questionnaire; contract or terms and a DPA where needed |
| 3: Low | Tools with no sensitive data and no production access | An inventory entry, the terms you accepted and a note confirming the data assumption |
Write the tiering rules into your vendor policy so anyone can repeat the decision.
Step 3: Read a vendor's SOC 2 report quickly
Collecting a vendor's report is not the same as reviewing it, so record a short review for each one. Section order varies between audit firms, but most reports contain the auditor's opinion, management's assertion, a description of the system and, in a Type 2 report, the tests of controls and their results. Check these in order:
- Type and period. Is it a Type 1 (design at a point in time) or a Type 2 (operating over a period)? Type 2 tells you more (see SOC 2 Type 1 vs Type 2). Note when the period ended. If it ended well before your own period, ask for a bridge letter: a statement from the vendor's management that nothing significant has changed since.
- Scope. Read the system description and confirm the product or service you actually use is covered, along with the Trust Services categories you care about.
- Opinion. An unmodified opinion is what you hope for. A qualified, adverse or disclaimed opinion needs a conversation with the vendor and probably a higher risk rating.
- Exceptions. In the test results, look for deviations the auditor found, and read management's response where one is included. Ask whether each exception affects the service you use.
- Subservice organizations. The description lists other companies the vendor relies on and whether their controls were carved out.
- Complementary user entity controls. These are controls the vendor assumes you, the customer, operate: for example, managing your own user accounts in their product or enforcing multi-factor authentication. Map each relevant one to a control you already have, or note the gap.
Write the result down in a few lines per vendor: report type and period, scope confirmed, opinion, exceptions and whether they matter, user entity controls mapped, and the resulting risk rating.
Important: vendors often share their SOC 2 reports under a confidentiality agreement that limits who may see them. Store the reports where only the people who need them have access, and keep your written review summary with your evidence.
When a vendor has no SOC 2 report
Many smaller vendors don't have one. That needn't rule them out, but you need another basis for trust and a record of the decision:
- ask for an equivalent, such as an ISO/IEC 27001 certificate with its statement of applicability, or a recent penetration test summary;
- send a security questionnaire sized to the vendor's tier, and follow up on weak answers;
- reduce your exposure on your side: share less data, connect the tool through single sign-on, restrict who can use it;
- record a risk acceptance signed off by management, with a date to revisit it;
- if the risk is still too high, plan a replacement.
Onboarding and offboarding vendors
The cheapest moment to manage a vendor is before you sign. A lightweight intake works for most teams:
- The person who wants the tool describes what it does and what data it will touch.
- Security or the compliance owner assigns a tier.
- Collect what the tier requires: report and review, questionnaire, contract terms, DPA.
- Approve or reject in writing, with the date.
- Add the vendor to the inventory with an internal owner.
When you stop using a vendor, remove your users and integrations, ask for confirmation that your data was returned or deleted where the contract allows, and mark the vendor as inactive in the inventory instead of deleting the row.
Subservice organizations in your own SOC 2 report
Some of your vendors will appear in your own SOC 2 report as subservice organizations: vendors whose controls are needed, together with yours, to meet your service commitments, such as a hosting provider. Your report can treat them in one of two ways:
- Carve-out method. Your system description explains what the subservice organization does for you, but its controls are left out of the scope of your examination. The description lists the controls you expect the subservice organization to operate (complementary subservice organization controls), and your auditor will typically look at how you monitor that it does, for example by reviewing its own SOC 2 report each year.
- Inclusive method. The subservice organization's relevant controls are included in your description and tested by your auditor. This needs the subservice organization's cooperation, including its own written assertion, so it is much less common.
For most startups the carve-out method is the practical choice, which makes your yearly review of those vendors part of the evidence for your own report. Which vendors count as subservice organizations, and which method fits, is something to settle with your auditor during scoping: they decide what is acceptable.
The annual vendor risk review
Once a year, or at the cadence your policy sets, walk through the inventory:
- Reconcile the inventory against spending and single sign-on records.
- Confirm each vendor's tier still fits. A tool that started with no customer data may have become Tier 1.
- Collect and review fresh reports or questionnaires for Tier 1 and Tier 2 vendors.
- Check that contracts and DPAs are in place where the tier requires them.
- Update each risk rating, and record follow-up actions with an owner.
- Have someone other than the reviewer sign it off, if you can.
Start early: chasing vendor reports can take weeks. To see how this fits with your other yearly controls, see the SOC 2 compliance calendar.
Vendor risk management evidence to keep
- the approved vendor management policy, including your tiering rules;
- a dated snapshot of the vendor inventory for each review;
- for each Tier 1 and Tier 2 vendor: the report or questionnaire collected and your written review of it;
- contracts and DPAs, or a pointer to where they are kept;
- risk ratings, risk acceptances and follow-up actions;
- onboarding approvals for vendors added during the period;
- the sign-off on the annual review, with a date.
Exactly which items and formats your auditor accepts is up to them, so ask early. For organizing evidence like this across every control, see SOC 2 evidence collection.
Running vendor reviews in Confluence with Compliance in a Box
If your team works in Confluence, Compliance in a Box provides both halves of this control in its SOC 2 content, and its controls matrix maps both to CC9.2:
- The Vendor & Third-Party Management Policy. A policy page in your compliance space that you tailor to your tiers and process. Each new version is approved against the exact page version submitted, and the policy comes up for review every 12 months. If nothing changed, the owner can use Mark as reviewed.
- The Vendor Risk Review activity. An annual recurring activity with its own activity page holding the procedure. Before each year's review is due, the app creates an evidence page for that period under the activity page, with a checklist and headings for the vendor list, the SOC reports collected and the risk ratings. You attach your inventory export and review notes there.
- Notice that suits the work. The evidence page appears 14 days before the due date by default. Because collecting vendor reports takes time, a Compliance Admin can raise the days of notice (up to 90) with Edit schedule.
- An owner and approvers. Assign them under Settings, Owners & approvers. The owner submits the evidence page for approval, every approver must approve, and editing the page before approval cancels the submission. Approving your own evidence is flagged as a self-approval.
- Visible status. The review shows up in My Tasks, an unfinished period becomes overdue after its due date, and the generated Activity Completion Report links to the evidence page version that was approved.
The SOC 2 content reference lists the activity's cadence and evidence prompts alongside every other control.
FAQ
Do all vendors need a SOC 2 report?
No. Ask for one from vendors with significant access to customer data or production, and use lighter checks for the rest, as your policy defines per tier.
What is a subservice organization?
A vendor whose controls, together with yours, are needed to meet your service commitments, such as your hosting provider. Your report either carves its controls out or includes them, and your auditor confirms which is appropriate.
Is a vendor's SOC 3 report enough?
A SOC 3 report is a short general-use summary without the detailed tests and results, so it tells you much less. It can work for lower-tier vendors. For a critical vendor, ask for the SOC 2 report under a confidentiality agreement.