A focused security tool RFP can run in about six weeks: one for requirements, one for vendor responses, one for scoring and demos, two for a hands-on test, and one for decision and negotiation. Timelines stretch when requirements are unclear or stakeholders join late, so fix both early.
The schedule
| Week | Focus | Deliverable | Owner |
|---|---|---|---|
| 1 | Requirements and long list | Must, should, could list; eight to twelve candidates | Security lead |
| 2 | RFI and cut | Written answers; shortlist of three or four | Security and procurement |
| 3 | RFP and Q and A | Responses received, questions answered fairly | Procurement |
| 4 | Scoring and demos | Panel scores; demo on your script | Panel |
| 5 | Hands-on test, part one | Setup done on agreed repos for each vendor | Engineering |
| 6 | Hands-on test, part two and decision | Scorecard, memo, negotiation start | Security lead |
This is a plan, not a measurement. Adjust it to your calendar and your approval process.
What to do in each week
Week 1. Write requirements from the environment section and the tool inventory. Freeze them. Build the long list from five sources and apply deal breakers.
Week 2. Send a short RFI. Cut on knockout questions. Tell the cut vendors politely and briefly.
Week 3. Send the RFP with the response template, evaluation factors and weights. Open a question window and share every answer with all vendors.
Week 4. Panelists score alone, then calibrate. Run demos using your script, on your data if possible.
Weeks 5 and 6. Run the same test on the same repos for each shortlisted vendor, with the same success criteria written beforehand. Hold reference calls in parallel. End with a scorecard and a one page decision memo.
Where schedules slip
- Requirements still moving in week three. Freeze them, and log any change with a reason.
- A stakeholder appears late. Identify legal, privacy, procurement and the daily users in week one.
- Vendors take longer to respond. Set a hard date and say you will score what arrives.
- Test environment access. Get tokens and permissions approved before week five. Use least privilege and review them with your security team.
- Calendar holidays. Check them before you commit to dates.
Speeding up safely
You can compress the schedule by running the RFI and requirements work in parallel, or by limiting the hands-on test to one team. Do not compress the scoring calibration or the test. Those two steps are where you find out what is true.
A worked example: a calendar with names
Here is how one team might fill in the table, with owners and dates relative to a start day.
| Day | Event | Owner | Output |
|---|---|---|---|
| 1 | Kickoff, panel named | Security lead | Panel list, roles |
| 3 | Requirements frozen | Security lead, engineering | Must, should, could |
| 5 | Long list complete | Security analyst | Ten names with sources |
| 8 | RFI sent | Procurement | RFI to ten vendors |
| 12 | RFI replies due, cut | Security and procurement | Shortlist of four |
| 15 | RFP issued | Procurement | RFP, template, weights |
| 18 | Question window closes | Procurement | Q and A shared with all |
| 22 | Responses due | Vendors | Four responses |
| 25 | Panel scoring, calibration | Panel | Scores, follow-ups |
| 26 to 27 | Demos on your script | Panel | Demo notes |
| 29 to 40 | Hands-on test | Engineering | Test results |
| 38 | Reference calls | Security lead | Notes |
| 41 | Scorecard and memo | Security lead | Decision memo |
| 42 | Decision and negotiation start | Budget owner | Selected vendor, runner-up |
The dates are an example. If your legal review or budget approval takes longer, move the later rows and keep the order.
Items that run in parallel
Several tasks can overlap with the main flow without adding calendar time:
- Legal review of the standard terms while vendors write responses.
- A security review of the vendor's own documentation, using the questions you plan to ask.
- Preparation of the test repositories and access tokens before the test begins.
- Drafting of the decision memo template during the response period.
What to freeze and when
| Item | Freeze by |
|---|---|
| Requirements | End of week 1 |
| Evaluation weights | Before the RFP is sent |
| Test criteria | Before the trial begins |
| Scoring scale | Before responses arrive |
Freezing prevents the common failure of shifting goalposts mid process.
What to do if the schedule slips
- Say so, in writing, to vendors and stakeholders, with a new date.
- Check whether the slip is on a critical path item or a parallel one.
- Do not cut the test or the calibration to recover time. Cut the optional items, such as extra demos.
- Re-read your freeze list. If requirements moved, log why.
After the decision
Plan the first ninety days as carefully as the selection. Choose the first team, set coverage and triage targets, and schedule the review against your memo. A decision without an adoption plan is only half a project.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings move from discovery to resolution, then decide which of those steps your week five test must cover.
Quick check
Can the schedule be shorter than six weeks?
Yes for a narrow tool and a small team, but keep the scoring and the hands-on test.
When should legal be involved?
In week one, so contract concerns shape the RFP instead of surprising you at the end.
When should you start the hands-on test?
Pick a period without a major release or freeze on the pilot team. Check holidays and on-call calendars first so engineers have real time for the test.
When you build the shortlist, Safeguard, with GA capabilities such as dependency scanning, SBOMs, reachability analysis and policies and gates, can take part in the week five test. The free scan at https://gold.safeguard.sh/scan is a quick preview.
Last reviewed: 19 October 2026.
