The SOC 2 Vendor Monitoring Guide

The Trust Services Criteria don't include the words "vendor monitoring tool." They include the word "monitoring" 31 times, and the SOC 2 audit will, sooner or later, ask how you do it. This guide is what we'd tell a colleague preparing for their first SOC 2 Type II.

What SOC 2 actually requires

SOC 2 is structured around the AICPA's Trust Services Criteria. The criteria most relevant to vendor monitoring sit in the Common Criteria (CC) and span several domains:

• CC9.2 — Vendor and business partner management. The clearest single home for vendor oversight: identification, due diligence, contracts, ongoing monitoring, and termination.
• CC3.4 — Risk identification and analysis. Includes risks introduced by vendors.
• CC7.1, CC7.2 — Detection of vulnerabilities and security events. Vendor-introduced events count.
• CC2.1 — Information needed to support the functioning of internal controls. Includes information from vendors.

The auditor isn't checking whether you have "a vendor management policy." They're checking whether the policy operates — whether the controls described actually run on a defined cadence and produce evidence.

What an auditor wants to see

In our experience, SOC 2 auditors looking at vendor monitoring ask for some combination of:

1. A vendor inventory. Every third party with access to systems or data, with their criticality classification.
2. Tiering criteria. How you distinguish a payroll vendor (high) from a Slack-channel-archiving plugin (low).
3. Onboarding evidence. Security questionnaire, SOC 2 report review, contract with required terms.
4. Ongoing monitoring evidence. Annual review at minimum. Most mature programs run more frequent automated checks plus an annual deep review.
5. Change tracking. Did the vendor's posture change between reviews? If yes, what did you do about it?
6. Termination evidence. What happens when you stop using a vendor — data deletion confirmation, access revocation.

Items 4 and 5 are where most companies lose points the first time around. The annual review is easy to demonstrate; the ongoing part is harder, because nothing was actually being done between reviews.

A defensible operating cadence

A workable cadence for a mid-sized company:

| Frequency | Activity | | --- | --- | | Daily (automated) | Crawl tracked privacy policies, DPAs, subprocessor lists, ToS, and trust pages for changes | | Weekly (semi-automated) | Triage detected changes; flag those needing human review | | Monthly | Review and document material changes; update vendor records | | Quarterly | Review tier 1 (critical) vendors' SOC 2 reports for any new bridge letters or scope changes | | Annually | Full vendor review: refreshed questionnaires, contract review, attestation review, business-need confirmation |

The daily/weekly tier is the part that benefits most from tooling. The quarterly/annual tier is human work and probably stays that way.

What "material change" means in practice

Auditors don't expect you to investigate every typo. They do expect you to have a working definition of what constitutes a material change. Examples that we'd treat as material:

• A new subprocessor in a non-adequate jurisdiction.
• A change in retention period for any data category.
• A new use of customer data (AI training, shared insights, advertising).
• A change in breach notification commitments.
• A change in the data centres or regions where data is stored.
• A change to security commitments (encryption, access controls, audit cadence).

Non-material:

• A reformatted privacy policy with no semantic change.
• A new "we may use cookies for analytics" disclosure that's already covered by your existing TIA.
• A grammar fix in the DPA.

Documenting the review

The SOC 2 audit standard isn't "did you read it." It's "can you produce evidence that you reviewed it, when, by whom, and with what outcome." Every review has to leave a trace:

• Who reviewed it.
• When.
• What changed.
• What action was taken (no action, escalate, contractual amendment, vendor replacement).

This is also where audit-evidence exports earn their keep — pulling a line for every reviewed change with a timestamp and a reviewer name is much easier than reconstructing a history of inbox conversations.

Common failure modes

Things that cause SOC 2 findings around vendor monitoring:

• No working subprocessor list URL. You have a list of vendors but not their subprocessor URLs, so changes in the chain are invisible.
• No defined materiality threshold. Every change goes into the same bucket; auditor can't tell which were reviewed vs. acknowledged.
• No evidence trail between annual reviews. All evidence is dated within two weeks of the audit prep.
• Vendor inventory drift. New vendors added by procurement without privacy review; vendors offboarded without data deletion confirmation.
• Tier 1 vendor SOC 2 expired. The vendor's last SOC 2 ended in March; it's now October; no bridge letter has been collected.

The first two are the most common. The third is the hardest to explain when found.

What we'd actually do

For a mid-sized company starting from scratch:

1. Build the inventory. Every vendor with access to systems or production data. Procurement's vendor list is a starting point, not an answer.
2. Tier them. Three tiers is enough — critical, important, low. Criticality is "if this vendor breached or vanished tomorrow, what would break."
3. Capture document URLs. Privacy policy, DPA, subprocessor list, ToS, trust page. Whatever you can find.
4. Set up monitoring. Tooling like Thorgate handles the daily crawl. Free alternatives (manual page-watching) work but won't scale beyond ~10 vendors.
5. Define the materiality rules. Write them down. They will get tested.
6. Establish the cadence. Calendar invites for quarterly and annual reviews.
7. Practice the audit story. Walk through six months of detected changes and reviewer actions. If the story has gaps, fix them now.

The investment is largely upfront. After three months of running the cadence, the audit narrative writes itself.