An annual vendor reassessment answers one question with precision: what did this vendor's security posture look like on the day they finished the questionnaire? It says very little about what that posture looks like today. The gap between those two things is the core weakness of point-in-time assurance, and it is measurable.
The staleness math of a point-in-time assessment
Assume a vendor completes a reassessment on day zero and the next one lands 365 days later. On any given day, the average age of the assurance you are relying on is about six months. Across a full portfolio on annual cycles, roughly half of your vendor evidence is more than six months old at any moment, and the vendors closest to their renewal date are running on assurance that is nearly a year stale.
Now layer in how fast the underlying facts change. As an illustrative model, consider what a typical SaaS vendor does in a year:
- Ships dozens to hundreds of production releases, any of which can introduce new services, ports, or data flows
- Onboards and offboards staff with privileged access
- Adds or replaces subprocessors, changing your fourth-party exposure
- Lets certificates, DNS records, and email authentication configurations drift
- Experiences security events it may or may not be contractually required to disclose
None of those changes wait for your questionnaire. A useful way to frame this internally is an assessment half-life: the point at which you would expect half of the operationally observable claims in a questionnaire to have changed in some way. For infrastructure-heavy answers (exposed services, TLS posture, patching evidence, subdomain inventory), a half-life of three to six months is a defensible planning assumption. For governance answers (policy existence, insurance coverage, certification status), twelve months usually holds. The problem with a purely annual model is that it prices both kinds of answers at the same twelve-month freshness, which is wrong for the first kind.
What actually changes between cycles
Not all vendor risk information decays at the same rate. Sorting it by decay speed is the first step toward a rational split between monitoring and reassessment.
| Information type | Typical decay speed | Observable externally? |
|---|---|---|
| Exposed services, open ports, new subdomains | Days to weeks | Yes |
| Certificate validity, TLS configuration, email authentication | Weeks | Yes |
| Breach disclosures, credential leaks, ransomware claims | Immediate when they occur | Yes, with intelligence sources |
| Patch and vulnerability posture on internet-facing assets | Weeks to months | Partially |
| Subprocessor list, hosting footprint | Months | Partially |
| Internal access controls, offboarding discipline, key management | Months | No |
| Security policies, training programs, incident runbooks | Annual or slower | No |
| Certifications, audit reports, insurance coverage | Annual, with hard expiry dates | Only the artifact, not the substance |
The pattern is clear. The fastest-decaying information is largely observable from the outside, and the slowest-decaying information is largely not. That is exactly the shape of a problem you solve with two instruments instead of one.
A decision framework: monitor, reassess, or both
Use these three questions to decide, per risk domain, which instrument owns it:
- Can the fact be observed externally without vendor cooperation? If yes, monitoring should own the freshness of that fact. Asking a vendor to attest to something you can watch directly adds latency without adding assurance.
- Does the fact require internal evidence to verify? Access reviews, encryption key handling, secure development practices, and incident response capability cannot be scanned from the outside. These stay in the reassessment, and no amount of monitoring substitutes for them.
- Does the fact have a divergence risk? Some claims are attested internally but testable externally: "all public endpoints enforce TLS 1.2 or higher" is a questionnaire answer you can check continuously. These belong to both instruments, because the interesting signal is when they disagree. We covered why that disagreement matters in assessed versus live vendor posture.
Applying the framework produces a clean division of labor:
- Monitoring owns: external attack surface, certificate and DNS hygiene, breach and leak intelligence, observable configuration drift, and the verification layer for externally testable claims.
- Reassessment owns: governance, internal controls, personnel security, development practices, subprocessor due diligence, business continuity, and anything requiring evidence artifacts.
- Both own: claims that are attested in the questionnaire and testable in the wild. Divergence between the two is a first-class finding, not a footnote.
What this does to the annual cycle
Continuous monitoring does not abolish the reassessment. It changes what the reassessment is for. Three practical shifts follow:
- The reassessment gets shorter and deeper. Strip out questions whose answers you already observe continuously and reinvest that questionnaire budget in the internal-control domains you cannot see. A leaner instrument also completes faster; teams that have done this report meaningfully higher vendor completion rates, though treat any specific figure as illustrative rather than guaranteed.
- The calendar stops being the only trigger. A severe monitoring signal, a breach disclosure, or sustained drift from the assessed baseline should be able to pull a reassessment forward. The calendar becomes the backstop, not the sole driver.
- Baseline discipline becomes mandatory. Monitoring only means something relative to a baseline, and that baseline should be set by a completed assessment, not by whatever the scanner happened to see last Tuesday. If the baseline silently updates every time a score recovers, drift detection quietly stops working.
This split is also the design premise behind platforms that hold both signals on one vendor record. ThirdSentry, for example, models each vendor across business criticality, assessed posture, and live external exposure, so a divergence between what a vendor attested and what is observable is flagged on the same record the assessment lives on.
Common failure modes to avoid
- Treating a rating as a reassessment. An external score cannot tell you whether offboarding works or backups restore. Monitoring extends assurance; it does not replace evidence.
- Monitoring everything at Tier 3 depth and Tier 1 urgency. Coverage breadth and response urgency should follow criticality. A cosmetic finding on a low-criticality vendor should never page anyone.
- Letting the annual cycle survive unchanged. If you add monitoring and change nothing about questionnaire scope or trigger logic, you have added cost without redesigning the system that made the cost necessary.
For implementation specifics on tooling and coverage, see our guide to continuous vendor monitoring best practices, and for where both instruments sit inside a full program, the full TPRM program guide.
The bottom line
Annual reassessment and continuous monitoring are not competitors. They are two instruments with different decay curves, and a program that assigns each risk domain to the instrument that can actually keep it fresh will catch changes months earlier than a calendar alone. ThirdSentry was built around that split: assessments, live monitoring, and drift detection against an assessed baseline, all on one vendor record, so the reassessment you run is the one the evidence says you need.
