The Situation
You sent an RFP (request for proposal) to five security vendors. You got back five long documents. Every vendor answered "Yes" or "Fully supported" to almost every requirement. Pricing came in five different formats. Now you have to pick one, and the RFP hasn't narrowed anything.
That isn't the vendors' fault. Most RFPs are built in a way that invites that kind of answer. A few changes fix most of it.
1. Start With the Problem, Not a Feature List
Open with a short description of your situation: your size, your environment, what you have today, and the specific problems you need solved. For example:
"We have 1,200 employees on Microsoft 365, about 1,500 endpoints and 60 servers across two data centers and Azure. We have no after-hours security monitoring. Our goal is 24/7 detection and response with containment in under 30 minutes."
Vendors write better answers when they understand the problem. You also make it harder for them to answer with boilerplate.
2. Separate Must-Haves From Nice-to-Haves
Label every requirement:
- Must have. If they can't do it, they're out. Keep this list short.
- Should have. Important, and it affects the score.
- Nice to have. Small tiebreakers.
If everything is a must-have, nothing is. A list of 200 "required" features guarantees 200 "yes" answers.
3. Ask "How," Not "Do You"
"Do you support ransomware rollback?" gets a yes from everyone. These get real answers:
- "Describe exactly how your product would respond to ransomware on a Windows file server, step by step, including what happens automatically and what needs a person."
- "Walk us through what your analyst does in the first 30 minutes after a critical alert at 2 a.m. on a Sunday."
- "Describe a recent customer incident similar to our environment, how you detected it and how long containment took."
Scenario questions are the most useful part of a security RFP. Put three to five of them at the center of yours.
4. Require a Standard Response Format
Give vendors a template and require them to use it:
- A response table with columns for Requirement, Supported (Yes / Partial / Roadmap / No), How and Included or extra cost.
- A word limit on each answer.
- A rule that "Roadmap" items must include a target date.
This one change makes side-by-side comparison possible.
5. Make Pricing Comparable
Pricing is where RFP responses are hardest to compare. Provide your own pricing sheet:
| Line item | Year 1 | Year 2 | Year 3 |
|---|---|---|---|
| Licenses (state the unit: per user, device, etc.) | |||
| Required add-ons | |||
| Implementation and onboarding | |||
| Training | |||
| Premium support | |||
| Expected annual increase | |||
| Total |
Give every vendor the same counts, such as 1,500 endpoints and 1,200 users, so the totals line up. Ask them to list anything excluded.
6. Publish the Scoring Up Front
Decide how you'll score before responses arrive, and share the weights with vendors. A simple split works:
- Technical fit and scenario answers: 40%
- Service, support and references: 20%
- Total three-year cost: 25%
- Contract terms and vendor stability: 15%
Have at least two people score independently, then compare.
7. Keep the Timeline Realistic and Short
A focused security RFP doesn't need months:
- Week 1: Issue the RFP.
- Week 2: Vendor questions due. Send one set of answers to all vendors.
- Week 4: Responses due.
- Week 5: Score and shortlist two finalists.
- Weeks 6–9: Live demos on your scenarios and a proof of concept with the finalists.
- Week 10: Negotiate and decide.
What to Do Next
Before you write a single requirement, write the one-paragraph problem statement and your three to five scenarios. If your team can't agree on those, the RFP won't fix it.
Buying or renewing soon? Stackcurve advisors help IT leaders compare vendors, benchmark pricing and negotiate contracts at no cost to you. Talk to an advisor → or get your free Cyber-Ready Score →
Stackcurve is independent. No vendor pays for placement or editorial influence on this blog.