Before you sign, agree what the vendor will delete when you leave, how quickly, what you can export first, and how you will confirm both. On exit day, revoke the integration's access yourself, rotate anything it could read, and ask for written confirmation of deletion.
Why plan the exit up front
Most tool evaluations focus on getting in. Leaving is when your bargaining position is weakest and the questions are least rehearsed. The data at stake is your source code, your findings, your configuration, and possibly logs of what developers asked the tool.
Where the data includes personal information, the GDPR sets a baseline for processors. Article 28(3)(g) says that at the controller's choice, the processor deletes or returns all personal data after the services end, and deletes existing copies unless the law requires storage. Even if the regulation does not apply to you, it is a reasonable standard to ask for.
What to settle in the contract
| Topic | Ask for |
|---|---|
| Deletion scope | Code, derived data, findings, logs, caches, backups |
| Deletion timeline | A number of days, and a different one for backups |
| Export | Findings, configuration and history in a documented format |
| Confirmation | Written statement from the vendor on completion |
| Sub-processors | Deletion flowed down to them |
| Model training | Confirmation that your data was not used to train or tune models |
| Notice period | How long access remains after termination |
Backups are the usual gap. A vendor may delete live data in days but keep backups for months. That can be acceptable, if stated and if the data in backups stays protected and unused.
The exit checklist
- Export first. Pull findings, dismissals with reasons, configuration and any evidence you need for audits. After deletion, you cannot reconstruct the record.
- Remove the integration. Uninstall the app from your source host, or revoke the token. Do not rely on the vendor to disconnect from their side.
- Rotate secrets the tool could read. If it had read access to repositories or CI variables, treat any secret it could see as exposed to a third party and rotate on a schedule that matches your risk.
- Remove IDE extensions and CI steps so nothing keeps sending code.
- Send a deletion request citing the contract, with a date.
- Get written confirmation, and file it with the vendor record.
- Update your records: vendor register, data flow diagram, sub-processor lists you share with customers.
- Check for leftovers: webhooks, deploy keys, service accounts, and scheduled jobs.
Test the exit before you commit
During the trial, ask the vendor to walk through a deletion of your trial data, and to show the export. You are checking that the process exists and works. If it needs weeks of tickets for a trial, expect worse later.
Keep the evidence
Auditors and customers sometimes ask what happened to data held by a former supplier. A short record of the export date, the deletion request, and the confirmation answers that cleanly. It also fits into an AI-related review of vendors.
Quick check
Is cancelling the subscription the same as deletion?
No. Cancelling ends billing. Deletion needs a request, a timeline, and confirmation under the contract.
Do I need to rotate secrets if the tool says it never stored code?
If it could read them, rotating is cheap insurance. Judge by what the integration could access, not by what it says it kept.
Safeguard includes compliance and evidence automation, which can help you keep vendor and control records current. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
