A security tool purchase usually moves through seven stages: a defined need, a shortlist, a vendor security review, a pilot, legal review, procurement, and signature. Most delays come from running stages in sequence that could overlap, or from missing one until late. Knowing the order lets you start the slow ones early.
The seven stages
1. Need. Someone writes down the problem in a sentence a non-specialist can read. "We cannot tell which of our dependencies are exploitable" works. "We need a platform" does not.
2. Shortlist. Two or three candidates is enough. More than that and the pilot never finishes.
3. Vendor security review. Your own security or risk team asks the vendor about its controls, data handling and subprocessors. This is the stage buyers most often start too late.
4. Pilot. A time boxed trial against your real code or systems, with success criteria agreed first. See the pilot versus proof of value comparison for what to call it and what to promise.
5. Legal review. Master terms, a data processing agreement if personal data is involved, and any security exhibit.
6. Procurement. Vendor onboarding, tax and payment details, approvals against budget, and sometimes a competitive quote requirement.
7. Signature. The order form is signed by someone with authority, and an owner is named for the renewal date.
Which stages can overlap
Legal and security review can start the day a vendor is shortlisted. Send your standard questions and ask for the vendor's standard contract documents while the pilot is still being scoped. Procurement onboarding can also start early, because it is mostly paperwork that does not depend on the pilot result.
The pilot is the one stage that should not be compressed. A rushed pilot produces a decision based on a demo.
Where deals stall
- Nobody owns the timeline. Name one person who chases every other stage.
- Legal sees the contract for the first time after the pilot. Redlines then land on a deal everyone already assumes is done.
- The data question is discovered late. If the tool will see source code, customer records or personal data, say so in stage one.
- Approval thresholds are unknown. Ask procurement early which spend level triggers which sign-off. The thresholds differ by company and you should not guess.
A simple tracking table
For each candidate, keep one line per stage with an owner, a date started and a status. A shared sheet is enough. If a stage has no owner, that is the stage that will stall.
How this applies to Safeguard evaluations
If you are assessing Safeguard, you can start with the free scan at gold.safeguard.sh/scan to see output on a public repository before any legal or procurement work begins. That gives the security reviewers something concrete to look at while the paperwork starts.
Try it yourself
Click through the vulnerability management flow to see the kind of output a pilot should produce.
Click through it at your own pace, or open it full screen.
Quick check
Which stage should start first?
The need statement, then immediately the security review and legal intake in parallel with scoping the pilot.
How many vendors should reach the pilot?
Two or three. More makes it hard to give each a fair test with real people's time.
Last reviewed: 19 October 2026.
