How to offboard a vendor without leaving data or access behind

Supplier offboarding fails for the same reason onboarding used to fail: every team assumes another team has it. Procurement thinks IT pulled the access. IT thinks the business owner asked for the data back. Finance keeps paying because nobody told accounts payable the contract ended. One accountable owner and a short responsibility table fix it, provided everyone has seen the table before the first exit starts.

Offboarding sits last in the third-party lifecycle because it is where the earlier stages pay off or do not. Your onboarding record tells you what access was granted, your contract review tells you the exit terms, and your data map tells you what to ask for back. Programs that run the exit as a workflow with owners and evidence, rather than a calendar reminder, close vendors in weeks. Certa's post on supplier offboarding in the lifecycle covers how the stages hand off to one another, and on Certa's own lifecycle map, Offboarding is the stage that cleanly closes out access, data and obligations at exit.

Open the contract before you open the letter template. Termination for convenience and termination for cause carry different notice periods, different fees and sometimes different data obligations. Sending a convenience notice when you have cause, or the reverse, can cost you months and a fee.

Pull these terms onto one page:

• Notice period and the form notice must take (registered mail, a named officer, a specific address)
• Termination fees, minimum commitments, and whether prepaid amounts are refundable
• Transition assistance: how long the vendor must keep providing the service after notice, and at what price
• Data return and destruction: format, deadline, who certifies, what the vendor may keep and for how long
• Subprocessor flow-down: whether the vendor must certify deletion by its own vendors
• Survival clauses: confidentiality, audit rights, indemnities and record retention that outlive the agreement
• The auto-renewal date and the last day you can stop it

The Interagency Guidance's contract section describes what an effective termination clause does. It provides "termination and notification requirements with reasonable time frames to allow for the orderly transition of the activity," provides for "the timely return or destruction of the banking organization's data, information, and other resources," and assigns "all costs and obligations associated with transition and termination." It also expects a bank to be able to terminate with reasonable notice and without penalty if its primary federal regulator directs it. DORA goes further for critical or important ICT services: Article 30(3)(f) requires the contract itself to carry exit strategies with a mandatory transition period, and Article 30(2)(d) requires provisions on "access, recovery and return in an easily accessible format of personal and non-personal data" when the arrangement terminates.

If the contract is silent on any of these, you are negotiating the exit now, from a weaker position than you had at signing. Write down what the contract gives you, what it does not, and what you will ask the vendor for. Certa's contract lifecycle management guide walks through the obligations worth capturing at signature so this page exists before you need it. On the platform, Certa's Contracts Agent reads the terms, missing or non-standard clauses, obligations, key dates and auto-renewals out of the agreement and slots into your existing review rather than replacing it, which is where most exits either hold their schedule or lose it.

A vendor contract termination letter does three jobs. It starts the notice clock, it puts the exit obligations in writing, and it becomes the first exhibit in the evidence file. Vendor termination letters that only say "we are ending our agreement" do the first job and skip the other two.

Keep it to a page, send it in the form the contract requires, and cover:

1. The agreement being terminated, by title, date and parties, and the clause you are exercising (convenience, cause or expiry).
2. The effective date, computed from the notice period, and the last day of service.
3. The transition period you are invoking and what the vendor must keep doing until it ends.
4. The data obligations: return by a date in a named format, then destruction with a certificate, including copies held by subprocessors.
5. The access obligations: the vendor's written confirmation that it has stopped using your credentials, systems and premises.
6. Commercial close-out: the final invoice deadline, disputed amounts, refunds and returned equipment.
7. A named contact on each side and a request for written acknowledgment within a set number of days.

A termination of services letter to vendor that goes out for cause stays factual. Cite the breach, the clause and the cure period if one applies, and leave the adjectives out. Legal reviews it before it goes. Your exit owner files the sent copy, the delivery receipt and the vendor's acknowledgment together, because those three documents are what prove the clock started.

Access is where vendor exits leak. Named user accounts get disabled because somebody remembers them. Service accounts, API keys, VPN tunnels and SSO integrations do not, because nobody owns them once the project ends. An IT offboarding checklist for vendors has to come from the access inventory, never from memory, and every line needs a date and a name.

Work it in this order. Cut the paths that could move data out before you cut the ones used to log in.

• Freeze, then revoke: disable every vendor identity at the cutoff, delete only after the log review, and never delete first
• API keys, OAuth grants and webhooks: rotate or revoke every key the vendor was issued, and every key your systems hold for the vendor's service
• Network: VPN accounts, site-to-site tunnels, firewall allow rules, IP allowlists, SFTP accounts and jump hosts
• Identity: SSO application assignments, federated trusts, guest accounts in your tenant, group memberships, conditional access exceptions
• Shared resources: shared mailboxes, forwarding rules, distribution lists, chat channels and guest users, shared drives and open links
• Secrets the vendor knew: any password, certificate or token the vendor could have seen, rotated
• Physical: badges, keys, parking and visitor pre-approvals, and any equipment still on site
• Your credentials on their side: your logins to the vendor's portal, their copies of your certificates, your data in their support tools

Then review. Pull the authentication and data egress logs for the vendor's identities for the last 30 to 90 days. Look for logins after the stop-work date and bulk downloads before it, and keep the review memo on file. An offboarding security checklist that ends at "accounts disabled" has not checked whether anything left before the lights went out. Certa's post on cybersecurity in TPRM goes deeper on the connection and fourth-party exposures that outlast a vendor.

Data is the step most programs treat as a checkbox and auditors treat as the whole exam. Three outcomes are possible for each data set the vendor holds: you get it back, the vendor destroys it, or the vendor keeps it under a documented exception such as a legal hold or a statutory retention period. Every data set gets one of the three, in writing.

Start with the return. Specify the format (an export in an open format you can actually load, not a proprietary backup), the transport (an encrypted channel, with hashes), the deadline, and who on your side confirms receipt and completeness. Load the export before you authorize destruction. A vendor that destroyed your data on your instruction will not recover it when the export turns out to be truncated.

Then the destruction. NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization (September 2025, superseding the 2014 Rev. 1), defines three sanitization methods: clear, purge and destroy. Clear applies logical techniques that protect against simple, non-invasive recovery. Purge renders recovery infeasible even with state-of-the-art laboratory techniques while leaving the media reusable, and NIST singles out cryptographic erase as the purge technique that matters for encrypted and virtual storage, where it may be the only purge option available. Destroy leaves the media unable to store data at all. Which method is right follows the sensitivity of the data and the type of media, so ask the vendor which method it used, on what, and how it verified the result. The NIST media sanitization guidelines are the reference your InfoSec team and your vendor should both be reading.

A certificate matters as much as the act. Section 4.6 of SP 800-88 Rev. 2 says a certificate of sanitization should be completed for each item of media sanitized, and lists what it should record: manufacturer, model, serial number, media type, sanitization method and technique, the tool used including its version, the verification method, and the name, title, date, location and signature of the person who verified it. For a cloud or SaaS vendor the equivalent is a signed statement naming the data sets, tenants and backups covered, the method, the date, and the subprocessors that have certified the same. Accept nothing less specific.

Personal data adds a layer. The data processing agreement normally sets the return-or-delete choice and the deadline at the controller's instruction, and it should flow down to subprocessors. If your DPA is thin here, Certa's data processing agreement basics cover the terms to look for. Under DORA, Article 30(2)(d) already requires in-scope contracts to provide for access, recovery and return of personal and non-personal data on termination, so for critical ICT services the gap should not exist.

Money and assets are the part of a vendor termination checklist that finance will run with or without you, so give finance the dates. Aim for a zero balance on both sides, no asset of yours in the vendor's hands, and no obligation of either party still running unnoticed.

• Final invoice: a deadline for the vendor to bill, a review against the contract's termination fees, and a dispute window
• Credits and refunds: prepaid fees, unused licenses, deposits, volume rebates
• Equipment and assets: your hardware on their site, their hardware on yours, leased devices, software licenses to deprovision or transfer
• Vendor master: deactivate the vendor in the ERP and the payment system so no new purchase order or payment can be raised without a deliberate reactivation
• Insurance and guarantees: release of performance bonds, parent guarantees and letters of credit
• Surviving obligations: a dated list of what each side still owes (confidentiality, audit cooperation, record retention, indemnities) and who monitors each one

Two things catch programs here. One is the auto-renewal that fires because the subscription lived on a corporate card outside procurement. Another is the open obligation nobody tracks: an audit right that expires in two years, a retention period that ends in seven. Put both on a calendar that belongs to the program, not to a person who may have left by then.

An examiner reading your file two years from now will ask four questions: when did the relationship end, who approved the exit, what happened to the access and the data, and how do you know. The offboarding checklist below is built to answer them, one row per action, with the owner who did it and the evidence that proves it.

The Interagency Guidance expects contracts to provide for "appropriate retention of, and access to, all relevant documentation" for regulatory examination. DORA's register of information under Article 28(3) has to distinguish arrangements that support critical or important functions, which means the entry for an exited vendor needs an end date and a disposition, not a deletion. File the exit evidence where the onboarding evidence lives, under the same vendor record, so the examiner reads one story from intake to exit. Keep it for the longest retention period any applicable rule requires, and write that period on the record.

This is the step where a platform earns its keep. On Certa, every screen, adjudication and disposition is captured with documented rationale, citations and timestamps, immutable and exportable on demand, and the Offboarding stage closes out access, data and obligations on the same record the onboarding stage opened. Your exit file becomes a report you export instead of a reconstruction.