Ownership should sit with the team that approved the relationship, with IAM or security enforcing the removal step. Procurement can close the commercial side, but it should not be the only group responsible. Account deletion, access revocation, and data retention handling need named accountability before the vendor relationship is considered finished.
Who should own vendor access closure and account deletion?
Ownership should sit with the team that approved the relationship, with IAM or security enforcing the removal step. Procurement can close the commercial side, but it should not be the only group responsible. Account deletion, access revocation, and data retention handling need named accountability before the vendor relationship is considered finished.
What the ownership model should actually look like
Vendor offboarding works best when business ownership and technical enforcement are split cleanly. The relationship owner should confirm the vendor is no longer needed, the technical control owner should revoke access, and the system owner should verify that any remaining integrations, shared credentials, or delegated access paths are removed. Without that split, offboarding tends to stall in the gap between contract closure and actual access removal.
That is why the closure process should name one accountable business owner, one accountable technical owner, and one validating control owner. In many organisations, the business owner is the team that sponsored the vendor, while IAM, PAM, or security executes and records the access change. Third-party access governance is strongest when the sponsoring team cannot declare the relationship closed until the technical removal evidence exists.
This model also avoids a common failure mode: procurement closes the purchase order, but no one confirms whether the vendor still has active accounts, API access, VPN access, or recovery access. The right owner is therefore not the purchaser alone, but the team with operational knowledge of why the vendor was granted access in the first place.
Why account deletion and access revocation are separate decisions
Access closure is not a single action. Revoking access answers who can still get in; account deletion answers whether the account object should remain for audit, recovery, legal hold, or continuity reasons. In practice, some vendor identities should be disabled immediately, some should be removed after a retention period, and some should be retained in an inactive state if the organisation needs history or evidence.
That distinction matters because deletion can break investigations, billing reconciliation, support records, and evidentiary retention. The team approving closure should define the rule up front: disable now, delete later, or archive according to policy. Where privileged or emergency access existed, a control owner should also confirm whether session logs, approval records, and credential rotations are complete before the account record is removed. Privileged access management is the right control layer for this decision because it ties revocation to privilege, not just to contract status.
For shared or break-glass style access, deletion is often the wrong first instinct. The practical question is whether the account is still needed for traceability or resilience, and if so, whether it can be safely disabled, vaulted, or quarantined instead of deleted outright. Break-glass and emergency access accounts need especially careful handling because deleting them blindly can remove an important recovery path.
What should be verified before the vendor is considered closed
The closure owner should be able to show that every access path granted to the vendor has been addressed, not just the primary login. That includes direct accounts, delegated admin roles, API keys, tokens, VPN profiles, support portals, and any lingering session or remote-support capability. If the vendor touched operational systems, the verification should also confirm that logs, approvals, and evidence of removal are retained in line with policy.
A good closure checklist therefore asks three questions: what was granted, what was removed, and what still needs to be retained. If those answers are not obvious, the vendor relationship is not finished even if procurement has ended the commercial arrangement. The third-party access guide is useful here because it aligns sponsorship, review, and offboarding into one lifecycle rather than treating closure as an isolated event.
Risk and Threat Considerations
Vendor offboarding becomes risky when commercial closure is mistaken for technical closure. Leftover access is a common persistence path because the account already has trust, context, and often elevated reach into internal systems. The danger is not only external abuse, but also accidental reuse of dormant vendor credentials after the relationship has ended.
Failure mechanism: The organisation closes the contract but never completes a controlled revoke, so stale vendor accounts, tokens, or remote-access paths remain active and usable.
Impact: A former vendor relationship can become an unmonitored access path, creating avoidable exposure to unauthorized access, privilege misuse, and audit gaps.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Vendor offboarding requires rotating, revoking, or deleting credentials and tokens. |
| AC-2 — Account Management | The question is about who owns account removal and closure of vendor access. | |
| AC-6 — Least Privilege | Vendor access should be removed to eliminate standing access after the relationship ends. | |
| Recommendation — Revoke or rotate vendor authenticators before closing the account record. Assign account lifecycle ownership and require approved removal before closure. Remove unnecessary vendor privileges during offboarding and retain only justified access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Vendor access closure is an access control governance activity. |
| A.8.2 — Privileged access rights | Vendor accounts often involve privileged or elevated access that must be removed carefully. | |
| Recommendation — Define access ownership and approval for vendor deprovisioning. Review and revoke vendor privileged rights before offboarding is closed. | ||
Practitioner Guidance
What to prioritise: Assign the closure task to the relationship owner who can prove the vendor is no longer needed, then require IAM or security to execute and attest to the removal. That division prevents “someone else will do it” gaps.
What to verify: Confirm the full inventory of vendor access, including non-interactive accounts, API credentials, support channels, and any admin or recovery paths. If the organisation cannot name every access path, it cannot credibly claim the vendor is offboarded.
Decision rule: If the vendor can still authenticate to any internal system, treat the account as open regardless of procurement status; if the account only needs to exist for retention or traceability, disable or archive it instead of deleting it immediately.
Practitioner takeaway: Vendor closure is complete only when business ownership, technical revocation, and retention handling are all explicitly signed off, because each one answers a different part of the risk.