On the kickoff call of a security tool trial, ask ten things: what the trial includes, what is limited, where your data goes, who supports you, how long scans take, which integrations work, what is on the roadmap versus shipped, how deletion works, how results are exported and what happens at the end.
The ten questions
1. What is included in the trial, exactly? Ask whether every feature you plan to test is switched on. Trial tiers sometimes hide the capability you came to evaluate.
2. What limits apply? Repository count, scan frequency, users, API calls, retention. Write each limit down. A limit you discover on day twelve costs you a week.
3. Where does my code or metadata go? Ask which parts of your code, if any, leave your environment, where it is processed and who can see it. Ask the same of SBOMs and findings.
4. Who do I contact when something breaks? You want a named technical contact, response expectations in writing and an escalation path. Open a small test ticket in week one to see how it goes.
5. How long does a typical scan take on a repository like mine? Give them your largest repository size and build type. Compare their answer with what you measure.
6. Which integrations are generally available today? Separate "shipped and supported" from "in beta" and "planned". Your trial should only depend on the first group. Ask for the label on each integration you need.
7. What is on the roadmap that I might be counting on? If a demo showed something you want, ask whether it is available in your account right now. If not, do not score it.
8. How do I delete my data, and how will I know it is gone? Agree on the deletion method and a confirmation step before you upload anything. See what to do with your data when a trial ends.
9. Can I export my results in an open format? Ask for the formats available, such as CSV, JSON or standard SBOM and advisory formats. An export you can read without the tool protects you if you walk away.
10. What happens on the last day? Does the account lock, convert to a paid plan automatically or stay read only? Is there a grace period? Is any commitment created by continuing to use it?
Record the answers
Put the ten answers in a shared document with the date and the name of the person who gave them. When the final decision arrives, you will want to check that what you were told matches what you got.
| Question area | Answer | Who said it | Date |
|---|---|---|---|
| Scope | |||
| Limits | |||
| Data handling | |||
| Support | |||
| Scan time | |||
| Integrations | |||
| Roadmap items | |||
| Deletion | |||
| Export | |||
| End of trial |
What not to do on the call
- Do not let the call become a product tour. Bring the list.
- Do not accept "we will check and get back to you" without a date.
- Do not share production credentials. Use scoped, revocable ones.
- Do not agree to a long trial just because it is free. See how long a trial should last.
When your own team is the vendor
If you are evaluating an internal tool or an open source project, the same questions still apply. Replace "vendor" with "maintainer" and ask about support channels, release cadence and data flow.
For reference, Safeguard publishes which surfaces are available on its download page, and you can start with a free scan to see output before any call.
Try it yourself
Open the demo and see how a pull request gate behaves. It is a good example of a capability you should ask about on the call: what is blocked, what is warned, and who can override.
Click through it at your own pace, or open it full screen.
Quick check
What is the single most useful kickoff question?
Ask what limits apply to the trial. Hidden limits on repositories, scans or retention are the most common cause of a misleading result.
Should I ask about the roadmap?
Yes, so you can exclude it. Only score what is shipped and switched on in your trial account.
Last reviewed: 19 October 2026.
