Exposure management RFPs often end up as vulnerability scanner RFPs with a new name, so bidders win on finding counts while the questions that define CTEM, whether an exposure is actually exploitable, which attack paths reach critical assets and whether fixes get done, go unscored. This template gives you a ready-to-issue request for proposal for an exposure management platform supporting a continuous threat exposure management (CTEM) programme, with numbered requirements written so answers can be tested and scored. It covers scoping, discovery across assets and identities, prioritisation, attack path analysis, validation, mobilisation, platform security, pricing and a proof of concept plan. It differs from the Vulnerability Management RFP Template by focusing on validation, attack paths and non-CVE exposures rather than scanning coverage. Read the Exposure Management Buyer's Guide first for categories and pricing models; this page is the procurement document.
How to use this template
- Replace text in square brackets, such as [Organisation], [scanner], [ITSM] and [number], with your own details. Delete requirements that do not apply rather than leaving them unscored.
- Each requirement has an ID (for example EXM-PRI-03) and a type: M mandatory (pass or fail), S scored (weighted 0 to 5) or I informational.
- Weights and figures in brackets are illustrative. Agree your internal prioritisation policy (how KEV, EPSS, CVSS, SSVC, reachability and asset criticality combine) before issue, so bidders are scored against your policy rather than proposing their own.
- Complete Appendix A (first two or three CTEM scopes, critical assets per scope, existing data sources and estate size by asset and identity type) yourself. Bidders price against it.
- Issue sections 1 to 8 to bidders. Implementation guidance is for the panel only.
1. Purpose and scope
[Organisation] invites proposals for an exposure management platform to support a CTEM programme across the scopes in Appendix A: aggregating and correlating exposures, prioritising them by exploitability and business impact, validating them and driving remediation to verified closure.
- In scope: aggregation of findings from existing tools; asset and identity correlation; non-CVE exposures; prioritisation; attack path analysis; validation [within the platform / through integration with BAS or automated testing tools]; mobilisation through [ITSM]; reporting.
- Out of scope: [replacement of existing vulnerability scanners]; [penetration testing services, separate procurement]; [external attack surface management, if procured separately].
- Contract term: [three] years, with an option to extend by [two].
- Drivers: [remediation backlog that cannot be prioritised]; [identity and cloud exposures outside scanner coverage]; [board reporting on exposure]; [findings disputed by asset owners].
2. Current state
| Item | [Organisation] value |
|---|
| Vulnerability scanners and agents | [products], coverage [percentage] of known assets |
| Cloud, SaaS and identity posture tools | [products] |
| Directories and identity providers | [on-premises directory, cloud identity provider, number of tenants] |
| Estate size | [number] hosts, [number] cloud resources, [number] human and [number] non-human identities |
| Asset ownership data | [CMDB], estimated [percentage] of assets with a current owner |
| Open findings and remediation | [number] open findings; median closure time [days] for critical |
| Validation today | [annual penetration test / BAS / red team / none] |
3. Instructions to bidders
- Timeline: RFP issued [date]; questions by [date]; responses due [date, time, time zone]; proof of concept [dates]; decision [date].
- Contact: [name, email]; other contact about this RFP may lead to disqualification.
- Response scale: available now; available with configuration; third-party product required (name the category and whether it is licensed separately); roadmap (committed date); not supported. Roadmap answers score zero unless contractually committed.
- Evidence: link documentation for each "available now" answer and state which CTEM stage (scoping, discovery, prioritisation, validation, mobilisation) each module serves.
4. Functional requirements
4.1 Scoping, discovery and correlation
| ID | Requirement | Type |
|---|
| EXM-SCO-01 | Defines scopes by business service, owner, tag or critical asset, with separate dashboards, metrics and cycle tracking per scope. | M |
| EXM-DIS-01 | Provides native connectors for each Appendix A source, with documented field mapping and stated refresh frequency. | M |
| EXM-DIS-02 | Correlates the same asset across sources, showing source, confidence and last-seen time, and counts it once for licensing. | S |
| EXM-DIS-03 | Treats non-CVE exposures as first-class findings: misconfigurations, excessive permissions, missing MFA, exposed secrets, missing security agents and internet-exposed management interfaces. | M |
| EXM-DIS-04 | Links human and non-human identities (service accounts, workload identities, API keys) to the assets and permissions they hold. | S |
| EXM-DIS-05 | Reports assets with no owner, no scanner coverage or no security agent as a coverage gap. | S |
4.2 Prioritisation
| ID | Requirement | Type |
|---|
| EXM-PRI-01 | Shows each prioritisation input for a finding: CISA KEV status, FIRST EPSS score and percentile (refreshed daily), CVSS v4.0 vector and score type (CVSS-B, CVSS-BT or CVSS-BTE), reachability and asset criticality. | M |
| EXM-PRI-02 | Supports [Organisation]'s own prioritisation policy, including SSVC-style decision outcomes (Track, Track*, Attend, Act), with weights that can be changed and the effect previewed. | S |
| EXM-PRI-03 | Explains any proprietary score by decomposing it into its inputs; no score is accepted that cannot be decomposed. | M |
| EXM-PRI-04 | Groups findings by fix (one patch or configuration change closing many findings) and estimates the risk reduced per fix. | S |
FIRST describes EPSS as estimating the probability that a published CVE will be exploited in the wild in the next 30 days, and CISA's KEV catalogue lists only vulnerabilities with a CVE ID, reliable evidence of active exploitation and clear remediation guidance. Neither is a risk score on its own. See the EPSS Guide, the CISA KEV Catalogue Guide and the CVSS v4 Guide.
4.3 Attack path analysis
| ID | Requirement | Type |
|---|
| EXM-PATH-01 | Models paths from defined entry points (internet-facing assets, phishable users, third-party access) to Appendix A critical assets across network reachability, vulnerabilities, identities and permissions. | M |
| EXM-PATH-02 | Identifies choke points and ranks them by the number of paths to critical assets each fix would close. | S |
| EXM-PATH-03 | Covers on-premises directory and cloud identity privilege paths, including group nesting, delegated rights, role assignments and service principal permissions. | S |
| EXM-PATH-04 | Recalculates paths after identity, network or configuration changes; state the refresh interval. | S |
See the Identity Attack Paths Guide.
4.4 Validation
| ID | Requirement | Type |
|---|
| EXM-VAL-01 | Validates whether prioritised exposures are exploitable and whether existing controls would prevent or detect exploitation, natively or through integration with [BAS or automated testing tool]; state which. | M |
| EXM-VAL-02 | Validation is safe by design: scope limits, production-safe techniques, rate limits, a kill switch and exclusion lists for fragile and OT systems; describe each. | M |
| EXM-VAL-03 | Maps validation scenarios to MITRE ATT&CK techniques and records which controls prevented, detected or missed each one. | S |
| EXM-VAL-04 | Re-validates automatically after a fix is reported and closes the finding only on a passing result. | S |
| EXM-VAL-05 | State the identities and credentials validation needs, how they are protected and how actions are logged. | M |
See the Breach and Attack Simulation Buyer's Guide.
4.5 Mobilisation and reporting
| ID | Requirement | Type |
|---|
| EXM-MOB-01 | Two-way integration with [ITSM] and [engineering tracker]: tickets grouped by fix and owner, status synchronised, and closure only after verification. | M |
| EXM-MOB-02 | Records risk responses (accept, mitigate, transfer, avoid) with approver, justification and expiry, and alerts on expired exceptions. | M |
| EXM-MOB-03 | Tracks remediation against [Organisation] timeframes per priority, with KEV entries tracked against [two weeks] as a reference. | S |
| EXM-REP-01 | Reports per scope: KEV exposure window on reachable assets, attack paths and choke points to critical assets, median closure time for validated exposures, owner coverage and exceptions past expiry; all exportable by API. | S |
An exposure management platform holds a map of every weakness and path to your critical assets, and its connectors read your clouds, directories and scanners. Treat it as a crown-jewel system.
| ID | Requirement | Type |
|---|
| EXM-SEC-01 | Access through [Organisation] SSO with phishing-resistant MFA, granular roles and restriction of attack path views by scope. | M |
| EXM-SEC-02 | Connectors use read-only, least-privilege roles, federated or short-lived credentials where supported, stored encrypted or in [secrets manager]; list the permissions each connector requires. | M |
| EXM-SEC-03 | Logs all user, API and validation actions, exportable to [SIEM]. | M |
| EXM-SEC-04 | States data locations for findings and attack graphs, sub-processors and how bidder staff access customer data; current independent assurance report and completed [SIG or CAIQ]. | M |
| EXM-NF-01 | Deployment options (SaaS, regional SaaS, self-hosted) and suitability for [air-gapped or sensitive] segments. | I |
6. Services and support
- Onboarding: plan to connect Appendix A sources and complete one full CTEM cycle on scope one within [weeks].
- Programme support: help defining scopes, critical assets and prioritisation policy, and the effort [Organisation] must provide.
- Support: tiers, hours and response targets by severity.
- References: [two or three] customers of similar size that have run at least [four] cycles.
7. Pricing
| Cost element | What to state |
|---|
| Licence metric | Assets, identities (state whether non-human identities count), cloud resources or modules; how duplicates are counted |
| Modules | Which CTEM stages each module covers and its price; total for all five stages |
| Validation | Scenarios, runs or targets included; cost of re-validation after fixes |
| Growth | Three-year cost at today's estate and at [30%] growth |
| Services | Onboarding and programme support, day rates |
| Renewal and exit | Cap on renewal increases; export of findings, exceptions and history |
8. Evaluation method and proof of concept
| Criterion | Weight | Evidence |
|---|
| Discovery and correlation (4.1) | [20%] | Proof of concept on Appendix A sources |
| Prioritisation and attack paths (4.2, 4.3) | [25%] | Shortlist quality against panel review |
| Validation (4.4) | [15%] | Validation results on the shortlist |
| Mobilisation and reporting (4.5) | [15%] | ITSM round trip demo |
| Platform security (5) | [10%] | Connector permissions, assurance reports |
| Cost over the term (7) | [15%] | Priced against Appendix A |
Scores use 0 to 5: 0 not met; 1 roadmap only; 3 met with configuration; 5 met fully and demonstrated. Shortlisted bidders run a [four]-week proof of concept on scope one:
- Connect [scanner], [cloud account], [identity provider] and [directory] with read-only credentials and report duplicate assets merged and coverage gaps found.
- Produce a shortlist of the top [25] exposures for scope one with every input visible; the panel compares it with its own expert ranking.
- Show attack paths to [two] critical assets and the top [five] choke points, including at least one identity-only path with no CVE.
- Validate [ten] shortlisted exposures safely in [test or agreed production segment] and record prevented, detected and missed results.
- Raise grouped tickets in [ITSM], apply one fix, and show re-validation and verified closure.
- Record and expire one risk acceptance and show the alert.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Scope before you buy: one or two business-defined scopes make the proof of concept meaningful; scoping "everything" reproduces the backlog. See the Exposure Management and CTEM Guide.
- Score the shortlist, not the dashboard: the panel's own ranking in step 2 is the best test of prioritisation.
- Insist on identity coverage: standing privilege and leaked secrets create paths with no CVE; a platform that misses them misses the shortest routes.
- Approve validation safety in writing: agree scope, exclusions and the kill switch with system owners before step 4.
- Revoke proof of concept access: remove every connector credential and test account from losing bidders.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|
| Discovery and correlation (4.1) | RA-5 | ID.AM-01, ID.RA-01 |
| Prioritisation and attack paths (4.2, 4.3) | RA-3, PM-16 | ID.RA-05 |
| Validation (4.4) | CA-8 | ID.RA-01 |
| Mobilisation (4.5) | RA-5 | ID.RA-06 |
| Acquisition (all) | SA-4 | GV.SC-05 |
Standards and references
Related NHI Mgmt Group resources: Exposure Management Buyer's Guide · Exposure Management and CTEM Guide · Vulnerability Management RFP Template · Attack Surface Management Buyer's Guide · Security Vendor Evaluation and RFP Guide