Continuous Vendor Monitoring: How to See Risk Between Assessments

Your vendor passed its annual assessment in March. In August, its certificate management fell apart, an exposed admin panel appeared on a subdomain, and a breach notification service flagged credentials from its employee domain. Your risk register still says "Low. Reviewed Mar 12, 2026."

That gap is the core failure of point-in-time vendor assessment. A questionnaire captures what a vendor reported on one day. Everything after that day is faith. Continuous vendor monitoring exists to replace that faith with observable signal, so that a vendor's risk record reflects what is true now, not what was attested last cycle.

This guide covers what continuous monitoring actually watches, how to set thresholds that do not bury your team in noise, how to keep a defensible baseline, and how to evaluate tooling.

Why point-in-time assessment fails

An annual questionnaire has three structural weaknesses.

1. It measures claims, not conditions. A vendor answers "Do you enforce TLS 1.2 or higher?" with yes. That answer is a statement about policy, not a scan of their endpoints today.
2. It decays immediately. Vendor environments change weekly. Infrastructure migrations, staff turnover, acquisitions, and new sub-processors all land between assessment cycles. Industry incident timelines regularly show compromise windows measured in weeks, well inside a 12-month reassessment cadence.
3. It scales linearly with headcount. If a full reassessment takes 8 to 12 analyst hours, a program past 50 vendors cannot shorten the cycle by simply assessing more often. The math does not close.

Continuous monitoring does not replace assessment. It answers a different question: has anything observable changed since the vendor last told us about itself?

What signals continuous monitoring actually watches

Useful external monitoring draws from a handful of signal families. When evaluating any monitoring feed, ask which of these it covers and how it collects them.

Two cautions. First, all of these observe the vendor's external surface. None of them can see internal controls like access reviews or backup testing, which is exactly what assessments cover. The two are complements, not substitutes. Second, a raw score aggregated from these feeds is only as good as its asset attribution. Confirm that the monitored domains and IP ranges actually belong to your vendor before acting on any alert.

Setting alert thresholds without alert fatigue

The failure mode of most monitoring rollouts is not missed signal. It is a queue of 400 unread alerts by week six, at which point the team stops reading any of them. Threshold design is the whole game.

1. Alert on change, not state. A vendor with a mediocre but stable external posture does not need a weekly alert repeating that fact. Alert when the posture moves.
2. Scale sensitivity by vendor tier. A critical vendor with production data access warrants alerts on moderate drift. A tier-3 marketing tool should only surface severe events. A workable starting point: critical vendors alert on any tiered drift, important vendors on moderate and above, low tiers on severe only.
3. Require persistence for low-grade findings. A single failed check on one scan is often scanner noise. Require the finding to persist across two consecutive scans before it opens an alert.
4. Route by severity, not volume. Severe drift creates a task with an owner and a due date. Moderate drift appears in a weekly digest. Minor drift accumulates silently on the vendor record for the next reassessment to consume.

Tier drift severity before anyone gets paged

Drift needs a severity model agreed in advance, or every alert becomes a judgment call at 4pm on a Friday. A three-tier model is enough:

• Minor. Small score movement or a single low-impact finding. Log it against the vendor record. No human action required.
• Moderate. Sustained decline, or a finding on a meaningful service. Reviewed in the weekly vendor risk triage. May trigger a targeted question to the vendor.
• Severe. Sharp decline, confirmed exposure, credential dump, or public incident. Opens a response task immediately and can trigger an off-cycle reassessment.

Write the numeric boundaries down (for example, a score drop of more than 15 points inside 30 days is Severe) and apply them mechanically. Consistency is what makes the program defensible when an auditor or examiner asks why one event escalated and another did not.

Baseline discipline: the rule most programs get wrong

Every drift calculation compares current signal against a baseline. The discipline that keeps the comparison honest: reset the baseline only when a completed reassessment establishes a new verified posture. Never reset it because a score drifted back up.

Here is why. Suppose a vendor's exposure score falls sharply in June, then partially recovers in July. If your tooling quietly adopts the July level as the new normal, the June deterioration disappears from history and the recovery masks an unresolved question: did the vendor fix the issue, or did the scanner lose sight of it? Score recovery is not evidence. A completed reassessment is. Until one lands, drift keeps being measured against the last verified baseline, and the June event stays visible.

When evaluating tools, ask the vendor directly how baselines reset. Automatic recalibration on recovery is a disqualifying answer for critical-tier monitoring.

The incident-to-reassessment workflow

A severe event should trigger a defined sequence, not an ad hoc scramble. A workable five-step flow:

1. Validate attribution and impact within one business day. Is the asset really theirs? Does the finding touch a service you depend on?
2. Notify the vendor with a specific question. Not "we saw your score drop." Instead: "Our monitoring shows service X exposing version Y as of Aug 14, 2026. Confirm and share your remediation timeline."
3. Decide the assessment scope. A single exposed service may need a 10-question targeted questionnaire. A confirmed breach of a critical vendor needs a full off-cycle reassessment plus contract and data-flow review.
4. Track remediation as tasks with dates, not email threads. Every commitment the vendor makes gets an owner and a due date.
5. Close by resetting the baseline once the reassessment completes, and record the whole sequence on the vendor's risk record.

Monitoring output must land on the vendor risk record

Monitoring that lives in a separate portal, disconnected from assessments and remediation, produces two versions of the truth. The vendor risk record should hold three layers side by side: how much the vendor matters to you (business criticality), what they attested under assessment (assessed posture), and what external signal shows now (live exposure). The most valuable read is not any single layer. It is the disagreement between them: a vendor whose assessed posture says mature while live exposure says deteriorating deserves attention before either number alone would trigger it. If your current stack cannot put those layers on one vendor risk record, that reconciliation becomes a manual quarterly exercise, which means it mostly does not happen.

Evaluation checklist: choosing continuous monitoring tooling

Use this list in demos. Every "no" is a finding.

• Does it alert on change rather than restating static scores?
• Can alert sensitivity vary by vendor tier?
• Is drift severity tiered with configurable numeric boundaries?
• Do baselines reset only on completed reassessment, never on score recovery?
• Can you verify and correct asset attribution per vendor?
• Does a severe event create an assignable task with a due date?
• Does monitoring output write to the same record as assessment results?
• Can an auditor trace an alert from detection through reassessment to closure?
• Is history immutable, so past drift events cannot be silently overwritten?
• Does pricing survive your vendor count doubling?

FAQ

How often should continuous monitoring scan each vendor? Weekly scanning is a reasonable default for external attack surface, with event-driven feeds (breach disclosures, credential dumps) arriving as they occur. Daily scanning of low-tier vendors mostly buys noise. Match frequency to tier and to how fast each signal family actually changes.

Does continuous monitoring replace annual assessments? No. Monitoring observes the external surface; assessments cover internal controls that no scan can see, such as access management and incident response process. The strongest programs use monitoring to decide when an off-cycle assessment is warranted and to test whether attested answers still look true.

What is a reasonable alert volume for a 100-vendor program? As an illustrative planning target, a well-thresholded program might see a handful of severe events per quarter and a weekly moderate digest of 5 to 15 items. If you are seeing dozens of actionable-severity alerts weekly, your thresholds are wrong, your attribution is wrong, or both.

How do we justify the spend to leadership? Frame it as compression of the detection window. Point-in-time assessment leaves up to 12 months of blindness per vendor. Monitoring is built to shrink the time between a vendor's posture change and your awareness of it from months to days, an illustrative target that directly reduces the window in which you are unknowingly exposed.

Where ThirdSentry fits

ThirdSentry was built around the model this guide describes. Vendor Dual-Signal Risk Intelligence keeps business criticality, assessed posture, and live external exposure on one vendor record, tiers drift as Minor, Moderate, or Severe before anyone is alerted, and resets baselines only on completed reassessments. When reported posture and live signal disagree, the platform flags it, so you know the moment a vendor's claims stop matching reality. If your monitoring and assessment workflows live in different tools today, book a demo and see both signals reconciled on one record.