Reassessment is needed whenever the vendor’s scope, control posture, data access, or business relationship changes in a way that could affect trust. Re-scoring alone is insufficient if the supplier still has active access. The decision point should be whether the current entitlement remains justified, not whether a dashboard number moved.
When a vendor change should trigger re-assessment, not just a new score
Re-score is a reporting action. Re-assess is a control decision. If the supplier’s role, data scope, delivery model, access path, or control environment changes, the original trust assumption may no longer hold, even if the vendor’s rating has only moved slightly. The relevant question is whether the current entitlement, not the scorecard, still matches the business need.
That distinction matters most where access is still active. A supplier can move from low concern to high concern without any dramatic dashboard change if it gains broader data access, new administrative rights, a different integration path, or a weaker subcontractor chain. At that point, the organisation needs to revisit who can do what, to which systems, under which conditions.
Changes that should force re-assessment usually fall into four buckets: scope expansion, control degradation, access expansion, and relationship change. Scope expansion includes new systems, new regions, new data classes, or new support functions. Control degradation includes weaker authentication, poorer segregation, unresolved audit findings, or broken offboarding. Access expansion covers longer-lived tokens, broader entitlements, and new privileged pathways. Relationship change includes subcontractors, acquisitions, platform migrations, or a materially different operating model. For a practical access-governance baseline, see IAM and IGA Basics and Third-Party, B2B and Contractor Access Guide.
Why the entitlement, not the score, is the unit of control
A vendor score can help triage, but it does not prove the access remains justified. If the supplier still has production access, the organisation is relying on an active trust relationship, not a historical assessment. That is why re-assessment should be triggered by meaningful change in the actual access path, especially when third-party credentials, tokens, or delegated permissions are in play. Token and credential-based third-party abuse is a recurring failure pattern in incidents such as Scania insurance portal breach 2025 and Slack GitHub breach 2022.
In practice, score changes matter less than whether the supplier still meets the conditions for access approval. If the vendor now touches higher-value data, uses a different integration, or relies on a new upstream provider, the review needs to revisit least privilege, segregation of duties, and whether the access should be narrowed or removed altogether. A useful governance lens is whether the current access would still be approved today, with the current facts, by the current owner.
For common third-party access failure modes, Klue OAuth Supply Chain Breach and Salesloft OAuth token breach show how integration drift and token exposure can turn a routine supplier relationship into a direct access problem.
What should force immediate review in a third-party programme
The strongest triggers are operational, not cosmetic. A new score should not be the only reason to act if the supplier has already changed in ways that alter trust. Re-assess when there is a change in data sensitivity, privilege level, integration method, contract scope, or the supplier’s own control posture. Treat subcontractor changes, support model changes, and newly introduced service accounts or tokens as especially significant because they can expand blast radius without changing the vendor’s headline risk score.
What to verify: confirm that the access owner can explain why the supplier still needs each entitlement, and that the access path, data scope, and offboarding path are all still current. If the answer depends on a stale contract, an old project, or an inherited exception, the access is due for review even if the score looks stable.
What good looks like: the third-party inventory ties each active entitlement to a current business purpose, a named owner, a review date, and a clear removal path. If any of those are missing, the organisation is managing a score, not a live trust relationship. For broader access governance and lifecycle controls, Top 10 NHI Issues and Ultimate Guide to NHIs, Key Challenges and Risks are useful navigation points.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5, CIS Controls v8 and CSA Cloud Controls Matrix set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party access changes can expose supplier identities and integrations to compromise. |
| NHI-05 — Overprivileged NHI | Reassessment is needed when supplier entitlements outgrow their current business need. | |
| NHI-07 — Long-Lived Secrets | Active supplier access often persists through tokens or secrets that outlast the original approval. | |
| Recommendation — Review supplier access paths and revoke third-party identities that no longer need production access. Reduce third-party permissions to the minimum set justified by current access requirements. Rotate or expire supplier secrets when the access context changes. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Third-party access must be reviewed and disabled when no longer justified. |
| AC-6 — Least Privilege | Access should shrink when the vendor scope or control posture changes. | |
| IA-5 — Authenticator Management | Changed third-party access often requires credential rotation or expiry control. | |
| Recommendation — Revalidate and remove supplier accounts that no longer match current business need. Reassign third-party permissions to the minimum necessary for the current task. Shorten authenticator lifetime and rotate secrets after material supplier changes. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Supplier changes affect trust assumptions and the need for reassessment. |
| A.5.18 — Access rights | Access rights should be reviewed when entitlement justification changes. | |
| Recommendation — Reassess supplier security requirements whenever the relationship or service scope changes. Review and withdraw supplier access rights when the original justification no longer holds. | ||
| CIS Controls v8 | CIS-5 — Account Management | Third-party access changes are account-management events, not just rating updates. |
| Recommendation — Maintain current inventories and promptly remove stale supplier accounts and permissions. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud supplier access changes require explicit identity and entitlement governance. |
| Recommendation — Track and recertify third-party identities, roles and entitlements when trust conditions change. | ||
Practitioner Guidance
Decision rule: if the supplier’s access, data scope, control environment, or business purpose changed, re-assess the entitlement immediately; if only the dashboard score changed, confirm whether the underlying access is unchanged before spending review effort.
What to prioritise: start with active production access, privileged paths, long-lived tokens, and any relationship that now depends on a subcontractor or a different platform integration. Those are the places where a stale approval can become a live exposure.
Practitioner takeaway: third-party risk becomes a control issue when access is still live, so the real test is whether the current entitlement is still justified, not whether the vendor score moved.
Related resources from NHI Mgmt Group
- Should organisations re-evaluate agent access after a third-party app is connected to core systems?
- How should organisations assess third-party access methods to stay compliant with privacy laws?
- When should organisations re-evaluate third party risk rather than rely on annual reviews?
- How should organisations govern third-party identity access more tightly?
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 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org