Vendor offboarding is the work of ending a vendor relationship so that the contract, the data, the accounts, and the integrations all end with it, and so that someone can show it later. Cancelling the subscription is one step. A vendor offboarding checklist covers the rest: who decided, which dates apply, what data comes back, which accounts close, what stays connected, and where the evidence lives.
The usual failure: finance sends notice and everyone relaxes. Two months later someone finds a vendor admin account still active, an API key that still works, data that was never exported, or a billing portal that only a former employee can open.
Record the commercial decision in the Renewals & Vendor Register, named account owners in People & Accounts, and the access handoff in Access Reviews. If the only open question is access at contract end, start with vendor access and contract end dates.
In short: the vendor offboarding checklist
Work through these nine steps in order. The order of steps 4 and 5 matters: validate the export before you remove your own access.
- Confirm the decision and name a business owner and a technical owner.
- Read the contract dates: notice deadline, renewal date, contract end date, and any exit terms.
- Send notice the way the agreement requires and keep the confirmation.
- Export or transfer the data you need, and have the business owner validate it, before access ends.
- Remove access: user and admin accounts, SSO assignments, service accounts, API keys, and any access the vendor's staff hold in your systems.
- Disconnect integrations and recover anything the vendor supplied.
- Close the commercial side: final invoice, payment method, credits, and billing contacts.
- Ask the vendor to return or delete your data and record what they confirm.
- Update your registers and write a short completion record that lists any open items.
The checklist records and coordinates the work. Authorized people still do the cancellation, export, access removal, and key rotation in the vendor system or the connected source systems.
What vendor offboarding means
Vendor offboarding is the operational process of ending or changing a vendor relationship while handling the contract, data, accounts, access, integrations, and evidence. A cancelled subscription says nothing about whether data was exported or access was removed.
Security frameworks treat this as planned work, not cleanup. Outcome GV.SC-10 in the NIST Cybersecurity Framework 2.0 expects cybersecurity supply chain risk management plans to "include provisions for activities that occur after the conclusion of a partnership or service agreement." NIST's implementation examples for that outcome include verifying that supplier access is deactivated promptly once it is no longer needed, and that assets holding the organization's data are returned or properly disposed of.
Privacy law adds a specific duty for some vendors, not all. Where a vendor acts as your processor of personal data under the GDPR, the contract has to require the processor to delete or return that data when the service ends, at your choice, unless the law requires it to be stored (GDPR Article 28(3)(g)). Offboarding is the moment you use that clause. It does not apply to vendors that hold no personal data for you, or to relationships the GDPR does not cover.
Who owns what
Offboarding fails when each team finishes its own part and assumes the rest happened. Name one person or role for each of these before you close step 1.
- Business owner: owns the decision, the reason, and the choice of what data to keep. Signs off the completion record.
- Technical owner: owns access removal, integrations, export mechanics, and the technical evidence.
- Finance or procurement contact: owns notice, the final invoice, the payment method, and credits.
- Legal or privacy contact, where one exists: owns questions about contract terms and data-processing obligations.
- Vendor contact: the account manager or support route that confirms cancellation, the end date, and data handling.
In a team of one, the same person may hold three of these roles. Write the names anyway. If an owner is unknown, write "unknown" and the name of the person responsible for finding out.
Step 1: confirm the decision and owners
Do not start from a vague "we are probably cancelling." Record:
- vendor or service name;
- decision: cancel, replace, downgrade, let expire, or keep for archive access only;
- decision date and a one-line reason;
- business owner and technical owner;
- replacement system, if there is one;
- open questions.
If the decision is not final, mark it as pending and assign a decision owner. Do not begin irreversible technical work on a pending decision.
Sometimes the vendor decides for you by retiring a product. The IT Admin Change Calendar lists dated product retirements and other admin-impacting changes for Microsoft 365, Google Workspace, Atlassian, and Apple.
Step 2: read the contract dates and exit terms
Three dates matter, and they are often different.
- The notice deadline is the last date you can give notice to cancel or change before another term starts.
- The renewal date is when the next term starts or the subscription rolls over.
- The contract end date is when service, access, and support are due to stop.
Track only the renewal date and you can miss the notice deadline. Track only the end date and you can miss the window for exporting data.
While the agreement is open, also note:
- how notice must be given, and to whom;
- any early-termination fee or minimum commitment;
- what the agreement says about returning or deleting your data, and how long you keep access to export it;
- whether the vendor owes any transition help.
The agreement governs all of this, and terms differ between vendors. If terms are disputed or unclear, involve someone qualified to read them. For the timing mechanics, see renewal date vs notice deadline and 90-60-30 renewal reminder rules.
Step 3: send notice and keep the confirmation
Finance, procurement, or the assigned owner sends notice through the route the agreement requires. Then capture:
- who sent the notice and on what date;
- the vendor's confirmation, with a ticket, case, or email reference;
- the confirmed end date and any conditions attached to it;
- a contract amendment or termination note, if one exists;
- the final invoice or credit note, when it arrives.
Notice sent is not notice confirmed. Keep the item open until the vendor confirms the end date in writing.
Step 4: export and validate data before access ends
Data is where vendor offboarding becomes risky, and this step has a hard deadline. Once access ends, the export may no longer be possible.
Record:
- what data the vendor system holds;
- who decides what must be kept;
- whether an export or transfer is required, and where the result will be stored;
- who validates it;
- how long it must be retained.
Have the business owner validate the export, not only the person who ran it. "Exported a file" is weaker than "Support confirmed the ticket history export opens and contains the active client projects."
Step 5: remove accounts and access
Vendor offboarding usually touches accounts. Look for:
- named employee accounts, including former employees;
- administrator accounts;
- billing portal and support portal users;
- contractor accounts;
- shared accounts and service accounts;
- API users and keys;
- SSO app assignments, and local accounts that sit outside SSO;
- emergency or break-glass accounts.
Then look the other way. Check what access the vendor's staff hold in your systems: support logins, guest accounts, shared mailboxes, remote-access tools, and delegated admin rights. NIST's examples for GV.SC-10 name this directly, and NIST SP 800-53 Rev. 5 covers the same ground in controls AC-2 (account management) and PS-7 (external personnel security).
Hand the work to an access review when accounts, admin rights, or integrations remain in scope. The handoff should say which system is in scope, which accounts need review, who reviews them, what action was taken, and where the source-system evidence lives. The manual accounts register fields and the former employee account checklist help here.
Order matters. Remove the vendor's access to your systems as soon as it is no longer needed. Remove your own users' access to the vendor system only after the export in step 4 is validated.
Step 6: disconnect integrations and recover assets
A system can stay connected after the vendor is commercially gone. The technical owner should check:
- API keys, webhooks, and data sync jobs;
- SSO configuration;
- email routing, notification settings, and support addresses;
- domain, DNS, or website references, including embedded forms and widgets;
- scheduled reports, exports, backup jobs, and monitoring alerts;
- shared folders and documentation links.
Rotate any credential the vendor knew or stored. Recover or account for anything the vendor supplied, such as loaned hardware, security tokens, or licenses held in the vendor's name.
No register discovers all of this automatically. The technical owner reviews the system and its connected tools, then records the result and updates the systems catalog if the system is listed there.
Step 7: close the commercial side
The main application can be closed while money still moves. Check:
- the final invoice, and any credit or refund due;
- the payment method, so a card or direct debit is not charged again;
- purchase orders or recurring approvals tied to the vendor;
- billing and support contacts that still point to someone who has left.
Step 8: ask for data return or deletion and record the answer
Once your export is safe, ask the vendor what happens to the data they still hold: what is returned, what is deleted, when, and what stays in backups and for how long.
Use careful language in the record. Do not write "data deleted" unless you hold evidence from the vendor or the system owner. Write "deletion requested," "deletion confirmed by vendor on 2026-09-04," "retention decision pending," or "no export required per business owner."
Step 9: update the registers and write the completion record
Update the renewal record so the vendor does not reappear as a mystery renewal next year. Record the status, the decision note, the notice and end dates, the export and access-review status, the last reviewed date, and a next check date if anything remains open.
Do not delete the row. A retired vendor record may be the only evidence that a decision was made. The renewal ledger hub covers what belongs in the record.
Then write a short completion record that shows the vendor was handled deliberately:
- Vendor: Acme Support Desk.
- Decision: cancel and replace with the internal support platform.
- Business owner: Head of Support. Technical owner: IT Manager.
- Notice sent: 2026-07-10. Vendor confirmed: 2026-07-14.
- Contract end date: 2026-08-31.
- Data export: completed and validated by Support Ops.
- Access review: admin and user accounts reviewed; two removals completed in the source system; one archive account remains until 2026-09-15.
- Open item: API key rotation scheduled with Engineering.
- Evidence: renewal decision note, vendor confirmation, access review completion record.
That summary is operational evidence. It is not legal advice and not a certification.
Worked example: a cancellation that becomes controlled offboarding
Jordan finds a project-management tool due to renew in forty days. The company has moved to another system and finance wants the charge stopped. The agreement puts the notice deadline thirty days before renewal, which leaves ten days. Finance sends notice that week and Jordan records the confirmation date.
The business owner wants active client projects exported and archived experiments left behind, so Jordan records where the export will live and who validates it. Two former employees still have local accounts, and one integration still posts status updates to the old tool. The technical owner removes the webhook in the source system and records the action reference. One archive account stays open, with an owner and an end date.
Common mistakes
- Treating cancellation as completion. Cancellation changes the commercial relationship. It does not show that data was exported, access was removed, or integrations were disconnected.
- Removing access before the export is validated. Closing accounts first can lock the team out of data the business still needs.
- Deleting the vendor row too early. A retired vendor record is evidence. Keep enough history to explain what happened.
- Hiding open items. An open item with an owner and a date is normal. One that vanished into chat is the problem.
Vendor offboarding record template
Copy this into a ticket, a document, or the notes on the vendor record. Fill every line, and write "unknown" plus an owner where you do not have the answer yet.
VENDOR OFFBOARDING RECORD
Summary
Vendor / service:
Decision (cancel, replace, downgrade,
let expire, archive only):
Reason:
Replacement system:
Dates
Notice deadline:
Notice sent:
Vendor confirmed:
Renewal date:
Contract end date:
Data export deadline:
Access review due:
Owners
Business owner:
Technical owner:
Finance or procurement contact:
Legal or privacy contact:
Vendor contact:
Data
Export required (yes / no, decided by):
Export location:
Validated by / date:
Retention period:
Deletion or return requested / confirmed:
Access
User and admin accounts reviewed:
Billing and support portal users:
Shared, service, and API accounts:
SSO assignment removed:
Vendor staff access to our systems removed:
Access review record:
Integrations and assets
API keys, webhooks, sync jobs:
Email, DNS, website references:
Credentials rotated:
Hardware, tokens, licenses recovered:
Commercial
Final invoice / credit:
Payment method removed:
Billing contact updated:
Evidence
Decision note:
Vendor confirmation reference:
Export validation:
Access review completion:
Open items
Action / owner / due date:
Completion
Status (open / open items remain / complete):
Signed off by / date:
Reference evidence by location. Do not paste passwords, keys, or tokens into the record.
What CertPilot does and does not do here
CertPilot records the human side of this checklist. In the Renewals & Vendor Register you can keep a vendor record with its renewal date, notice deadline, auto-renew flag, decision status, decision notes, business owner, technical owner, vendor contact, and last reviewed date, and mark the record as cancelled instead of deleting it. Access Reviews records review decisions and a completion log, and People & Accounts holds the named accounts. Renewal and access-review records feed the evidence reports; the sample reports show the output style with fictional data.
CertPilot does not cancel contracts, send notice, read contract terms, parse invoices, monitor payment cards, discover vendors or accounts, export or delete vendor data, remove accounts, rotate keys, or disconnect integrations. It does not confirm that a vendor deleted your data, and nothing here is legal advice.
Frequently Asked Questions
Who should own vendor offboarding?
The business owner owns the decision and the data choices, the technical owner owns access and integrations, and finance or procurement owns notice and the final invoice. Named owners matter more than the exact split.
Should vendor offboarding trigger an access review?
Yes, when the vendor had user accounts, admin access, support portal access, integrations, service accounts, SSO assignments, or access to your data. The review records whether access is still needed and what action was taken.
Does CertPilot remove vendor access automatically?
No. CertPilot records the review and the evidence. An authorized person makes the access change in the vendor system or the connected source system.
How long does vendor offboarding take?
It depends on the notice period in the agreement and on how much data and access the vendor holds. As an illustration, the internal work for one SaaS tool can be planned across ten working days: decision and notice first, then export and validation, then access and integrations, then the registers and the completion record.