When you leave an SCA vendor, you should be able to export your inventories and decisions in open formats, and the vendor should delete your data on a stated schedule. Ask for both in writing before you sign. If the answer is vague, assume that history will be hard to move and that deletion will not be verifiable.
What you will want to take with you
| Data | Why it matters | Format to ask for |
|---|---|---|
| Component inventories per project or release | Answers "did we ship X" later | CycloneDX or SPDX |
| Findings and their status | Shows what was open and fixed | CSV or JSON |
| Dismissals and exceptions with reasons | The records an auditor samples | JSON with timestamps and user |
| Policy definitions | Lets you recreate rules elsewhere | Readable export or API |
| Audit logs | Shows who changed what | CSV or JSON |
CycloneDX and SPDX are both widely used SBOM formats, and the OSV schema is a common way to describe vulnerabilities, so a vendor that speaks them is easier to leave.
Questions for the contract conversation
- What can be exported through the user interface, and what needs a support request?
- Is the API available on every plan, and is there a rate limit that would block a full export?
- How long after termination can we still export?
- When is our data deleted, and will you confirm deletion in writing?
- Are backups included in deletion, and on what schedule?
- Who can access our data in the meantime, and is it used to improve models or benchmarks?
This is a procurement checklist, not legal advice. Have counsel review the exit and data terms.
Test the export before you buy
Do not wait until you leave. In your trial, export an inventory, a findings list, and a dismissal record. Then try to load the inventory into a different tool or a simple script. If the file is incomplete or hard to read, you have found your lock-in.
Keep your own copy
Even with a good export, schedule a periodic one. A monthly copy of release inventories and decision records to storage you control means a vendor change never leaves a gap. Name an owner for the job and note it in your vulnerability management procedure.
Plan the move itself
If you do switch, run both tools in parallel for at least one release cycle. Compare inventories and findings, resolve differences, and only then retire the old one. Keep the old exports labeled with the date and tool version, since finding identifiers will differ.
A worked example: an exit plan on paper
A mid sized company has used a vendor for three years and wants to switch. Before giving notice, it writes an exit plan.
Inventory of what exists: about 150 repositories, with stored component inventories for each release, 4,000 closed findings, 600 dismissals with reasons, 30 policy rules, and two years of audit logs.
What the contract says: export is available through the API during the term and for 30 days after termination, and the vendor confirms deletion in writing within 60 days. The team confirms these figures are written in its own agreement and does not rely on assumptions.
Plan: export everything in month one of a three month overlap. Load inventories into the new tool and compare. Re-create policies. Keep dismissal records and audit logs in the company's own archive. Confirm deletion before the final invoice.
The point is not the numbers, which are illustrative. The point is that every item has an owner, a date, and a format.
Step by step: rehearse the exit during the trial
- Export an inventory for one project in CycloneDX or SPDX.
- Validate the file with a standard validator and open it in a generic viewer.
- Export findings with identifiers, status, first seen, and last seen.
- Export a dismissal with its reason, user, and timestamp.
- Export the policy rules and check that you could rewrite them elsewhere.
- Pull audit log entries for a test action and confirm they include user and time.
- Delete the trial project and ask the vendor how and when the data is erased.
- Write down anything that could not be exported, and weigh it.
Sticky points to look for
- Findings tied to vendor specific identifiers with no mapping to public ones. Prefer tools that keep public identifiers such as CVE and GHSA numbers and list aliases.
- Dismissal reasons stored as free text only, with no user or time.
- Policy rules that can only be configured through the interface, with no export.
- API limits that make a full export slow.
- History that is truncated after a period you were not told about.
What leaving does to your compliance evidence
If an auditor will ask about monitoring during the period you used the old tool, you need evidence from that period. Keep exports of inventories, decision records, and logs, with dates, in an archive you control. Label each with the tool name and version, since a later reader will not remember.
After the move
Run both tools in parallel for at least one release cycle if budget allows. Compare inventories and findings. Resolve differences, and decide which tool's records are authoritative for which dates. Then close the old account, revoke tokens and integrations, and ask for deletion confirmation.
A reminder on terms
Contract and data terms are a legal topic. This article is a procurement checklist. Have counsel review the agreement, and make sure the exit and deletion terms you care about appear in writing.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at what the tool records over time, and ask which of those records you would need to carry with you.
Quick check
Is a CSV of findings enough to leave?
It is a start. You also want inventories and decision records with timestamps and users, or you lose the history behind each finding.
How often should I export?
Monthly is a reasonable default for most teams. Choose a cadence that matches how much history you could afford to lose.
Who should own the export and archive process?
Assign a named owner in the security or engineering operations team, put the schedule in the vulnerability management procedure, and check it each quarter.
Last reviewed: 19 October 2026.
