They should re-evaluate whenever the vendor relationship changes in a material way, such as access scope, service dependency, contract status, or compliance posture. Annual review alone is too slow when third party risk changes between cycles. Event-driven review is the stronger model because it ties governance to real operational change.
How to tell when third party risk needs an event-driven review
Annual review is a coarse control, not a complete control. Re-evaluate a third party whenever something changes that alters what the vendor can reach, what data or systems it can influence, or what your organisation is relying on it to do. JumpCloud breach 2023 and Slack GitHub breach 2022 both show that vendor compromise can quickly become customer impact when trust paths and credentials are reused across environments.
The trigger is not simply “the contract exists”, it is whether the operating relationship has materially changed. A vendor gaining new API access, broader admin scope, production support privileges, or a deeper dependency into a business-critical workflow changes the risk profile immediately. A relationship can also become riskier when offboarding slips, a renewal extends access, or a compliance attestation no longer reflects the current service design.
Material change is the practical boundary. If the vendor’s access scope, data handling, subcontractors, hosting model, or integration pattern has shifted, the old assessment is stale even if the annual review date has not arrived. That is why event-driven review is stronger: it keeps governance tied to the actual exposure surface instead of a calendar reminder.
Which changes should trigger re-review immediately?
Use events that change privilege, dependency, or assurance as the trigger set. Scope expansion is the clearest example, but so are new credentials, new environments, new regions, altered retention obligations, and any change in whether the vendor can authenticate into systems that matter. Salesloft OAuth token breach and Toyota T-Connect key exposure 2022 are good reminders that long-lived or poorly governed access materialises as third party risk even when no one is actively changing the annual questionnaire.
Contract status matters too, because expired paper controls do not remove live access. If the vendor is in renewal, termination, dispute, merger, or transition, the control question changes from “is this supplier acceptable?” to “is this supplier still entitled to the access it has right now?” Compliance posture is similar: if the vendor loses or materially changes a certification, audit result, or contractual commitment, the assurance basis for continued access should be rechecked.
A useful rule is to treat any event that changes blast radius as a review trigger. That includes support tooling, token issuance, federation trust, privileged remote access, data-sharing scope, and subcontractor changes. If the answer to “what can this vendor now reach that it could not reach before?” is materially different, the review should happen now, not at the next annual cycle.
How should organisations operationalise event-driven third party review?
Build the review trigger into change management, procurement, security exception handling, and vendor onboarding/offboarding so it is not dependent on memory. The best operating model is to require a re-assessment before access is expanded, before production integration goes live, and before any material contract or control exception is approved. That makes the governance decision part of the change itself, not an after-the-fact audit.
For larger supplier estates, create a small number of clear trigger categories and assign ownership. Security should own the risk judgement, procurement should surface contractual and lifecycle changes, and system owners should report access or dependency changes as part of release or service management. The main failure to avoid is letting the business continue using a vendor under “existing approval” after the technical relationship has already changed.
Measure whether reviews are happening at the point of change, not just on a fixed cadence. If material access changes are landing without a fresh review trail, the programme is effectively calendar-based even if it claims to be event-driven. The strongest indicator of good control is that the organisation can show a recent decision for each significant change in vendor access or dependency.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 sets the technical controls, while ISO/IEC 27001:2022 and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-01 — Cyber Supply Chain Risk Management | Vendor changes alter third-party cyber risk and need governance tied to current exposure. |
| GV.RM-01 — Risk Management Strategy | Event-driven review supports a risk process based on changing conditions, not fixed cadence. | |
| PR.AA-05 — Identity Management, Authentication, and Access Control | Third-party risk changes when vendor access scope or entitlements change. | |
| Recommendation — Reassess supplier risk when scope, access, or dependency changes materially. Trigger reassessment when material vendor risk conditions change. Review and update vendor access controls whenever entitlement scope expands. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Supplier relationships require current oversight when the service or trust model changes. |
| A.5.22 — Monitoring, review and change management of supplier services | This control directly calls for monitoring and reviewing supplier service changes. | |
| Recommendation — Reevaluate supplier controls whenever the relationship materially changes. Tie supplier review to service, access, and contract changes. | ||
| DORA | ICT third-party risk management | Third-party ICT risk must be governed across the full relationship lifecycle. |
| Recommendation — Review third-party ICT risk whenever the service or dependency changes. | ||
Practitioner Guidance
What to prioritise: Re-review vendors first when the change affects production access, sensitive data, privileged workflows, or recovery dependencies, because those are the changes most likely to alter real exposure.
What to verify: Confirm that the current vendor entitlement set still matches the approved use case, that dormant access has been removed, and that any third party assurances still reflect the live service model.
Decision rule: If the vendor can now reach more systems, more data, or more users than it could at the last review, treat that as a fresh risk decision, not a documentation update.
Practitioner takeaway: Annual review is a reporting rhythm; event-driven review is a control. Use the change itself as the trigger whenever access, dependency, or assurance materially shifts.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org