Accountability should be shared, but not vague. Procurement typically owns contract lifecycle details, while security owns access policy, review standards, and risk monitoring. Business owners should confirm the relationship still has a valid need. Clear ownership matters because joiner, mover, leaver changes, breach disclosure, and certification failures all require coordinated action across teams.
How accountability should be split
The cleanest model is shared accountability with named ownership, not a diffuse committee. Procurement should own the contract record, renewal dates, supplier clauses, and commercial escalation path. Security should own the access control standards, review criteria, and ongoing risk signals. Business owners should validate the relationship still has a legitimate operational need and that the access granted still matches the service being delivered.
This division matters because third-party access is both a commercial relationship and a security control surface. When responsibility is blurred, reviews slip, renewals happen by default, and access can outlive the business justification that originally approved it. That is where contract hygiene and access hygiene diverge, and both need active ownership.
For the identity and access dimension of this problem, the strongest practice is to treat contract renewal, access recertification, and offboarding as linked lifecycle events. NHIMG’s Lifecycle Processes for Managing NHIs is useful here because it frames review, rotation, and deprovisioning as coordinated control points rather than isolated tasks. That same logic is reinforced by Guide to NHI Rotation Challenges, which shows why renewal dates and credential validity should not be allowed to drift independently of governance checks.
A practical ownership model is to assign one accountable owner for each of three questions: who can approve the relationship, who can approve the access, and who can terminate either one. If those are not explicit, teams often assume someone else has checked the supplier, the account, or the entitlement set. That is how stale third-party access survives contract renewal and how renewal gets approved even though access should have been reduced or removed.
What good review and renewal process looks like
Good practice is a recurring workflow, not a one-time vendor onboarding exercise. Before renewal, the business owner confirms the service is still needed, security confirms the access scope is still appropriate, and procurement confirms the contract terms still reflect current obligations, including breach notice, subprocessors, data handling, and right-to-audit language where relevant.
That review should be anchored to actual usage and entitlement evidence. If the third party has not used the access in the review window, or if the access model no longer matches the service being provided, renewal should trigger a reduction, revalidation, or removal decision rather than an automatic extension. For organisations that struggle with this at scale, NHIMG’s Key Challenges and Risks and Top 10 NHI Issues are good navigation points for the recurring failure modes: overprivilege, visibility gaps, and unmanaged credentials.
Where access is mediated by secrets, tokens, or API keys, renewal also needs a hard decision on whether the credential should be rotated, shortened in lifetime, or replaced with a more constrained access model. The relevant control is not just “is the contract still valid?” but “is the current access path still the minimum necessary path?” That is why a supplier review that ignores the access artifact itself is incomplete.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Third-party access renewal depends on least-privilege and access review discipline. |
| 5 — Account Management | Renewal and offboarding require explicit ownership of external accounts and entitlements. | |
| Recommendation — Enforce business-need reviews and remove stale third-party access at renewal. Assign accountable owners for external accounts, approvals, and termination. | ||
| NIST Zero Trust (SP 800-207) | 3 — Policy Enforcement Point and Policy Decision Point | Third-party access should be revalidated continuously, not assumed safe after contract renewal. |
| Recommendation — Reassess third-party access decisions at each policy decision point. | ||
| NIST CSF 2.0 | GV.OC-01 — Organizational Context is Established and Communicated | Third-party relationships need clear ownership and business context to support renewal decisions. |
| PR.AA-01 — Identities and Credentials are Managed | External access must be reviewed, renewed, and revoked through controlled identity lifecycle processes. | |
| RS.MA-1 — Mitigation is Executed | Breach disclosure and certification failures require coordinated action across procurement, security, and business owners. | |
| Recommendation — Document who owns the relationship, access, and renewal decision. Review, rotate, and revoke supplier credentials on a defined schedule. Coordinate revocation and contract actions when supplier risk changes. | ||
Practitioner Guidance
What to prioritise: Put the renewal calendar, the access review cadence, and the offboarding trigger in the same control process. If those timelines are separate, the weakest one usually becomes the default and access persists after the business need has changed.
What to verify: Require evidence that the supplier still needs the access they have, that the access is mapped to a named business purpose, and that there is a documented owner who can revoke it. If nobody can produce that evidence quickly, the relationship is already undercontrolled.
Decision rule: If the contract is renewing but the access justification is unclear, renew the commercial term only conditionally and force a security and business reapproval before access is extended. If the business cannot defend the need, treat removal as the safer default.
Practitioner takeaway: The important judgement is to manage third-party access as a living entitlement, not a procurement checkbox, because the risk usually comes from access that outlasts both the contract and the business need.
Related resources from NHI Mgmt Group
- How should security teams limit data access when they connect an identity platform to many third-party services?
- What is the difference between reviewing human access and reviewing NHIs?
- Who is accountable when third-party remote access is overused in public safety environments?
- Who is accountable for third-party access after a campaign or project ends?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
