1. Define scope and outcomes before you write a single question
Most weak security RFPs fail at this step. The buyer lists tools they think they want instead of describing the problem, and every vendor answers "yes" to everything.
Start with an internal scoping session that includes IT, security, legal, finance, and whoever owns incident response. Agree on:
- Environment: number of endpoints, servers, cloud accounts, SaaS apps, locations, and users. Vendors price on these, so estimates will be wrong if you skip this.
- Service model: fully managed (MSSP runs detection and response), co-managed (shared responsibility with your team), or product only.
- Coverage hours: 24/7/365 monitoring or business hours with on-call escalation.
- Response authority: can the provider isolate a host or disable an account without asking, or must they call first?
- Compliance drivers: frameworks or regulations you must satisfy, such as SOC 2, ISO 27001, HIPAA, PCI DSS, or cyber insurance requirements.
- Budget range and contract length you can actually approve.
Write the outcomes in plain terms. Example: "Detect and contain credential compromise and ransomware activity across all endpoints and Microsoft 365 within one hour of the first alert, 24/7."
2. Write requirements that force specific answers
Yes/no questions produce yes answers. Ask vendors to describe, show, or quantify instead.
Group your questions into sections:
- Service delivery: SOC location and staffing model, analyst tiers, escalation path, named contacts.
- Detection and response: data sources ingested, how detections are built and tuned, what actions they take on your behalf.
- Technology: SIEM, EDR, and SOAR platforms, whether you must buy their tools or they can use yours, and who owns the licenses.
- Reporting: what you receive weekly, monthly, and after an incident.
- Vendor security: their own certifications, recent audit reports, subprocessors, and how they protect access to your environment.
- Commercials: pricing model, what drives cost increases, onboarding fees.
Example wording that works better than a checkbox:
Describe the last time your SOC contained a live ransomware incident for a client of similar size. Include time from first alert to containment, actions taken, and what the client was asked to do.
List every data source included in the base price. List every data source that costs extra, with the pricing unit.
Keep the questionnaire focused. A long list of generic questions buries the ones that separate good providers from average ones.
3. Run the process with a fixed timeline and clean communication
Invite a shortlist rather than an open field. Four to six qualified vendors is a common, manageable number. Screen them first on size fit, coverage hours, and any hard compliance requirements.
A typical timeline, which you should adjust to your approval cycle:
- Week 0: send NDA and intent-to-bid request.
- Week 1: issue RFP with environment details and scoring criteria summary.
- Week 2: written questions due. Answer all questions in one document shared with every bidder.
- Week 4: responses due.
- Weeks 5 to 6: scoring and shortlist to two or three finalists.
- Weeks 7 to 9: demos, proof of concept, reference calls.
- Weeks 10 to 12: negotiation and contract.
Rules to state in the RFP:
- One point of contact on your side. Vendors who go around it can be disqualified.
- A required pricing template so quotes are comparable.
- Responses valid for a set period, such as 90 days.
Share enough detail about your environment to get accurate pricing, but keep sensitive specifics such as network diagrams or known vulnerabilities for finalists under NDA.
4. Score responses against weights set in advance
Agree on the scoring model before any response arrives. Otherwise the team drifts toward the best presentation or the lowest price.
An example weighting for a managed detection and response RFP:
| Category | Weight |
|---|---|
| Detection and response capability | 30% |
| Service delivery and staffing | 20% |
| Integration with your environment | 15% |
| Vendor security and compliance | 15% |
| Total cost over contract term | 15% |
| Contract terms and flexibility | 5% |
Use a 0 to 5 scale with written definitions, for example: 0 = not addressed, 3 = meets requirement, 5 = exceeds with evidence. Have at least three evaluators score independently, then meet to discuss large gaps.
Compare cost as total cost of ownership over the full term: onboarding fees, platform licenses, per-endpoint or per-GB charges, incident response retainer, and projected growth. A low base price with expensive overage units often costs more by year two.
5. Test finalists before you commit
Written answers show what a vendor says. Testing shows what they do.
Options, from lightest to heaviest:
- Scenario demo: give each finalist the same scenario, such as a phished user whose mailbox forwards to an external address. Ask them to walk through detection, triage, and response in their real console.
- Tabletop exercise: a 60 to 90 minute session with their analysts and your team working a mock incident. Watch how they communicate under pressure.
- Proof of concept: deploy on a limited set of endpoints or one cloud tenant for two to four weeks, which is a common range. Define success criteria in writing first: alert quality, false positive volume, response time, report usefulness.
For reference calls, ask for customers of similar size and industry, and ask specific questions: "How long did onboarding actually take?" and "Tell me about a time they missed something."
6. Negotiate the contract terms that matter
The security value of the deal lives in the contract. Focus on these areas:
Service levels with remedies. Define time to acknowledge, time to escalate, and time to contain by severity. Tie misses to service credits. Example clause:
Provider shall notify Customer of any Severity 1 incident within 15 minutes of detection, 24/7/365. Failure to meet this target in any calendar month entitles Customer to a service credit of 10% of that month's fees.
The specific minutes and percentage are negotiable; the point is that they are written down.
Data handling. Where your logs are stored, retention period, who can access them, encryption, and a list of subprocessors with notice of changes.
Breach notification. A fixed window for the provider to notify you if their own systems are compromised, often 24 to 72 hours.
Liability and insurance. Security vendors often cap liability at 12 months of fees. Push for a higher cap or a separate super-cap for data breaches caused by their negligence, and require proof of cyber liability coverage.
Exit and transition. Return of all data and detection content in a usable format, transition assistance for a set period, and removal of their agents and access. Avoid auto-renewal terms without a clear notice window.
Price protection. Cap annual increases and fix unit prices for growth during the term.
Let pingpong run it for you
pingpong drafts the RFP, finds and invites vendors, collects proposals through a private portal, scores them with five AI models and flags the gotchas above. It drafts every negotiation message for your approval, then keeps watching the market so you renegotiate before renewal. $100 for the first month, then $799 a month.
Common questions
What is the difference between an MSSP and an MDR provider in an RFP?
An MSSP typically manages a broad set of security tools and monitoring, sometimes including firewalls and compliance reporting. An MDR provider focuses on threat detection and active response, usually on endpoints and cloud. Write your RFP around the outcomes and services you need, and let vendors of either type show how they meet them.
Should we require vendors to use our existing security tools?
It depends on how much you have invested and how well those tools perform. Asking vendors to price both options, using your stack and using theirs, gives you a clear comparison. Make sure the contract states who owns the licenses and configurations if you leave.
How many references should we check for a cybersecurity vendor?
Two or three references per finalist is common and usually enough. Ask for customers similar to you in size and industry, and at least one who has been with the vendor through a real incident. Prepare the same questions for every reference so answers are comparable.