RFP template for security tooling

Long RFPs get answered by proposal teams; short ones get answered by engineers. Keep it to four pages and demand specifics.

1. About us (half a page)

State size in people and endpoints, industry, regulatory scope (RBI, SEBI, PCI DSS, DPDP, ISO 27001), primary cloud and identity provider, existing security tools that must integrate, and the team that will run the product with its size and skills.

2. The problem (half a page)

The one-pager from your evaluation plan. Include the three scenarios the product must handle, written as stories: "An employee's laptop is compromised through a phishing link at 18:40 on a Friday; we need to know by 19:00 and contain it without a person on shift."

3. Requirements (one page)

A table with three columns: requirement, must-have or nice-to-have, and a blank column for the vendor's answer of available today / beta / roadmap / not planned. Refuse prose answers. Twenty rows is plenty.

4. Proof of concept

"Each shortlisted vendor will receive the same environment description and the same dataset. The proof of concept is scored by us on the attached scorecard. Vendor staff may observe but not operate."

5. Commercial questions

• Unit of pricing and what counts as a unit.
• Three-year price with renewal uplift written into the order form.
• Overage rules, add-ons most customers buy in year two, shrink terms.
• Professional services required for deployment, priced separately.
• Data residency for India, exit terms, and data return.

6. Support and company

• Support locations, time zones, severity-one SLA, named contact and its cost.
• Last twelve months of incident reports.
• Ownership changes, funding, and layoffs in the last eighteen months.
• Two reference customers of our size and industry that we may call alone.

7. Format and timeline

Answers in the table format provided, maximum twelve pages, PDF plus the table as a spreadsheet. Questions by day 5, responses by day 12, proof-of-concept days 15 to 22, decision by day 30.

Scorecard attachment

Use the five DBSE axes weighted for your context. A common weighting: deployment effort 20%, support quality 20%, features versus promises 25%, pricing transparency 15%, return on investment 20%. Must-haves are gates, not scores.