Vendor Reassessment Cadence: Setting Frequency by Tier

"We reassess every vendor annually" sounds rigorous and is usually neither achievable nor sensible. Past a hundred vendors, uniform annual reassessment means your team runs two full assessments a week forever, most of them on vendors whose risk has not moved. Meanwhile the vendor that actually changed gets its questionnaire in eleven months. Cadence should be a function of risk, and risk lives in your tiers.

Baseline cadence by tier

Start from your vendor tiering framework. If tiering is sound, cadence follows almost mechanically. An illustrative baseline model:

Tier	Profile	Baseline cadence	Instrument depth
Tier 1	Critical operations dependency, sensitive data, or privileged access into your environment	Every 12 months, full scope	Full instrument plus evidence review; consider a light 6-month checkpoint on the highest-stakes handful
Tier 2	Meaningful data access or operational importance, no privileged access	Every 18 to 24 months	Condensed instrument focused on high-weight domains
Tier 3	No sensitive data, no system access, easily replaced	Every 36 months, or attestation-and-certificate refresh only	Short screener; verify certifications remain current

Three rules keep the model honest:

1. Cadence attaches to the tier, not the vendor. When a vendor's tier changes, its clock changes with it, effective immediately, not at the next renewal.
2. The clock starts at completion, not at send. A reassessment that took four months to close does not earn the vendor four bonus months of assurance.
3. Certification expiry is a hard date inside the cadence. If a Tier 2 vendor's independent audit report lapses at month 14 of a 24-month cycle, the artifact refresh happens at month 14. The cadence governs your questionnaire, not their auditor's calendar.

Event triggers that override the calendar

The calendar is the backstop, not the brain. A defined set of events should pull a reassessment forward regardless of where the clock stands. Write these into the program document so invoking one is procedure, not debate:

1. Security incident or breach disclosure at the vendor or a subprocessor in their chain. Targeted reassessment, scoped to the failed and adjacent domains, within days not weeks.
2. Severe monitoring signal: credible leak intelligence, sustained score collapse against the assessed baseline, or external observation contradicting an attested control.
3. Material scope change in the relationship: the vendor starts receiving a new data class, gains an integration or privileged access, or becomes load-bearing for a new business process. This is really a tier change wearing a trigger costume; retier first, then reassess at the new tier's depth.
4. Corporate events at the vendor: acquisition, divestiture, major leadership turnover in security, or signs of financial distress. Ownership changes routinely change security posture within two or three quarters.
5. Loss or lapse of a relied-upon certification, or a qualified audit opinion where prior reports were clean.
6. Regulatory change that alters your obligations for the services this vendor performs.
7. Missed remediation deadlines from a prior conditional approval. Failing the conditions of an approval is itself a reassessment event, not a nagging opportunity.

Every triggered reassessment should record which trigger fired and when. Over a year, that log tells you something the calendar never will: how much of your assurance work is actually driven by events, which is the honest measure of whether your cadence is set correctly.

How monitoring legitimately extends cadence

Here is the question program owners actually want answered: can continuous monitoring let us reassess less often? Yes, under specific conditions, and pretending otherwise wastes the main economic benefit of monitoring. But the extension has to be earned, not assumed. Monitoring justifies a longer interval for a given vendor only when all four conditions hold:

1. The vendor's key risks are externally observable. Monitoring extends cadence for vendors whose risk profile is dominated by internet-facing posture. It extends nothing for a vendor whose risk is dominated by internal data handling that no scanner can see.
2. A completed assessment set the baseline. Monitoring measures drift from a known state. If the last real assessment is years old, monitoring is measuring drift from a fiction. Baselines should reset only when a reassessment completes, never because a score drifted back up on its own.
3. Severe and Moderate signals are actually worked. An alert queue nobody clears provides negative assurance: you had the signal and ignored it. Extension is conditional on demonstrated response discipline, which is a staffing commitment, not a tooling purchase.
4. The trigger list above is live. Extended cadence plus dead triggers equals a longer blind spot. The two mechanisms are a package.

When those conditions hold, a defensible extension policy looks like this, with the numbers as illustrative targets to calibrate against your own portfolio:

• Tier 1: no extension. Monitoring adds early warning between annual cycles; it does not buy criticality out of an annual full-scope reassessment, because Tier 1 risk is never fully externally observable.
• Tier 2: 18 months extends toward 24 for vendors with clean monitoring history, meaning no unresolved Moderate-or-above findings across the current cycle. One sustained Severe event revokes the extension for that vendor until the next completed reassessment.
• Tier 3: calendar reassessment largely replaced by monitoring plus annual attestation and certificate verification, with the trigger list as the only path to a full questionnaire.

Document the extension policy explicitly, including the revocation rule. An examiner who finds a 24-month cycle backed by a written, conditioned, monitored policy sees risk-based design. The same cycle with no written policy reads as under-resourcing, and the difference between those two findings is the paragraph you did or did not write. For the tooling side of this equation, see our guides to continuous vendor monitoring and continuous supply chain risk.

Running the model at portfolio scale

Cadence policy fails in execution more often than design, usually because due dates live in a spreadsheet nobody owns. Three operational requirements: every vendor carries a next-reassessment date computed from tier and last completion; triggers create reassessment tasks automatically rather than relying on someone remembering the policy; and a monthly cadence report shows overdue reassessments by tier, because an overdue Tier 1 is a different problem from an overdue Tier 3 and should be visible as such. This is a place where platform support earns its keep; ThirdSentry, as one example, ties each vendor's criticality tier, assessed posture, and live external signal together on one record, so cadence, triggers, and baseline resets run as workflow instead of tribal memory.

The bottom line

Set baseline cadence by tier, let a written trigger list override the calendar, and let monitoring extend intervals only where its four conditions genuinely hold. The result is a program that concentrates assessment effort where risk actually lives and can show an examiner exactly why every interval is the length it is. ThirdSentry was built to run that model end to end: tiered cadence, event-driven reassessment, drift graded Minor, Moderate, and Severe against baselines that reset only on completed reassessments.