The vendor review that SOC 2 auditors actually ask for (checklist inside)

If you're heading into a SOC 2 audit, here's what the vendor-management part really comes down to: can you show that you know which third parties handle your data, that you reviewed them, and that you'd notice if something important changed? Auditors aren't looking for a hundred-column spreadsheet. They're looking for a repeatable process with evidence. This post breaks that down and gives you a checklist to copy.

As always, this is practical guidance, not legal or audit advice — your auditor's expectations and your own controls are what govern.

What the criteria actually expect

SOC 2's Common Criteria include vendor and business-partner risk management (the CC9 area). In plain terms, an auditor wants to see that you: identify the vendors who touch in-scope data, assess their risk, set expectations in contracts (your DPA and security terms), and monitor them over time. The word that trips teams up is "monitor" — a one-time review at onboarding isn't monitoring. Something has to happen on an ongoing basis, and you have to be able to prove it did.

The vendor review checklist

Here's a lean version that holds up. For each vendor that processes customer or employee data:

• Identify: name the vendor, what data it processes, and why. Note whether it's a processor and who its subprocessors are.
• Contract: confirm you have a current DPA and, where relevant, security terms. Save links to the executed versions.
• Assess: capture a risk level and the basis for it — certifications (their own SOC 2 / ISO 27001), data location, and sensitivity.
• Document the source: save the URLs for the vendor's subprocessor list, DPA, and security page. These are your evidence trail.
• Monitor: decide how you'll notice changes to those documents, and on what cadence. Write down the mechanism.
• Review on a schedule: set a recurring review (annually is common) and log the date each time you do it.
• Keep the evidence: store the dates, the decision, and any change you actioned. That log is what the auditor samples.

What "evidence" actually looks like

Auditors sample. They'll pick a few vendors and ask you to walk through them: show me the DPA, show me when you last reviewed it, show me that you'd know if the subprocessor list changed. Strong evidence is boring and specific — a dated log entry that says "reviewed Zoom's subprocessor list on this date; one change noted; no action needed." Weak evidence is a vague "we check periodically" with nothing to point at.

The subprocessor angle auditors increasingly probe

Because subprocessor lists change quietly and often — especially now that vendors are adding AI providers — auditors have started asking specifically how you keep up. "We re-check the pages" is a good answer only if you can show it happens without depending on one person remembering. This is also where SOC 2 and GDPR overlap: the same monitoring that gives you audit evidence is what protects your Article 28 objection window.

The lazy way to pass this part

The monitoring row of the checklist is the one that quietly rots. You can do it by hand — a spreadsheet of URLs and a calendar reminder — or you can let something watch the pages for you and hand you a dated record when anything changes. That record is exactly the evidence an auditor wants.

That's what DPA Monitor produces as a side effect of doing its job: pick your vendors, and we watch their DPAs and subprocessor lists, email you when they change, and keep a timeline you can point an auditor to. We report changes; we don't interpret their legal or audit meaning.