Who should own vendor risk management in an identity programme?

Why This Matters for Security Teams

Vendor risk ownership in an identity programme is not a paperwork issue. It determines who approves third-party access, who validates the minimum access needed, and who ensures that access disappears when the relationship changes. Identity teams usually own the technical enforcement, while procurement handles contracts and business owners define the operational need. Without that split, vendors accumulate standing access, secrets drift into shared channels, and revocation becomes a best-effort exercise.

This is where NHI governance becomes a control problem rather than a procurement one. NHIs often outnumber human identities by 25x to 50x in modern enterprises, and the Ultimate Guide to NHIs shows that 92% of organisations expose NHIs to third parties, which makes vendor access a recurring attack path, not an edge case. The right ownership model must therefore connect commercial oversight to identity lifecycle enforcement, not treat them as separate tracks. That is consistent with the NIST Cybersecurity Framework 2.0, which places governance, protection, and monitoring on the same operating plane. In practice, many security teams discover vendor overreach only after a renewal, audit, or incident has already exposed the gap.

How It Works in Practice

The practical model is a three-way ownership structure. Procurement owns commercial due diligence, legal terms, and vendor exit clauses. Business owners own the need for access and the business justification. IAM and security own how access is granted, reviewed, constrained, logged, and removed. That means identity teams define the control plane for vendor accounts, API keys, service accounts, and support access, while the business validates whether the access request still matches a live use case.

For NHIs, this should be enforced through lifecycle controls: issuance, scoping, rotation, monitoring, and offboarding. The NHI Lifecycle Management Guide and the lifecycle processes for managing NHIs both reinforce that access should be tied to ownership, not just to technical creation. In mature programmes, vendor onboarding includes:

• Named business owner and technical owner for every third-party identity.
• Minimum-access approval with expiry dates and renewal triggers.
• Secrets stored in managed vaults, never in email, code, or tickets.
• Quarterly review of active vendor accounts, scopes, and dormant credentials.
• Immediate revocation when contracts end, scope changes, or risk signals increase.

Security teams should also require evidence that vendors can support removal and rotation without breaking service delivery. That is where the regulatory and audit perspectives become useful, because auditors care less about who signed the contract and more about whether access can be demonstrated, reviewed, and revoked on demand. These controls tend to break down in decentralized buying environments where departments provision vendor tools directly and IAM is brought in only after the account sprawl is already entrenched.

Common Variations and Edge Cases

Tighter vendor control often increases operational overhead, requiring organisations to balance faster onboarding against stronger access governance. That tradeoff is unavoidable in environments with many short-term suppliers, subcontractors, or managed service providers. Best practice is evolving, but there is no universal standard for exactly how often vendor access must be recertified; many organisations align reviews to contract renewal, quarterly risk cycles, or material change events.

Edge cases usually appear when a vendor acts like both a service provider and a platform operator. In those models, one vendor may need human support access, machine-to-machine API access, and delegated admin rights across multiple systems. The right answer is still not vendor-led self-governance. Identity and security teams should define the access pattern, while business owners decide whether the access is still needed. The Top 10 NHI Issues shows how easily excessive privileges and weak lifecycle controls turn a convenience relationship into a persistent exposure. Where vendors insist on standing credentials or broad support access, current guidance suggests converting those paths to time-bound access, monitored elevation, and documented emergency use only. The model becomes fragile when vendor relationships are global, highly automated, or embedded in legacy integrations because ownership, review cadence, and revocation responsibilities get blurred across too many teams.

Related resources from NHI Mgmt Group

• Who should own SaaS reporting outputs in an identity programme?
• When does secret exposure become a broader identity risk?
• What is the difference between vendor risk management and identity governance?
• Who should own third-party access risk in an identity programme?