How should organisations decide when a vendor relationship is truly closed?

When is a vendor relationship actually closed?

A vendor relationship is not closed when procurement says it is closed. It closes only when access has been revoked, sensitive data has been returned or destroyed, and contractual obligations have been completed. Until those operational and technical steps are done, the relationship still carries residual exposure, even if buying activity has ended.

What “closure” has to cover beyond procurement

True closure is a lifecycle event, not a paperwork milestone. The business may stop placing orders, but the security relationship can persist through active accounts, API keys, shared folders, retained records, support portals, backups, and delegated support paths. For that reason, closure should be judged against the last remaining control dependency, not the last purchase order.

The practical test is whether the vendor can still authenticate, still see sensitive information, or still influence a system or process. If any of those remain true, the relationship is still open in a security sense. That is why closure criteria should be written to include access removal, data disposition, and evidence of contractual completion, not just a commercial offboarding date.

For organisations that manage vendors through cloud and identity controls, the closure standard should align with CSA Cloud Controls Matrix expectations around IAM, data handling, and third-party governance, so the business and technical records tell the same story.

Which closure steps determine residual exposure

The highest-risk gap is usually mismatched closure across teams. Procurement may archive the contract while IT still has active credentials, legal may retain records while operations still expose the vendor to support portals, or the vendor may still hold customer data that was never formally returned or destroyed. Any one of those gaps is enough to keep the relationship effectively open.

A closed vendor should have no remaining route to production systems, no unresolved shared secrets, and no unbounded retention of sensitive material. Where the relationship involved credentials, tokens, or cloud access, closure should include revocation and rotation, not just deactivation of a named user. Where the relationship involved regulated data, closure should also include documented destruction or return, because retention without purpose is continued exposure.

Practitioners often treat this as a vendor-management issue, but it is also an access-control and data-protection issue. The closure decision should be anchored in evidence that the vendor no longer has standing access, standing data possession, or standing obligations that create active operational dependency. If any one of those still exists, closure is incomplete.

That is why vendor offboarding checks often map cleanly to controls such as NIST SP 800-53 Rev. 5 Security and Privacy Controls for access control, auditability, and system integrity, and to the IAM domain in the CSA Cloud Controls Matrix when cloud services and third-party integrations are involved.

How should teams prove the relationship is closed?

Teams should require a closure record that ties the commercial, technical, and data steps together. A useful record answers four questions: what access was removed, what data was returned or destroyed, what dependencies were decommissioned, and what exceptions remain. Without those answers, “closed” is only an assumption.

Practitioner Guidance

What to verify: Confirm that every vendor account, shared credential, support path, integration token, and file-sharing permission has been removed or rotated, and that the evidence is recorded in one place.

Decision rule: If the vendor still has any route to sensitive data or production systems, treat the relationship as active regardless of contract status or procurement closure.

What good looks like: The closure file shows access revocation, data disposition, asset handback or disposal, and confirmation from the owning teams that no active dependency remains.

Practitioner takeaway: Vendor closure is real only when the organisation can prove that the vendor can no longer act, access, or retain anything that would keep the relationship live.

Related resources from NHI Mgmt Group

• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?
• Should organisations prioritise external exposure or internal credential governance first?