Asset inventory and cyber asset attack surface management (CAASM) procurements usually fail on one question nobody tested: when ten tools each report a slightly different version of the same laptop, does the product merge them correctly and tell you what is missing? This template is a ready-to-issue request for proposal for a CAASM or security asset inventory platform. Its requirements are numbered and scorable, and they concentrate on the three things that separate products in practice: the depth of connectors, the quality of correlation and deduplication, and the ability to query coverage gaps such as devices with no endpoint agent or cloud accounts with no owner. It is narrower than the Exposure Management RFP Template, which covers prioritisation and validation across the whole attack surface. It is vendor-neutral and written for security architects, vulnerability and IT asset management leads, and procurement. For how the market is shaped, read the Asset Inventory and CAASM Buyers Guide; this page is the procurement document.
How to use this template
- Replace text in square brackets, such as [Organisation], [number of devices] and [CMDB], with your own details. Delete requirements that do not apply rather than leaving them unscored.
- Each requirement has an ID (for example CA-DD-03) 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 to the ones you would genuinely walk away over.
- Weights, volumes and cadences in brackets are illustrative. Set them before issue and do not change them once responses arrive.
- Issue sections 1 to 8 to bidders. The Implementation guidance section is for your evaluation panel only.
- Ask for responses in a spreadsheet with one row per requirement ID, the response scale in section 3, and a documentation link for every "available now" answer.
1. Purpose and scope
[Organisation] invites proposals for a cyber asset attack surface management platform. The platform must collect asset data from existing tools through their APIs, correlate it into one accurate record per asset, show which security controls apply to each asset, and expose the gaps as queries that owners can act on.
- In scope: devices (servers, end-user devices, mobile, network equipment), cloud resources and accounts, SaaS applications, users and non-human identities (service accounts, workload identities, API keys known to source systems), software, vulnerabilities as reported by existing scanners, and the relationships between them.
- Out of scope: [replacing the CMDB as the IT service management record]; [vulnerability scanning, which remains with existing scanners]; [external attack surface discovery, unless offered as an optional module priced separately]; [remediation execution beyond ticket creation].
- Contract term: [three] years with an option to extend by [two] years.
- Drivers: [audit findings on CIS Control 1 or ISO/IEC 27001 asset inventory]; [unknown agent coverage]; [slow incident scoping because asset context sits in many tools]; [cloud accounts with no owner]; [regulatory expectations such as NIS2 or DORA].
2. Organisation background and current state
| Item | [Organisation] value |
|---|---|
| End-user devices and servers | [number laptops and desktops], [number Windows servers], [number Linux servers] |
| Mobile devices | [number corporate], [number BYOD enrolled] |
| Cloud | [providers], [number of accounts, subscriptions or projects], [Kubernetes clusters] |
| SaaS | [number of sanctioned applications], [identity provider] |
| Network and OT | [network equipment count], [OT or medical device segments, scanning restrictions] |
| Source tools to integrate | [identity provider and directory], [endpoint management], [EDR], [vulnerability scanners], [cloud provider inventories], [CMDB], [network access control], [DHCP and DNS], [HR system] |
| Downstream consumers | [SIEM], [ticketing system], [CMDB], [vulnerability management platform] |
| Hosting and residency | [SaaS acceptable in named regions / on-premises collector required in restricted 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.
- Connector list: provide your full connector catalogue as Appendix A, marking for each connector whether it is built and maintained by you, by a partner or by the customer, and which object types and fields it reads.
- 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 Connectors and data collection
| ID | Requirement | Type |
|---|---|---|
| CA-CN-01 | Provides maintained, read-only API connectors for every source in section 2. For each, state object types collected (devices, users, cloud resources, software, vulnerabilities) and the fields mapped. | M |
| CA-CN-02 | Collects from each source on a configurable schedule of at least [every 24 hours], with on-demand refresh, and shows last successful collection time per connector. | M |
| CA-CN-03 | Alerts when a connector fails, returns partial data or returns a sudden drop in object count (for example more than [20%] fewer devices than the previous run). | M |
| CA-CN-04 | Supports generic ingestion (REST API, CSV, webhook) with customer-defined field mapping for sources without a native connector. | S |
| CA-CN-05 | Collects in restricted or air-gapped segments through an on-premises collector that initiates outbound connections only. | S |
| CA-CN-06 | States connector maintenance commitments: time to fix after a source vendor changes its API, and how breaking changes are communicated. | S |
4.2 Correlation and deduplication
| ID | Requirement | Type |
|---|---|---|
| CA-DD-01 | Correlates records from different sources into one asset using multiple identifiers (serial number, hardware UUID, MAC address, hostname, cloud instance ID, agent ID) with documented precedence rules. | M |
| CA-DD-02 | Shows, for each correlated asset, which sources contributed which fields and when each was last seen, so analysts can see why records were merged. | M |
| CA-DD-03 | Handles common traps without false merges: reimaged devices, reused hostnames, virtual machine clones sharing identifiers, randomised MAC addresses and ephemeral cloud instances. | M |
| CA-DD-04 | Lets administrators adjust correlation rules and split or merge records manually, with changes logged and preserved across collections. | S |
| CA-DD-05 | Reports a deduplication ratio per asset class (raw records to unique assets) and flags low-confidence matches for review. | S |
| CA-DD-06 | Correlates users and non-human identities across the identity provider, directory, cloud and SaaS sources, and links them to the devices and resources they own or use. | S |
4.3 Coverage gap queries and policy
| ID | Requirement | Type |
|---|---|---|
| CA-GP-01 | Provides a query language or builder over all assets, fields and relationships, with saved queries, scheduled runs and export. | M |
| CA-GP-02 | Ships ready-made coverage queries, at minimum: devices with no EDR agent; devices not seen by the vulnerability scanner in [14] days; devices missing from endpoint management; cloud accounts and resources with no owner tag; assets absent from the CMDB. | M |
| CA-GP-03 | Evaluates customer-defined policies continuously (for example "every production server has EDR, a backup policy and an owner") and records each violation with first-seen and resolved dates. | M |
| CA-GP-04 | Detects assets seen by network sources (DHCP, network access control, passive monitoring) that no managed source knows about, supporting CIS Safeguard 1.2 handling of unauthorised assets. | S |
| CA-GP-05 | Identifies identity hygiene gaps from collected data: accounts of leavers still enabled, service accounts with no owner, users with no MFA registration in [identity provider]. | S |
| CA-GP-06 | Shows software and end-of-life operating systems per asset from collected data, and links SBOM data where sources provide it. | I |
4.4 Context, workflow and integration
| ID | Requirement | Type |
|---|---|---|
| CA-WF-01 | Assigns ownership from source data (CMDB, cloud tags, directory manager) and lets owners be set by rule for assets that lack one. | M |
| CA-WF-02 | Creates and updates tickets in [ticketing system] for policy violations, with two-way status sync and automatic closure when the gap is verified as fixed at the next collection. | M |
| CA-WF-03 | Writes reconciled data back to [CMDB] under customer control, field by field, without overwriting authoritative CMDB fields. | S |
| CA-WF-04 | Provides an asset lookup for incident responders (by IP at a point in time, hostname, user or cloud ID) returning owner, controls, vulnerabilities and history. | S |
| CA-WF-05 | Streams asset changes and violations to [SIEM] and exposes a documented API for assets, queries and violations. | M |
| CA-WF-06 | Describe any actions the platform can trigger in source tools (for example tagging, isolating, deploying an agent), the permissions required and the approval controls. | I |
See the Asset Inventory and CMDB Security Guide and the CIS Control 1 Inventory and Control of Enterprise Assets Guide.
5. Platform security and non-functional requirements
A CAASM platform holds read credentials to almost every security and IT tool you own, and its database is a map of your estate. Treat it as a high-value system.
| ID | Requirement | Type |
|---|---|---|
| CA-SEC-01 | Connector credentials (API keys, OAuth clients, service accounts) stored encrypted, scoped to read-only least privilege documented per connector, retrievable from [secrets manager] where supported, and never displayed after entry. | M |
| CA-SEC-02 | Supports short-lived or federated credentials (for example cloud role assumption or workload identity federation) instead of long-lived keys where the source allows it. | S |
| CA-SEC-03 | Administrator access through [Organisation] SSO with phishing-resistant MFA, and roles that separate connector management, query authoring and read-only use, with scoping by business unit. | M |
| CA-SEC-04 | Logs all administrative actions, connector changes, manual merges and exports with actor and time, retained for [period] and exportable to [SIEM]. | M |
| CA-SEC-05 | Provide a current ISO/IEC 27001 certificate with in-scope service or SOC 2 Type II report, data residency options, sub-processor list and a completed [SIG or CAIQ] questionnaire. | M |
| CA-NF-01 | Scales to [number] assets and [number] raw records, with query response under [seconds] for the queries in CA-GP-02. | S |
| CA-NF-02 | Retains asset history for [13] months to answer "what was at this IP on this date". | S |
| CA-NF-03 | Full export of assets, history, queries and policies in a documented format at exit, and deletion of customer data with certificate. | M |
The connector accounts are non-human identities with broad read access: inventory, scope and rotate them like any other. See NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments and NHI Inventory Reconciliation.
6. Implementation, services and support
- Approach: phases, deliverables and acceptance criteria for [identity and endpoint sources first, then cloud and scanners, then CMDB write-back] within [weeks].
- Correlation tuning: who tunes correlation rules during onboarding, how many days are included, and how false merges reported after go-live are handled.
- Team: named roles and experience with estates of similar size; split between bidder, partner and [Organisation] effort.
- Support: tiers, hours, response targets by severity, and the target time to restore a broken connector.
- References: [two or three] customers of similar size or sector, at least one using CAASM data for audit evidence or incident response.
7. Commercials
| Cost element | What to state |
|---|---|
| Licence metric | Per unique asset, per raw record, per user or per employee; how users, cloud resources, containers and ephemeral instances are counted; whether deduplicated or raw counts are billed |
| Connectors | Whether any connector is charged separately or limited by edition |
| Modules | Which section 4 requirements need add-ons (identity, cloud, external attack surface, write-back, actions) |
| Collectors | Any charge for on-premises collectors |
| 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 |
| 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 |
|---|---|---|
| Connectors and collection (4.1) | [20%] | Appendix A, proof of concept connector health |
| Correlation accuracy (4.2) | [25%] | Proof of concept against a reconciled sample |
| Coverage gap queries and policy (4.3) | [20%] | Proof of concept query tests |
| Workflow and integration (4.4) | [10%] | Ticketing and SIEM test |
| Platform security (5) | [10%] | Assurance reports, connector permission review |
| Life-cycle cost (7) | [15%] | Appendix B modelled on your counts |
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] weeks connected to the same sources, covering at least:
- Connect [identity provider, endpoint management, EDR, one vulnerability scanner, one cloud account, CMDB] using read-only accounts issued for the test, and show connector health.
- Before the test, the panel builds a hand-reconciled sample of [200] assets, including seeded traps: a reimaged laptop, a reused hostname, a cloned virtual machine and a decommissioned device still in the CMDB. Bidders report correlation results for the sample.
- Run the CA-GP-02 queries and show the gap counts, then pick ten results and trace each back to source records.
- Define the policy in CA-GP-03 for one business unit and raise tickets for violations; fix two and show automatic closure after the next collection.
- Answer an incident-style lookup: owner, controls and history for [IP address] on [date].
- Export the dataset and pull assets through the API.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Score correlation on your hand-reconciled sample: count false merges (two real assets shown as one) and false splits (one asset shown twice) separately. False merges are worse, because they hide an unprotected device behind a protected one.
- Distrust the headline asset count: a bidder that reports more assets than your sources contain is usually failing to deduplicate. Compare the raw-to-unique ratio across bidders.
- Test the gap, not the dashboard: the value is in the queries of CA-GP-02. If a bidder cannot trace a "no EDR" result back to source records, its gap counts cannot be used as audit evidence.
- Set cadences from your standard: CIS Safeguard 1.3 expects active discovery at least every 24 hours (IG2 and IG3), and CISA Binding Operational Directive 23-01 requires US federal agencies to run automated asset discovery every 7 days and vulnerability enumeration every 14 days. Choose CA-CN-02 and CA-GP-02 values that meet whichever applies to you.
- Control proof-of-concept access: issue time-limited, read-only accounts for every connector, record them and revoke them all at the end, and get the bidder's confirmation that collected data is deleted.
- Price on deduplicated counts: raw-record licensing penalises you for having many tools. Model Appendix B on raw and unique counts from the proof of concept.
- Plan the OT boundary: where OT segments are in scope, require passive collection only and follow the CISA-led Foundations for OT Cybersecurity asset inventory guidance. See the OT Asset Visibility Guide.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | CIS Controls v8.1 |
|---|---|---|---|
| Connectors and correlation (4.1, 4.2) | CM-8, CM-8(1) | ID.AM-01, ID.AM-02 | 1.1, 2.1 |
| Unauthorised and unmanaged assets (4.3) | CM-8(3), SI-4 | ID.AM-01 | 1.2, 1.3, 1.4, 1.5 |
| Identity correlation and connector credentials (4.2, 5) | IA-5, AC-6 | PR.AA-01 | 5.1 |
| Audit logging (5) | AU-2 | PR.PS-04 | 8.2 |
| Supplier assurance (5, 8) | SA-9, SR-6 | GV.SC-06 | 15.4 |
After award, carry requirement IDs into the statement of work and acceptance tests, and rerun the correlation sample at go-live. For discovery of internet-facing assets, see the Attack Surface Management Buyer's Guide; for scanning requirements, the Vulnerability Management RFP Template.
Standards and references
- CIS: Controls Assessment Specification, Safeguard 1.3 Utilize an Active Discovery Tool
- CIS: Control 1 Inventory and Control of Enterprise Assets
- CISA: Binding Operational Directive 23-01 Improving Asset Visibility and Vulnerability Detection on Federal Networks
- CISA: Foundations for OT Cybersecurity, Asset Inventory Guidance for Owners and Operators
- NIST NCCoE: SP 1800-5 IT Asset Management
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Asset Inventory and CAASM Buyers Guide · Exposure Management RFP Template · Security Vendor Evaluation and RFP Guide · Attack Surface Management Guide · Asset Management Policy Template