The organisation creates a gap between supplier approval and supplier exit. A vendor can be assessed, onboarded, and given access, but still retain reach after the commercial relationship changes. That is where third-party exposure becomes persistent rather than temporary, and why access scope must be paired with revocation, deletion, and account closure controls.
Where the vendor checklist breaks down
A vendor risk checklist that stops at onboarding creates a false sense of closure. The supplier may have been vetted, contracted, and granted access, but the control set never proves that access can be reduced, time-boxed, or removed when the relationship ends. That gap turns a temporary business relationship into an open-ended security dependency.
This is especially visible when the checklist covers due diligence but not exit hygiene. A clean approval process does not matter if third-party access governance is never extended to offboarding, or if the organisation cannot show who owns revocation after the contract changes.
What persists after supplier approval
What persists is not just an account, but the assumptions behind it: federation links, API credentials, shared credentials, support channels, delegated privileges, and any automation that was enabled for the vendor. If those are not explicitly retired, the supplier can retain a path into systems even after the business no longer needs that path.
That is why lifecycle controls matter more than a one-time approval decision. Joiner-Mover-Leaver control is the right mental model here because the leaver step is where dormant access, stale tokens, and forgotten integrations should be removed rather than merely reviewed.
The same logic applies to revocation evidence. If the checklist cannot show that credentials were closed, access paths were disabled, and residual secrets were rotated or destroyed, then the vendor exit is incomplete even if procurement marked the supplier relationship as ended.
Why revocation and offboarding must be part of the control set
Access revocation and offboarding controls are the mechanism that converts vendor risk from persistent to bounded. They force the organisation to define when access ends, who confirms it, what gets revoked, and how quickly the revocation happens after termination, suspension, or scope reduction.
Without that discipline, the control fails at the point where risk changes most: when the commercial relationship changes. A supplier can move from trusted partner to unnecessary exposure, yet still retain a live credential or an active integration if the checklist never required closure.
That is why a mature checklist should pair initial approval with exit criteria, and it should cover both human and non-human access paths. IAM and IGA basics are relevant here because access governance only works when provisioning and deprovisioning are treated as a single lifecycle, not separate activities.
For vendors, the practical question is whether access can be revoked fast enough to match contract termination, incident response, or a change in scope. If the answer is no, the checklist is missing a control that directly affects blast radius and recovery.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Vendor access and revocation are core cloud identity governance concerns. |
| Recommendation — Enforce IAM controls to provision, review, and revoke third-party access on exit. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Offboarding requires timely removal of vendor accounts and credentials. |
| IA-5 — Authenticator Management | Vendor access often persists through tokens, keys, and other authenticators. | |
| Recommendation — Use AC-2 to disable and remove vendor accounts when access is no longer needed. Apply IA-5 to rotate, revoke, and retire vendor authenticators during offboarding. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Supplier access must be governed across approval, review, and removal. |
| A.5.18 — Access rights | Vendor rights must be removed when the relationship or need ends. | |
| Recommendation — Define and enforce access control rules for vendor accounts across the full lifecycle. Review and revoke vendor access rights promptly at termination or scope change. | ||
Practitioner Guidance
What to verify: Confirm that every vendor relationship has an explicit offboarding trigger, an owner for revocation, and a record of what was removed. The checklist should prove closure of accounts, tokens, keys, federation trust, and shared access channels, not just document that the vendor was approved.
Decision rule: If a vendor can access production data, privileged functions, or any system that remains live after termination, require revocation and decommissioning steps before treating the supplier as fully offboarded. If the organisation cannot evidence those steps, classify the relationship as still active from an access-risk perspective.
What practitioners underestimate: The hardest failures are often indirect, such as forgotten API tokens, unrevoked support access, or dormant integrations that remain usable long after the contract ends. Those paths are easy to overlook because they sit outside the procurement workflow, yet they create the exact residual exposure the checklist was meant to prevent.
Practitioner takeaway: Vendor risk does not end at approval, it ends only when every access path can be shown to be closed, revoked, or time-bounded.