Who is accountable for access when a vendor supports a transformation programme?

Accountability should sit with the organisation that owns the business process, not with the vendor alone. External partners may administer systems or build components, but the enterprise must define approval, expiry, and revocation rules so access does not persist after the support relationship changes.

Why This Matters for Security Teams

When a vendor supports a transformation programme, the biggest risk is not who can click through a workflow. It is who can approve, scope, and remove access when the work changes. Accountability must follow the business process owner because that role understands the operational need, risk tolerance, and end date. Vendors can administer systems, but they should not own the access decision itself.

This distinction matters because third-party access often outlives the project that justified it. NHI Management Group notes that 92% of organisations expose NHIs to third parties in some form, which makes supplier access a supply chain issue as much as an identity issue, as covered in the Ultimate Guide to NHIs. The governance failure is usually not a missing contract clause; it is unclear ownership of approval, expiry, and revocation once delivery starts to slip or the support model changes. OWASP also treats non-human access as a distinct control problem in the OWASP Non-Human Identity Top 10.

In practice, many security teams discover that vendor access was never formally reapproved until an audit, a contract dispute, or an incident forces the review.

How It Works in Practice

The cleanest model is a three-way split: the business owner approves the need, the security or IAM function enforces the control pattern, and the vendor operates only within the granted bounds. That means the enterprise defines access scope, approval chain, TTL, and revocation triggers. The vendor may request access and use it, but it should not be the final authority on whether access exists, how long it lasts, or what happens when the transformation programme ends.

For vendor-supported programmes, best practice is to issue access as time-bound and purpose-bound rather than broad and persistent. Current guidance suggests using just-in-time access for privileged tasks, short-lived secrets for automation, and explicit offboarding steps when the support relationship ends. The Ultimate Guide to NHIs — Key Challenges and Risks highlights why stale credentials and weak offboarding are common failure points, especially when multiple teams assume someone else owns revocation.

• Define the process owner as the accountable approver for access requests.
• Use role-based or entitlement-based access only as an implementation detail, not as the accountability model.
• Set expiry dates tied to milestones, not open-ended project membership.
• Require explicit revocation when a vendor changes staff, scope, or contract status.
• Log who approved access, who can renew it, and who must confirm offboarding.

For identity governance, the practical test is simple: if no internal owner can explain why the vendor still needs access next month, the access should already have a removal date. NIST’s zero trust guidance also supports continuous verification and least privilege, which is reinforced by the CISA Zero Trust Maturity Model and the access-control principles in NIST SP 800-207. These controls tend to break down in multi-vendor programmes where one supplier administers the environment, another delivers the change, and no single internal owner is assigned revocation authority.

Common Variations and Edge Cases

Tighter access governance often increases delivery overhead, so organisations must balance speed against the risk of unmanaged third-party privilege. That tradeoff becomes most visible in transformation programmes with aggressive deadlines, outsourced operations, or shared service platforms. In those environments, “temporary” access easily becomes inherited access unless the enterprise enforces a renewal rhythm and a named owner.

There is no universal standard for this yet, but current guidance suggests treating vendor access differently from vendor responsibility. A supplier may be accountable for how its staff use granted access, while the enterprise remains accountable for the approval model, expiry rules, and final revocation. This is especially important where a vendor manages NHIs such as service accounts, API keys, or CI/CD automation. NHI Mgmt Group’s research shows that only 20% of organisations have formal offboarding and key-revocation processes, which is why supplier access often lingers after a programme phase closes, as discussed in the Ultimate Guide to NHIs — The NHI Market.

Exception handling should be documented up front for emergency support, cutover windows, and break-glass access. In those cases, the business owner still owns the decision, while security owns the evidence trail and post-event review. Without that split, access decisions drift into vendor convenience rather than enterprise accountability.

Related resources from NHI Mgmt Group

• Who should be accountable for revoking shared credential access?
• Who is accountable when a platform vendor changes ownership or branding?
• Who is accountable when configuration drift causes an access failure or breach?
• Who should be accountable for access to a self-hosted credential store?