An annual vendor review tells you what was true on the day you did it. The rest of the year is a gap. In that time the vendor's SOC 2 report expires, it adds a sub-processor, it discloses an incident on its status page, and your own team connects it to a production database it was never reviewed for.
Continuous vendor monitoring is the practice of noticing those changes between reviews and responding to the ones that matter. "Continuous" overstates it. You are not watching every vendor every day. You are deciding which signals to collect for which vendors, and what each signal should trigger.
This article covers what the frameworks ask for, the signals worth watching, the response each should prompt, and how much monitoring each tier deserves.
What the frameworks ask for
The requirements are about ongoing oversight, not a specific technique.
ISO/IEC 27001:2022 Annex A control 5.22 covers monitoring, review and change management of supplier services. It expects you to monitor, review, evaluate and manage change in suppliers' information security practices and service delivery on a regular basis.
SOC 2. CC9.2 expects vendor risk to be assessed and managed. Auditors testing it usually look for periodic review of vendors and for evidence that issues found were followed up.
PCI DSS v4.0. Requirement 12.8.4 asks you to monitor the PCI DSS compliance status of third-party service providers at least once every 12 months. The PCI DSS framework page covers the wider third-party requirements.
None of these demands real-time feeds. All of them expect that a material change at a vendor would reach someone who can act on it before the next annual review.
The signals worth watching
Most useful signals come from sources you already have access to. The table lists the ones that most often change a vendor's risk, where to find them, and the response each should prompt.
| Signal | Where it comes from | What it should trigger |
|---|---|---|
| Assurance report or certificate expiring | The report period end date or the certificate validity date in your vendor record | Request the new report before the date; ask for a bridge letter if there is a gap |
| New report with exceptions or a modified opinion | The report itself | Read the exceptions against your use; decide whether to accept, follow up or reassess |
| Security incident disclosed | Vendor notice, status page, public disclosure | Establish whether your data was affected; follow your incident process if so |
| Sub-processor added or changed | The vendor's change notifications | Check whether the new party handles your data; object or reassess if needed |
| Change in your use | New integration, new data category, broader OAuth scope | Re-run the tiering questions; reassess if the tier rises |
| Ownership or terms change | Acquisition announcements, updated terms or privacy policy | Review data use and contract terms against what you approved |
| Repeated availability problems | Status page history, your own incident records | Review against the service commitment for critical-path vendors |
Two of these are internal. Changes in your own use are the signal most often missed, because nobody on the vendor's side will tell you about them. The vendor's risk did not change. Your exposure to it did.
Changes in your own use
Catching your own changes means attaching vendor checks to processes you already run. Three hooks cover most of it. Add a question about third-party services to your change management or architecture review, so a new integration with production data is flagged when it is designed. Route OAuth consent requests for sensitive scopes to an administrator, so a broader grant cannot happen silently. Ask the vendor's internal owner, at each reassessment, whether the data or the integration has changed since the last one. None of these needs new tooling.
Assurance report dates
Track the end date of each vendor's SOC 2 period and the expiry date of each certificate. Ask for the new report shortly after the next period should have ended. If the vendor's next report is not yet issued, a bridge letter is the usual way to cover the gap, and it should be read with the same care as the report. Our guide to reading a SOC 2 report as a buyer covers what to check in the new one.
Outside-in ratings
Rating services scan a vendor's internet-facing assets and score what they observe. They can flag changes worth a question, such as an expired certificate or an exposed service. They see only the outside, they can attribute assets to the wrong company, and they are not an assessment of the controls protecting your data. Treat a drop in a rating as a prompt to ask, not as a finding.
Cadence by tier
Monitoring effort should follow the tier, as review depth does. Using the four-tier model from vendor tiering by data access:
Tier one. Track assurance dates, subscribe to sub-processor and incident notices, review status history for critical-path vendors, and reassess at least annually. Re-run tiering whenever your use changes.
Tier two. Track assurance dates and subscribe to sub-processor notices. Reassess annually.
Tier three. Re-run tiering on change of use. Reassess every two years, or when a signal suggests it.
Tier four. Confirm the vendor is still used and still has an owner, typically during an annual inventory check.
Write the cadence into your vendor management procedure, so an auditor can compare what you said you would do with what happened.
Separating signal from noise
A monitoring program that raises an alert for every vendor change will be ignored within a quarter. Decide in advance which signals require action.
A workable rule: a signal requires a recorded response if it could change the vendor's tier, invalidate the basis on which the vendor was approved, or indicate your data may have been affected. Everything else is logged and looked at during the next scheduled review.
Under that rule, a new sub-processor that will host your data needs a response. A new sub-processor for the vendor's internal payroll does not. An exception in a SOC 2 report on change management in a system you do not use can usually wait. An exception on access controls to customer data cannot.
What monitoring should leave behind
Monitoring is evidence only if the responses are recorded. For each signal that needed a response, keep:
The signal, its source and the date it was received
Who looked at it, and what they concluded
Any follow-up: questions to the vendor, a reassessment, a contract change, a change to your own configuration
The closure, with a date
An auditor testing vendor management will often ask how you would know if a critical vendor's assurance lapsed. A record of the last time it happened, and what you did, is the strongest answer you can give.
When monitoring should end the relationship
Some signals point toward exit rather than remediation: repeated incidents affecting your data, a refusal to provide current assurance, a change of ownership that moves data somewhere you cannot accept, or terms that now allow uses you never agreed to. When that happens, the decision feeds directly into offboarding the vendor, and the monitoring record becomes the justification for it.
How TrustLynce helps
TrustLynce's third-party risk module records each vendor's tier, review dates and assurance documents, and schedules reassessments by tier, so expiring reports and due reviews surface before they lapse. Responses to monitoring signals are recorded against the vendor, with the history kept for audit.