SOC 2 vendor monitoring, actually performed

What the frameworks actually require.

SOC 2's CC9.2 expects you to assess and manage risks associated with vendors and business partners, on an ongoing basis, and ISO 27001's supplier controls (the A.15 family) expect you to monitor and review supplier service delivery and changes. In practice, for a B2B SaaS company, the concrete obligations reduce to a short list: know which vendors touch your data, know their subprocessors, notice when those subprocessors change, notice when the DPA or security terms change, and be able to show an auditor that this noticing actually happened on a cadence you can name.

The last clause is the trap. The control is not "care about vendors". It is "produce evidence of ongoing monitoring". A policy document that says you monitor is not monitoring.

Why the spreadsheet version quietly fails.

The common implementation is a vendor register in a spreadsheet and a calendar reminder to open every vendor's subprocessor page once a quarter. It fails three ways. It rarely happens: forty tabs a quarter loses to any deadline, and a skipped quarter looks identical to a performed one. It proves nothing: a spreadsheet edited today can claim any history, so the "evidence" is an assertion. And it misses everything between looks: a subprocessor added in April and removed in August never existed as far as a September review can tell.

Auditors know all three. The follow-up question that collapses the spreadsheet is simply "show me the review from March, and how do I know it happened in March?"

What acceptable evidence looks like.

Whatever tooling you use, evidence that survives scrutiny has five properties. A stated cadence. "We check every vendor's subprocessor and DPA pages every N hours" is a testable claim. A record of every check, including the failures. Gaps that are visible are a finding you managed. Gaps that are invisible are a control that did not operate. Change capture. What changed, when it was detected, and what the page said before and after. Tamper evidence. Some mechanism that makes the record hard to backfill, because evidence you could have written yesterday proves nothing about last quarter. Exportability. The record has to outlive the tool and the vendor relationship.

The honest manual version, if you want one.

You can perform this control without buying anything: keep the vendor register, save dated captures of each page on a fixed schedule, diff each capture against the last, and log every review in a system with real timestamps (a ticket system beats a spreadsheet, because tickets carry creation dates you cannot quietly edit). web.archive.org helps reconstruct history when you start late. Budget roughly a focused half day per month for fifteen vendors, forever, and accept that changes between captures are invisible. That is a real, defensible implementation. Its cost is that it depends entirely on the discipline of a busy human.

What Dormouse does instead.

Dormouse watches each vendor page every 12 hours, records every check, including failures and its own gaps, in a keyed hash-chained audit trail, alerts you when a subprocessor or DPA change is detected, and produces a monthly coverage report an auditor can verify independently. The record is tamper-evident by construction and exports with you. The sample report shows exactly what you would hand over, and how the proof works shows why backfilling it is not possible.

The fastest way to evaluate it: send a vendor list and get a free baseline report on your real vendors. No card, no call.