Ask vendors, before you sign, exactly what you can take with you when you leave: which data, in which open formats, how fast, with what history, and how deletion is confirmed. Put the answers in the contract. A security tool you cannot leave becomes a risk of its own.
Why ask about exit at the start
Exit questions feel pessimistic during a courtship. They are cheaper before signature than after. They also reveal how a vendor thinks about customer control. A vendor that answers plainly and in detail is usually easier to work with on everything else.
What you may want to take
- Findings and their history, including status changes and who changed them.
- The inventory of components, repos and images.
- Suppressions, exceptions and the reasons recorded for them.
- Policies, gates and rule definitions.
- Reports and audit evidence generated for compliance.
- Integration settings, so you can rebuild connections elsewhere.
Ask which of these can be exported today, not which could be exported "on request."
Ten questions to adapt
- Which data types can we export, and which cannot be exported at all?
- In which open or documented formats? Name the formats and versions.
- Is export available through the user interface, the API, or both?
- Does the export include history and the reasons attached to suppressions, or only the current state?
- Is there a size or rate limit on export, and does it apply during a termination period?
- How long after termination do we keep access to export our data?
- How and when is our data deleted after that period, and what written confirmation do you provide?
- Are backups included in deletion, and on what schedule do they expire?
- Will you support a transition, for example by keeping scanning active during a parallel run, and under what terms?
- If you are acquired or discontinue the product, what notice period and export support do we get?
How to compare answers
| Answer type | What it tells you |
|---|---|
| "Yes, via API, formats listed, sample attached" | Mature and confident |
| "Yes, on request" | Probably a manual process, ask how long it takes |
| "Findings only" | History and suppressions may be lost, which breaks audit continuity |
| "Proprietary format" | Lock-in risk, ask for a converter or schema |
Test it, do not just read it
In the hands-on trial, export a dataset and look at it. Check that the file opens, that counts match the dashboard, and that suppression reasons survive. Ten minutes of testing replaces a page of promises.
Also check whether the export can be re-imported into any other tool you know about. Portability that only works back into the same product is a weaker guarantee than it sounds.
A worked example: an export test in the trial
During a two week trial, a team plans a short export test and writes the result in a table.
| Check | How to test | Result to record |
|---|---|---|
| Findings export includes status history | Mark three findings as fixed, ignored and accepted, export, look for all three states and timestamps | Present or missing |
| Suppression reasons survive | Add a reason to an exception, export, search for the text | Present or missing |
| Counts match | Compare finding counts in the interface and in the export | Equal or differences explained |
| Inventory export includes ownership | Check that team or owner fields appear | Present or missing |
| Format is open and documented | Open the file in two unrelated tools | Opens or fails |
| Policy definitions exportable | Export rules and compare with what is configured | Present or missing |
| API limits | Request a full export through the API and note any throttling | Time taken |
The whole test takes under an hour. If findings export without history or reasons, you now know that leaving would cost you your audit trail, and you can decide whether to negotiate, accept, or look elsewhere.
What to put in the contract
A good answer in a response is not enough. Ask that the agreement states:
- The data types you can export and the formats.
- A minimum period after termination during which export remains available.
- Deletion timing and written confirmation.
- Notice if the vendor is acquired or the product is retired.
- Reasonable help with a transition, if you need it, with the terms stated.
Have your legal team review the wording. This post is a checklist of topics, not legal advice.
Plan your own exit before you need it
Even with good terms, leaving takes work. Write a short exit plan in the first month: what you would export, where it would go, who would do it and how long you expect it to take. Review it at each renewal. The act of writing it often shows you dependencies that you can reduce, such as custom scripts that rely on a proprietary field.
Beware of soft lock-in
Hard lock-in is a missing export. Soft lock-in is subtler. Examples include policies written in a proprietary language, workflows that live only in the vendor's interface, and reports whose logic you cannot reproduce. Ask how much of your configuration can be expressed in a portable form, and weigh that in scoring.
Where Safeguard fits
For reference, Safeguard's GA capabilities include SBOM and dependency scanning, so SBOM export is a natural item to test, along with any other data you care about. Run the free scan at https://gold.safeguard.sh/scan and judge the output against your own requirements, as you would for any candidate.
Try it yourself
Click through it at your own pace, or open it full screen. See how an inventory is presented, then ask each vendor to show the same data exported in an open format.
Quick check
When should exit terms be negotiated?
Before signing. After signature you have little negotiating room.
Is a documented API enough for export?
Only if it covers history and suppressions, not just current findings. Test it with real data.
How soon after signing should we write an exit plan?
In the first month, while the setup details are fresh. Review it at every renewal and after any major change in how you use the tool.
Last reviewed: 19 October 2026.
