What breaks when third-party risk reviews are still run on a calendar instead of on change events?

Why calendar reviews fail when the vendor relationship changes in between

A calendar review answers whether the vendor looked acceptable at the last checkpoint, not whether its access is still proportionate today. The failure is timing: new integrations, expanded data sharing, added credentials, or a changed support path can all alter exposure long before the next scheduled review. That gap is where stale trust forms.

When third-party oversight is tied to periodic cadence alone, the review process becomes detached from the event that actually changes risk. A vendor can remain formally approved while its technical reach has already widened, which means the organization is managing the contract state, not the live access state. That distinction matters because risk often changes at the moment of integration, token issuance, or privilege expansion.

Change-event review is more than a process preference. It is the only way to catch the specific inflection points where third-party access moves from acceptable to excessive, such as a new API connection, a fresh service credential, or a broader data scope. If those triggers are not captured, the review program will consistently lag the environment it is meant to govern.

What stale trust looks like in practice

Stale trust usually appears as a mismatch between what governance says is approved and what the system now permits. The business relationship still carries an approved status, but the vendor may now have standing credentials, additional datasets, or a deeper integration path that were never re-evaluated. That is especially common when teams add access incrementally and treat each change as operational rather than security-relevant.

The practical hazard is that change accumulates quietly. A small integration can later become a routed data feed, a support account can become a production path, or a token issued for one use can outlive the original business need. By the time the calendar review arrives, the organization may be validating a relationship that no longer resembles the one that was approved.

This pattern also weakens accountability. If review timing is disconnected from access-changing events, no one owns the moment when a third party crosses a new threshold of trust. The result is a control that feels complete on paper but is blind to the exact changes most likely to matter.

How to make third-party review event-driven instead of periodic only

Move the review trigger to the events that change exposure, not just the passage of time. A useful rule is: if the vendor gains a new integration, a new credential, a new dataset, a new environment path, or a materially broader use case, the review should reopen. That keeps the assessment aligned to actual trust boundaries rather than administrative dates.

• Trigger review when access scope changes, not only when the annual or quarterly cycle comes due.
• Require approval for new credentials, tokens, keys, or service accounts before they are used in production.
• Reassess data sharing whenever the vendor’s reachable systems, support model, or downstream processors change.
• Record the specific change event that justified continued trust, so the approval has a current technical basis.

For third-party risk teams, the core discipline is to tie governance to observable change signals. Top 10 NHI Issues is useful here because the same access-growth problem appears when credentials and permissions are allowed to sprawl without timely lifecycle review.

Real incidents show why this matters. Slack GitHub breach 2022 and Salesloft OAuth token breach both illustrate how third-party tokens can become the access path, not just the administrative detail, when lifecycle control lags behind actual use.

Practitioner Guidance

What to prioritise: Treat any new integration, token, key, delegated access path, or data-sharing expansion as a review trigger. If the change increases reach into production systems or sensitive data, it should be evaluated before or immediately after go-live, not deferred to the next scheduled cycle.

What to verify: Check whether the vendor still uses only the access that was originally approved. Verify the current credential set, the current data scope, and whether any downstream subcontractor or support pathway has been added since the last review. If the answer is unclear, the approval is already stale.

What good looks like: The review record should show a clear link between each meaningful change event and a contemporaneous access decision. That gives you evidence that trust was renewed against current conditions, not inherited from an older state.

Practitioner takeaway: The control objective is not “review vendors regularly”, it is “revalidate trust whenever access changes”. If the trigger is wrong, the review can be perfectly completed and still miss the risk that matters most.

Related resources from NHI Mgmt Group

• What breaks when identity governance is still run on a calendar instead of on risk signals?
• What breaks when organisations rely on ad hoc vendor reviews instead of a formal third-party risk process?
• What breaks when password rotation is based on the calendar instead of risk events?
• What breaks when third-party risk management depends on annual reviews?