Vendorapp › OpenVMO › Offboarding and exit
Offboarding and exit in OpenVMO.
Every vendor relationship ends. Offboarding makes sure access is removed and your data is returned or deleted, with proof. For critical vendors, exit planning means knowing how you would leave before you have to.
Open standard, CC BY 4.0 · Free, no sign-up · Works with a spreadsheet · Maps to SOC 2, ISO 27001, NIS2, DORA
Why it matters
What this domain is for.
Access that outlives the contract is one of the most common audit findings, and "we asked them to delete it" is not proof that they did. For critical vendors, an untested exit plan is one of the first things a regulator or bank customer asks about.
Offboarding and exit is one of the 11 domains of the OpenVMO framework, an open standard for running vendor management at a startup. Each practice below has a minimum maturity level: you only need the practices at or below the level you are aiming for.
Practices
The 3 EXIT practices.
Offboarding checklist
An offboarding checklist runs whenever a vendor relationship ends: access, single sign-on, API keys and webhooks revoked; data return or deletion requested and confirmed; final invoices settled; assets returned; register updated with the date and reason. Evidence: The completed checklist for each offboarded vendor, with the deletion confirmation.
Exit plans for critical vendors
Tier 1 and critical vendors have an exit plan: the alternative, how data moves, and how long a switch would take. Evidence: A short exit plan per Tier 1 or critical vendor.
Exit plans tested
Exit plans for critical functions are tested or desk-reviewed. Evidence: Test or review records with the date and the result.
A practice counts as in place only when a dated record shows it was performed. A tool that could perform it does not count on its own.
By stage
What good looks like at each level.
| Level | What good looks like |
|---|---|
| Level 1: Foundational | An offboarding checklist used every time, with deletion confirmed in writing. |
| Level 2: Managed | Offboarding evidence included in the audit evidence pack. |
| Level 3: Defined | Exit plans written for Tier 1 and critical vendors. |
| Level 4: Optimised | Exit plans tested or desk-reviewed for critical functions. |
With a spreadsheet
Doing it without any special tool.
- Use the OpenVMO offboarding checklist and save the completed copy against the vendor.
- Record the offboarded date, reason and deletion confirmation in the register row.
- For each Tier 1 vendor, write three lines: the alternative, how the data moves, and how long it would take.
Common mistakes
Where teams usually go wrong.
- Cancelling the subscription but leaving API keys, webhooks or single sign-on access live.
- Asking for deletion and never getting confirmation.
- Writing the exit plan during the outage.
Crosswalk
How this maps to the frameworks you are audited against.
| Framework | Related requirements |
|---|---|
| SOC 2 (Trust Services Criteria) | CC9.2, CC6.2, CC6.5 |
| ISO/IEC 27001:2022 | A.5.20, A.5.22, A.8.10 |
| NIS2 and Implementing Regulation 2024/2690 | CIR 2024/2690 Annex §5.1 |
| DORA | Art. 28(7), Art. 28(8) |
| NIST CSF 2.0 | GV.SC-10 |
The mapping is informative, not legal advice: it points to where each framework deals with the same topic. The full mapping for every practice is on the crosswalk page.
Templates
Templates for this domain.
- Offboarding checklist (Markdown): Every step to close a vendor relationship cleanly, with space for the evidence.
All OpenVMO templates are on the templates page.
Previous domain: Third-party incidents. Next domain: Metrics and reporting.
Run OpenVMO with a spreadsheet, or with a tool.
Every practice can be met with the free templates. If you would rather not maintain the register by hand, Vendorapp implements most of OpenVMO and has a free plan.