Article Oyoon Altaqnya security team
How to write a security RFP that gets comparable answers
Seven sections that turn a technology tender into proposals you can actually compare — and a scoring approach that rewards fit, not the longest feature list.
Many security tenders fail before a single proposal arrives. The request asks for “a SIEM solution” or “a firewall upgrade” with a long list of features copied from a vendor datasheet. Every bidder answers “compliant” to every line. The evaluation committee is left comparing prices for products that will behave very differently once installed.
A good request for proposal (RFP) does the opposite: it describes your problem precisely and asks bidders to show how they would solve it. The sections below work for security products, integration projects and assessment services alike.
1. Start with the outcome, not the product
Write one or two paragraphs on why you are buying. For example: “We need to detect and investigate suspicious activity on our core banking servers and domain controllers, and keep the evidence our auditors ask for.” This tells bidders what success looks like and lets them propose an approach you may not have considered.
Avoid naming a product category too early. “We need an XDR” invites product pitches; “we need to detect ransomware activity on 600 endpoints and 40 servers” invites solutions.
2. Describe your current environment
Bidders cannot size or price accurately without facts. Include, at a level of detail that is safe to share under a non-disclosure agreement:
- Number of users, endpoints, servers and sites.
- Main platforms: operating systems, directory service, email, virtualization, cloud tenants.
- Existing security tools that must integrate or be replaced.
- Network layout at a high level: data centers, branches, internet links.
- Constraints such as data that must stay in Libya, change windows or restricted remote access.
Vague environments produce vague proposals, and the cost of that vagueness appears later as change requests.
3. Separate mandatory requirements from preferences
Mark each requirement as mandatory (a proposal that does not meet it is rejected) or desirable (scored). Keep the mandatory list short — ten real requirements are better than a hundred copied ones. Typical mandatory items are integration with systems you cannot change, regulatory or data-location constraints, and support availability in Libya.
For each mandatory item, ask how it is met, not just whether. “Compliant” is not an answer; “Supported natively through the vendor’s Active Directory connector, configured during phase 2” is.
4. Ask bidders to walk through your scenarios
Scenarios reveal more than feature tables. Give three to five realistic situations and ask each bidder to describe, step by step, what their solution and team would do. For a detection platform:
- A user’s account logs in from two countries within an hour.
- A server starts encrypting files on a network share.
- An auditor asks for all administrator activity on a payment system over the last six months.
Where possible, turn the most important scenarios into a short proof of concept (PoC) with clear pass/fail criteria agreed in advance.
5. Specify the delivery, not just the technology
Most security projects succeed or fail on delivery. Ask for:
- The proposed team, their roles and relevant certifications — and whether they are the people who will actually do the work.
- A project plan with phases, milestones and what you must provide at each stage.
- Deliverables: high-level and low-level designs, as-built documentation, test results and handover sessions.
- Knowledge transfer: how your staff will be able to operate and tune the system after handover.
- Support after go-live: what is included, for how long, and how issues are raised.
6. Make pricing comparable
Provide a pricing template and require every bidder to use it. Separate one-time costs (licenses, hardware, implementation, training) from recurring costs (subscriptions, support renewals) and ask for a total over three or five years. Ask bidders to state what would increase the price — more endpoints, more log volume, additional sites — so you can compare growth, not just year one.
7. Publish how you will score
Tell bidders how proposals will be evaluated. A simple, published model encourages focused answers:
| Criterion | Example weight |
|---|---|
| Fit to outcomes and scenarios | 35% |
| Delivery approach and team | 25% |
| Integration and mandatory requirements | 15% |
| Total cost over the contract period | 25% |
Agree the weights inside your organization before the RFP is issued, and score each proposal independently before the committee meets.
Common mistakes to avoid
- Copying a vendor’s datasheet into the requirements. It favours one product and hides what you actually need.
- Asking for everything. Long lists of low-value features dilute the answers that matter.
- Too little time to respond. Rushed proposals are generic proposals.
- No clarification round. A short written question-and-answer period, shared with all bidders, prevents misunderstandings and keeps the process fair.
How we can help
Our IT advisory team helps organizations define requirements, write RFPs and evaluate proposals, and our solution architecture service produces the designs that make proposals comparable. If you are buying testing services, our checklist on what a penetration test report should contain will help you judge the samples bidders send.