Vulnerability management RFPs often ask how many CVEs a scanner detects, every bidder claims industry-leading coverage, and the selection ends up rewarding the tool that produces the longest list rather than the one that tells you what to fix first. This template is a ready-to-issue request for proposal for a vulnerability management platform, with numbered requirements that can be checked in a proof of concept and scored. It covers asset coverage, scanning methods, risk-based prioritisation using exploitation evidence such as the CISA Known Exploited Vulnerabilities (KEV) catalogue and the Exploit Prediction Scoring System (EPSS), remediation workflow, reporting, platform security, services and pricing. It is vendor-neutral and written for vulnerability management leads, infrastructure owners and procurement. For how the market is shaped, read the Vulnerability Management Buyer's Guide; this page is the procurement document.
How to use this template
- Replace text in square brackets, such as [Organisation], [number of assets] and [ticketing system], with your own details. Delete requirements that do not apply rather than leaving them unscored.
- Each requirement has an ID (for example VM-PR-02) and a type: M mandatory (pass or fail; a fail eliminates the bid), S scored (0 to 5, weighted) or I informational. Keep M items few.
- Weights, volumes and timings in brackets are illustrative. Set them from your own risk, scale and remediation SLAs before issue, and do not change them after responses arrive.
- Issue sections 1 to 8 to bidders. The Implementation guidance section is for your panel only.
- Ask for responses in a spreadsheet with one row per requirement ID and a documentation link for each "available now" answer.
1. Purpose and scope
[Organisation] invites proposals for a vulnerability management platform and associated services. The platform must find vulnerabilities and misconfigurations across the estate, decide which matter most using exploitation evidence and business context, drive remediation to named owners, and prove that it happened.
- In scope: asset discovery and inventory reconciliation; network, authenticated and agent-based scanning of servers and endpoints; cloud workloads and container images; web applications [if in scope]; risk-based prioritisation; remediation workflow and exceptions; reporting and metrics.
- Out of scope: [patch deployment, which remains with the existing endpoint management tool]; [penetration testing services]; [source code analysis, covered by application security tooling].
- Contract term: [three] years with an option to extend by [two] years.
- Drivers: [backlog of findings with no owner]; [audit findings on remediation SLAs]; [regulatory obligations such as PCI DSS or NIS2]; [blind spots in cloud and remote endpoints]; [exploited vulnerabilities patched late].
2. Organisation background and current state
| Item | [Organisation] value |
|---|---|
| Servers (on-premises, by operating system) | [number Windows], [number Linux], [other] |
| End-user devices | [number], of which [number] remote or rarely on the corporate network |
| Cloud | [providers, number of accounts or subscriptions, virtual machines, container clusters, serverless functions] |
| Network and security appliances | [number and main types] |
| Internet-facing assets and web applications | [number of domains, IP ranges, applications] |
| OT or medical devices | [present or not; scanning restrictions] |
| Asset sources | [CMDB], [directory], [endpoint management], [cloud inventories] |
| Current tooling and process | [existing scanners, spreadsheets, ticketing system, remediation SLAs] |
| Hosting and residency | [SaaS acceptable in named regions / on-premises scanners required in segments] |
3. Instructions to bidders
- Timeline: RFP issued [date]; clarification questions by [date]; answers shared with all bidders by [date]; responses due [date, time, time zone]; shortlist and proof of concept [dates]; decision [date].
- Single point of contact: [name, email]. Contact with other [Organisation] staff about this RFP may lead to disqualification.
- Response scale: for each requirement state available now; available with configuration; available with custom development; third-party product required (name it); roadmap (with a committed date); not supported. Roadmap answers score zero unless the date is contractually committed.
- Edition: state which edition or module each answer depends on and confirm it is included in the Appendix B price.
4. Functional requirements
4.1 Asset discovery and coverage
| ID | Requirement | Type |
|---|---|---|
| VM-AS-01 | Discovers assets by network sweep, agent check-in, cloud provider API and import from [CMDB, directory, endpoint management], and reconciles them into one record per asset without duplicates. | M |
| VM-AS-02 | Reports coverage: assets known to any source but not assessed in the last [7] days, by business unit and asset type. | M |
| VM-AS-03 | Assesses cloud workloads through provider APIs or snapshot scanning without an agent, and container images in [registries] and running clusters. | S |
| VM-AS-04 | Discovers internet-facing assets attributable to [Organisation] that are not in any internal source. | S |
| VM-AS-05 | Records business context per asset: owner, business service, environment, data sensitivity, internet exposure, tags imported from [CMDB]. | M |
See the Asset Inventory and CMDB Security Guide and the Attack Surface Management Guide.
4.2 Scanning and assessment methods
| ID | Requirement | Type |
|---|---|---|
| VM-SC-01 | Supports unauthenticated network scanning, authenticated scanning (SSH, Windows) and lightweight agents. State operating systems supported by agents. | M |
| VM-SC-02 | Reports authentication success or failure per asset and per scan, so failed credentialed scans are not counted as clean. | M |
| VM-SC-03 | Detects missing patches, vulnerable third-party software, end-of-life software and insecure configuration against [CIS Benchmarks or other baselines]. | S |
| VM-SC-04 | States the time from public CVE disclosure to detection content being available, with the last 12 months' median for vulnerabilities added to the CISA KEV catalogue. | S |
| VM-SC-05 | Provides safe scanning profiles and rate limits for fragile devices, and passive or vendor-integration options for [OT or medical] segments. | S |
| VM-SC-06 | Correlates software components from SBOMs (SPDX or CycloneDX) to known vulnerabilities. | I |
See the Authenticated vs Unauthenticated Scanning Guide.
4.3 Risk-based prioritisation
| ID | Requirement | Type |
|---|---|---|
| VM-PR-01 | Flags every finding whose CVE is in the CISA KEV catalogue, including the KEV date added and known ransomware campaign use field, refreshed at least daily. | M |
| VM-PR-02 | Shows the FIRST EPSS probability and percentile for each CVE, updated daily, and allows filtering and SLA rules on it. | M |
| VM-PR-03 | Shows CVSS base scores with version (v3.1 and v4.0) and vector, and lets [Organisation] adjust for environment. | S |
| VM-PR-04 | Combines exploitation evidence, asset criticality, internet exposure and compensating controls into a documented, explainable priority. Describe the model and its inputs; proprietary scores must show the factors behind each result. | M |
| VM-PR-05 | Supports decision models such as Stakeholder-Specific Vulnerability Categorization (SSVC) or customer-defined rules. | S |
| VM-PR-06 | Groups findings into remediation actions (for example one cumulative update fixing many CVEs) so owners receive fixes, not lists. | S |
See the CISA KEV Catalogue Guide, the EPSS Guide, the CVSS v4 Guide and the SSVC Guide.
4.4 Remediation workflow and exceptions
| ID | Requirement | Type |
|---|---|---|
| VM-RW-01 | Assigns findings to owners automatically from asset context, and creates and updates tickets in [ticketing system] with two-way status sync. | M |
| VM-RW-02 | Applies SLA rules by priority (for example KEV and internet-facing: [days]; critical: [days]) and reports breaches. | M |
| VM-RW-03 | Verifies remediation by rescanning and closes tickets only on verified fix; reopens findings that reappear. | M |
| VM-RW-04 | Records risk acceptances and exceptions with approver, compensating control and expiry, and re-raises them at expiry. | M |
| VM-RW-05 | Integrates with [patch and endpoint management tools] to show patch deployment status against findings. Describe any ability to trigger remediation and the approval controls around it. | S |
See the Remediation SLAs and Vulnerability Exceptions Guide.
4.5 Reporting and metrics
| ID | Requirement | Type |
|---|---|---|
| VM-RP-01 | Reports mean and median time to remediate by priority, business unit and owner; SLA compliance; KEV exposure over time; coverage. | M |
| VM-RP-02 | Provides an executive view and an auditor-ready export showing a finding's history from detection to verified fix. | S |
| VM-RP-03 | Provides a documented API for findings, assets and scan results, and streams events to [SIEM]. | M |
| VM-RP-04 | Describe any machine learning or generative AI features, how their outputs are explained, and what customer data they use. | I |
5. Platform security and non-functional requirements
| ID | Requirement | Type |
|---|---|---|
| VM-SEC-01 | Scan credentials stored encrypted, scoped to least privilege, retrievable from [secrets manager or PAM vault] at scan time, and never shown to administrators after entry. | M |
| VM-SEC-02 | Administrator access through [Organisation] SSO with phishing-resistant MFA and granular roles separating scan configuration, credential management and reporting. | M |
| VM-SEC-03 | All administrative actions logged with actor, time and change, retained for [period]. | M |
| VM-SEC-04 | Describe how agents and scanner appliances are updated, signed and protected from tampering, and how bidder staff access customer data. | S |
| VM-SEC-05 | Provide a current ISO/IEC 27001 certificate with in-scope service or SOC 2 Type II report, and a completed [SIG or CAIQ] questionnaire. | M |
| VM-NF-01 | Scales to [number] assets with scan windows of [hours] and agent impact under [CPU and memory limits]. | S |
| VM-NF-02 | Full export of assets, findings, exceptions and history in a documented format at exit. | M |
A scanner holds credentials to most of the estate. See the Secrets Management RFP Template for how those credentials should be brokered.
6. Implementation, services and support
- Approach: phases, deliverables and acceptance criteria for [discovery, agents on servers, cloud connectors, ticketing integration] within [months].
- Team: named roles and experience with estates of similar size; split between bidder, partner and [Organisation] effort.
- Content updates: how detection content is released, tested and communicated, including for emergency vulnerabilities.
- Support: tiers, hours, response targets by severity and escalation path.
- References: [two or three] customers of similar size or sector, at least one using risk-based SLAs in production.
7. Commercials
| Cost element | What to state |
|---|---|
| Licence metric | Per asset, per IP, per agent or per workload; how ephemeral cloud instances and containers are counted |
| Modules | Which section 4 requirements need add-ons (cloud, containers, web applications, external attack surface, prioritisation) |
| Scanners and agents | Any charge for additional scanner appliances or agents |
| Implementation | Fixed price or time and materials with day rates and estimated days by phase |
| Growth and renewal | Price for [growth percentage] more assets; cap on renewal increases; treatment of temporary overage |
| Exit | Charges for export and transition assistance |
8. Evaluation method and proof of concept
[Organisation] will check mandatory requirements first, then score the rest with these illustrative weights:
| Criterion | Weight | Evidence |
|---|---|---|
| Coverage and discovery (4.1) | [20%] | Proof of concept coverage report |
| Assessment accuracy (4.2) | [15%] | Proof of concept against known test hosts |
| Prioritisation quality (4.3) | [20%] | Proof of concept, explainability review |
| Remediation workflow and reporting (4.4, 4.5) | [15%] | Ticketing integration test |
| Platform security (5) | [10%] | Assurance reports, questionnaire |
| Life-cycle cost (7) | [20%] | Appendix B |
Scores use 0 to 5: 0 not met; 1 roadmap only; 3 met with configuration; 5 met fully and demonstrated. Shortlisted bidders run a proof of concept of [three to four] weeks on a representative slice of [Organisation]'s estate covering at least:
- Discover assets in [two network segments, one cloud account, one container registry] and report assets found that are missing from [CMDB].
- Run authenticated and agent assessments on [number] hosts, including a seeded host with known missing patches, and show credential failures explicitly.
- Produce a priority list for the slice and explain the top 20: KEV status, EPSS, CVSS, asset criticality and exposure for each.
- Create tickets in [ticketing system] for the top findings, fix two, and show verified closure after rescan.
- Record a risk acceptance with expiry and show it re-raised.
- Export the full dataset and pull findings through the API.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Score the top of the list, not the length: compare bidders on how many of their top 20 priorities in the proof of concept are KEV-listed or internet-facing on critical assets. A longer finding list is not a better result.
- Use the same slice for every bidder: identical hosts, credentials and time window, with seeded known vulnerabilities, so accuracy is comparable.
- Check the KEV and EPSS feeds yourself: pick five recent KEV additions and confirm when each bidder flagged them.
- Control proof-of-concept credentials: issue time-limited, least-privilege scan accounts, record them and revoke them all at the end.
- Agree SLAs before scoring: VM-RW-02 is only meaningful against your own remediation policy. CISA's Binding Operational Directive 22-01 sets remediation due dates for KEV entries at US federal agencies and is a useful reference point for others.
- Price ephemeral assets carefully: autoscaling and containers can multiply a per-asset licence. Model Appendix B at your peak, not your average.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Asset discovery (4.1) | CM-8 | ID.AM-01 |
| Scanning and content updates (4.2) | RA-5, RA-5(2) | ID.RA-01 |
| Remediation (4.4) | SI-2 | ID.RA-01 |
| Scan credentials and platform security (5) | IA-5, AC-6 | PR.AA-01 |
| Supplier assurance (5, 8) | SA-9, SR-6 | GV.SC-06 |
After award, carry requirement IDs into the statement of work and acceptance tests. For the programme around the tool, see the Risk-Based Vulnerability Management Guide and Top 10 Vulnerability Management Mistakes.
Standards and references
- CISA: Known Exploited Vulnerabilities Catalog
- FIRST: Exploit Prediction Scoring System (EPSS)
- FIRST: Common Vulnerability Scoring System v4.0
- CERT/CC: Stakeholder-Specific Vulnerability Categorization (SSVC)
- NIST: SP 800-40 Rev. 4 Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Vulnerability Management Buyer's Guide · Vulnerability Management Guide · Security Vendor Evaluation and RFP Guide · Patch Management Guide · SIEM RFP Template