Vendor risk does not end when the contract ends
Procurement teams often invest heavily in supplier selection and little in supplier exit. That is a control failure.
When a technology or service vendor is offboarded, the organization may still face active accounts, retained data, unmanaged integrations, unreturned assets, unresolved invoices, inaccessible records and dependence on people who are already leaving the relationship. A signed termination notice does not close those exposures.
A controlled exit needs five verified outcomes:
- the parties agree what the contract requires;
- data and assets are located and dispositioned;
- identities, integrations and privileges are removed;
- service and knowledge are transferred without an avoidable operational gap;
- closure evidence is retained with named owners.
This guide turns those outcomes into a practical vendor-offboarding system.
The CLOSE framework
MTF Institute’s CLOSE framework organizes the exit into five workstreams.
| Workstream | Core question | Required evidence |
|---|---|---|
| C — Confirm obligations | What do the contract, law and operating plan require at exit? | Termination notice, obligation register, dates, owners, unresolved exceptions |
| L — Locate data and assets | Where are organizational data, credentials, devices, records and copies? | Data/asset inventory, owner confirmation, subprocessor map |
| O — Offboard identities and integrations | Which human and machine access paths must be disabled? | Revocation log, API-key rotation, SSO removal, integration test |
| S — Secure continuity and transfer | How will the business continue and knowledge move? | Transition plan, export validation, runbook, support contacts, acceptance record |
| E — Evidence closure | How will the organization prove that the exit is complete? | Deletion or return evidence, final access review, residual-risk acceptance, closure approval |
The framework applies to software, cloud, professional services, outsourced operations and data-processing relationships. The depth should follow the exposure.
Start with an exit exposure profile
Before building the task list, classify the relationship across six dimensions.
| Dimension | Low exposure | Higher exposure |
|---|---|---|
| Data | Public or non-sensitive data | Personal, confidential, regulated or high-volume data |
| Access | No environment access | Privileged, production or persistent access |
| Dependency | Easily replaceable | Operationally critical or concentrated |
| Integration | Manual exchange | APIs, SSO, agents, service accounts or embedded software |
| Assets | No organizational assets | Devices, keys, records, models, code or physical materials |
| Transition | Immediate substitution | Complex migration, knowledge transfer or regulatory retention |
High exposure requires earlier planning, stronger evidence and executive ownership. It should not wait until the final service day.
The NIST Cybersecurity Supply Chain Risk Management guidance treats supplier risk as a lifecycle concern. Exit is part of that lifecycle, not an administrative afterthought.
Build the exit obligation register
Extract obligations from the contract, order forms, data-processing terms, security schedules, statements of work and operating procedures. The register should separate four things that are often mixed together:
- contractual obligation: what the supplier must do;
- business requirement: what the organization needs to continue operating;
- control action: what internal teams must disable, rotate or validate;
- evidence standard: what will prove completion.
| Obligation | Due date | Supplier owner | Internal owner | Evidence | Status |
|---|---|---|---|---|---|
| Export customer records | T–10 days | Supplier service lead | Data owner | File manifest and validation result | Open |
| Revoke support access | T0 | Supplier security | IAM owner | Account and group review | Open |
| Delete residual copies | T+30 days | Supplier privacy | Privacy owner | Authorized deletion attestation | Open |
| Return company laptop | T0 | Supplier manager | Asset owner | Asset receipt | Open |
| Transfer operating runbook | T–15 days | Supplier operations | Service owner | Accepted version and walkthrough record | Open |
The register prevents an easy but dangerous assumption: that the supplier owns every exit action. Internal teams normally control SSO, network rules, payment approvals, integrations, backups and downstream business acceptance.
Locate data before requesting deletion
“Delete our data” is not an operational instruction. First identify:
- production records and tenant storage;
- backups and disaster-recovery copies;
- logs, tickets and support attachments;
- collaboration spaces and email;
- analytics, telemetry and derived datasets;
- sandbox, test and demonstration environments;
- subprocessors and downstream service providers;
- local exports held by authorized personnel.
Then assign a permitted disposition: return, transfer, retain for a defined obligation, delete, or anonymize under an agreed standard. Legal, regulatory and record-retention duties may constrain deletion. Those decisions require appropriate legal and privacy review; the checklist is not a substitute for it.
The US Federal Trade Commission’s data-security guidance recommends keeping only what is needed and properly disposing of information that is no longer required. Procurement should translate that principle into a vendor-specific inventory and evidence trail.
Close every access path
Human accounts are only one part of access. The offboarding scope can include:
- named user and administrator accounts;
- shared or emergency accounts;
- API keys, tokens and client secrets;
- service accounts and automation credentials;
- SSO assignments and federation trust;
- VPN, remote-support and privileged-access routes;
- allowlists, certificates and SSH keys;
- integration webhooks and scheduled transfers;
- vendor-managed agents or software components;
- physical badges, devices and removable media.
Use a two-sided validation. The supplier confirms what it has disabled; the organization independently checks its identity, network, application and integration systems. NIST SP 800-53 provides a broad control catalogue for access, account, media and system-management practices, but the buyer must map relevant controls to its own environment.
Use a time-based exit plan
| Timing | Management objective | Typical actions |
|---|---|---|
| T–60 to T–30 | Decide and prepare | Confirm authority, freeze scope, identify dependencies, appoint owners, test export method |
| T–30 to T–10 | Transfer safely | Export data, validate completeness, document processes, train successor, resolve open incidents |
| T–10 to T0 | Remove dependency | Cut over integrations, rotate credentials, redirect workflows, prepare communications |
| T0 | End service and access | Disable accounts, stop transfers, recover assets, confirm support route and final operating state |
| T+1 to T+30 | Prove closure | Validate deletion/return, close invoices, review logs, document residual risk and approve closure |
The sequence should be adapted to the contract and service. A highly integrated provider may need months. A low-risk subscription may need days. What matters is that timing comes from dependency and evidence, not from a generic template.
Worked example: why “account closed” is not enough
A company replaces a customer-support platform. Procurement confirms contract termination, and IT disables 42 user accounts. The exit still remains incomplete because:
- two service accounts continue sending data;
- a business-intelligence connector retains an API token;
- historical ticket attachments have not been exported;
- the supplier’s backup-retention period is not documented;
- the new provider cannot reproduce one escalation workflow.
The CLOSE review identifies five separate closure decisions. Access is not closed until human and machine paths are tested. Data is not closed until the export is accepted and residual copies are dispositioned. Continuity is not closed until the escalation workflow operates under the new model.
Define closure gates
The steering owner should not mark the supplier “offboarded” until all applicable gates pass.
- Authority gate: termination and exit instructions were issued by authorized parties.
- Data gate: required exports were validated and residual data has an approved disposition.
- Access gate: accounts, credentials and integrations were independently reviewed.
- Continuity gate: replacement processes operate and critical knowledge is accepted.
- Evidence gate: required records, attestations and residual-risk decisions are stored.
- Commercial gate: final charges, credits, commitments and disputes are resolved or owned.
A failed gate may be accepted temporarily only through a named residual-risk decision with an owner, due date and compensating control.
Metrics that reveal weak offboarding
Track outcomes rather than completed checkboxes:
- percentage of exits with an approved plan before notice;
- median time from T0 to access closure;
- number of credentials or integrations found after T0;
- percentage of data exports validated before service termination;
- overdue deletion or asset-return evidence;
- critical incidents or business interruptions caused by exit;
- residual-risk items open more than 30 days.
These measures show whether the exit system works across the supplier portfolio.
Connect onboarding and offboarding
The best exit control is negotiated before the relationship begins. During due diligence and contracting, define export formats, assistance, notice periods, deletion, evidence, subprocessor responsibilities, access ownership, continuity and transition charges. The Procurement Information Security framework helps teams identify those requirements before approval.
Deepen your procurement capability
Professionals who want to strengthen sourcing governance, supplier lifecycle management and third-party risk can explore the Professional Certificate in Strategic Procurement, Sourcing & Vendor Risk Management.