Most CNAPP selections go wrong because the RFP asks bidders to tick feature boxes, so every response says "yes" to CSPM, CWPP, CIEM and attack paths and the panel ends up choosing on the demo. This template gives you a ready-to-issue request for proposal for a cloud-native application protection platform, with numbered requirements written so that each answer can be tested in a proof of concept and scored. It covers posture management, workload protection, cloud entitlements and non-human identities, agentless versus agent-based coverage, infrastructure as code and pipeline scanning, attack path analysis, platform security, services and commercials. It is vendor-neutral and written for cloud security leads, platform engineering teams and procurement panels. For what the market offers and how the categories fit together, read the CNAPP Buyer's Guide; for the selection process itself, the Security Vendor Evaluation and RFP Guide.
How to use this template
- Replace text in square brackets, such as [Organisation], [cloud providers] and [number], with your own details. Delete requirements that do not apply to your estate.
- Each requirement has an ID (for example CNP-CSPM-02) and a type: M mandatory (pass or fail, a "no" eliminates the bid), S scored (0 to 5, weighted) or I informational (not scored, used for planning).
- Keep mandatory items few. If more than about a fifth of requirements are mandatory, every bid will fail something and the panel will start waiving them, which undermines the process.
- Weights, volumes and timings in brackets are illustrative, not benchmarks. Set them from your own risk and scale 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.
1. Purpose and scope
[Organisation] invites proposals for a cloud-native application protection platform (CNAPP) and associated implementation services. The platform must give a single, prioritised view of misconfigurations, vulnerabilities, excessive permissions, exposed secrets and runtime threats across [Organisation] cloud accounts, workloads and delivery pipelines, and support remediation by the teams who own each resource.
- In scope: [named cloud providers and number of accounts, subscriptions or projects]; [virtual machines]; [managed Kubernetes and self-managed clusters]; [serverless functions]; [container registries]; [infrastructure as code repositories]; [CI/CD pipelines]; [cloud identities, roles and service accounts].
- Out of scope: [SaaS posture management]; [endpoint protection for user devices]; [web application firewall]; [a SIEM replacement].
- Drivers: [too many disconnected point tools]; [audit findings on cloud configuration]; [no inventory of cloud identities]; [regulatory obligations]; [incident lessons].
- Contract term: [three] years with an option to extend by [one or two] years.
2. Organisation background and current state
| Item | [Organisation] value |
|---|
| Cloud providers and accounts | [provider]: [number] accounts, subscriptions or projects; [organisation or management group structure] |
| Compute footprint | [number] virtual machines; [number] Kubernetes clusters and nodes; [number] serverless functions |
| Container images and registries | [registries]; [approximate images built per month] |
| Code and pipelines | [source control platform]; [number] repositories; [IaC languages, for example Terraform, CloudFormation, Bicep, Helm]; [CI/CD platforms] |
| Cloud identities | [number] human users with cloud access; [number or "unknown"] roles, service principals, service accounts and access keys |
| Existing tooling | [native cloud security services in use]; [vulnerability scanner]; [secrets scanner]; [SIEM and SOAR]; [ticketing] |
| Compliance baselines | [CIS Benchmarks for named providers]; [PCI DSS]; [ISO/IEC 27001]; [internal standards] |
| Data residency and hosting | [region constraints for platform data and scan results] |
3. Instructions to bidders
- Timeline: RFP issued [date]; clarification questions by [date]; responses due [date, time, time zone]; shortlist [date]; proof of concept [dates]; decision [date].
- Single point of contact: [name, email]. Contact with other [Organisation] staff during the process may lead to disqualification.
- Response scale: for each requirement state one of: available now; available with configuration; requires custom development; requires a third-party product (name it); roadmap (give a committed date); not supported. Roadmap answers score zero unless the date is written into the contract.
- Evidence: reference public product documentation for every "available now" answer, and state which licence tier or module each capability needs.
- Architecture: provide a diagram showing every connection into [Organisation] cloud accounts, the permissions requested, where scan data and snapshots are processed and stored, and in which regions.
4. Functional requirements
4.1 Cloud security posture management (CSPM)
| ID | Requirement | Type |
|---|
| CNP-CSPM-01 | Discovers all resources in every in-scope account, including newly created accounts, within [24 hours], and maintains a searchable asset inventory. | M |
| CNP-CSPM-02 | Assesses configuration against CIS Benchmarks for [named providers and Kubernetes services] and against custom policies written by [Organisation]; state the policy language. | M |
| CNP-CSPM-03 | Maps findings to [PCI DSS, ISO/IEC 27001, NIST SP 800-53, other] and produces exportable compliance reports per account and business unit. | S |
| CNP-CSPM-04 | Detects configuration drift and changes in near real time from cloud audit logs, not only on scheduled scans; state the typical delay. | S |
| CNP-CSPM-05 | Offers guided and optional automated remediation, with automated actions off by default, scoped by account and tag, and fully logged. | S |
| CNP-CSPM-06 | Identifies sensitive data stores (for example object storage and databases) and data exposure risk; state the data types classified and where classification runs. | S |
4.2 Cloud workload protection (CWPP) and vulnerability management
| ID | Requirement | Type |
|---|
| CNP-CWP-01 | Scans virtual machines, container images and serverless functions for operating system and language package vulnerabilities, malware and embedded secrets. | M |
| CNP-CWP-02 | Prioritises vulnerabilities using exploitability context: internet exposure, CISA Known Exploited Vulnerabilities listing, EPSS where offered, and whether the package is loaded at run time. | S |
| CNP-CWP-03 | Provides runtime threat detection for hosts and containers (process, file, network and Kubernetes audit events), with detections mapped to MITRE ATT&CK. | S |
| CNP-CWP-04 | Supports optional runtime prevention (for example blocking a process or isolating a workload) with a monitor-only mode. | S |
| CNP-CWP-05 | Scans registries and enforces image admission policy in Kubernetes (for example block unsigned images or images with critical exploitable vulnerabilities). | S |
| CNP-CWP-06 | Assesses Kubernetes cluster configuration, RBAC and workload settings (privileged containers, host mounts, service account token use). | S |
See the Container Security Guide and the Kubernetes Security Guide.
4.3 Agentless and agent-based coverage
| ID | Requirement | Type |
|---|
| CNP-COV-01 | Describe exactly what agentless scanning covers (API-based configuration, disk snapshot analysis or other), how often it runs, and what it cannot see. | M |
| CNP-COV-02 | Describe where snapshots or disk images are analysed (in [Organisation] accounts or the bidder's), how long copies persist, and the cloud cost [Organisation] will incur. | M |
| CNP-COV-03 | Provide an agent or sensor for runtime detection and prevention on [Linux distributions and versions], [Windows Server versions] and Kubernetes nodes; state kernel and eBPF requirements and resource overhead. | S |
| CNP-COV-04 | Agent updates can be staged in rings, pinned to a version and rolled back by [Organisation]. | S |
4.4 Cloud infrastructure entitlements (CIEM) and non-human identities
| ID | Requirement | Type |
|---|
| CNP-CIEM-01 | Calculates effective permissions for human and non-human identities (roles, service principals, service accounts, access keys), including inherited, cross-account and resource-based policy grants. | M |
| CNP-CIEM-02 | Identifies unused permissions, dormant identities and long-lived access keys, using [90] days of activity, and generates least-privilege policy suggestions. | S |
| CNP-CIEM-03 | Flags identities that can escalate their own privilege or reach administrative permissions through role chaining. | S |
| CNP-CIEM-04 | Detects anomalous use of cloud identities from audit logs (for example use of a key from an unusual network or a first-time sensitive API call). | S |
| CNP-CIEM-05 | Assigns or imports an owner for each non-human identity and exports the identity inventory to [IGA or NHI management platform]. | I |
See the Cloud PAM and CIEM Guide and the CIEM Buyers Guide.
4.5 Infrastructure as code, pipeline and supply chain scanning
| ID | Requirement | Type |
|---|
| CNP-IAC-01 | Scans [IaC languages] in pull requests and pipelines with the same policies used for runtime posture, so a rule is written once. | M |
| CNP-IAC-02 | Detects hard-coded secrets in repositories and images, and states whether it validates whether a found secret is live. | S |
| CNP-IAC-03 | Traces a runtime finding back to the IaC file and repository owner that created the resource, and opens a fix pull request where supported. | S |
| CNP-IAC-04 | Generates or ingests SBOMs for images and supports image signature verification. | S |
| CNP-IAC-05 | Offers break-the-build and warn-only modes per repository, with exception workflow and expiry. | S |
See the Infrastructure as Code Security Guide.
4.6 Attack path analysis, prioritisation and workflow
| ID | Requirement | Type |
|---|
| CNP-APA-01 | Correlates exposure, vulnerabilities, identities, secrets and data sensitivity into attack paths from the internet or a compromised identity to sensitive resources; explain the graph model. | M |
| CNP-APA-02 | Ranks issues with a transparent, explainable risk score and allows [Organisation] to adjust weighting by asset criticality tags. | S |
| CNP-APA-03 | Routes findings to owning teams in [ticketing platform] with deduplication, SLA tracking and automatic closure when the issue is fixed. | S |
| CNP-APA-04 | Sends alerts and findings to [SIEM and SOAR] via documented APIs and supports bidirectional status updates. | M |
| CNP-APA-05 | Provides role-based views so that application teams see only their own accounts and findings. | S |
See the Identity Attack Paths Guide.
A CNAPP is granted read access, and sometimes write access, to every cloud account you own. A breach of the platform or of its connector credentials is a breach of the estate, so these requirements carry heavy weight.
| ID | Requirement | Type |
|---|
| CNP-SEC-01 | Connects to cloud accounts through role assumption or workload identity federation with external IDs, not long-lived access keys; list every permission requested and justify any write permission. | M |
| CNP-SEC-02 | Users authenticate through [Organisation] SSO with phishing-resistant MFA; roles are granular, and API tokens are scoped, expiring and revocable. | M |
| CNP-SEC-03 | Describe tenant isolation, encryption of scan data at rest and in transit, customer-managed key options and data retention periods. | M |
| CNP-SEC-04 | Bidder staff access to customer data is approved, time-bound and logged; [Organisation] can see these logs. | S |
| CNP-SEC-05 | Provide a current independent assurance report (for example SOC 2 Type II or ISO/IEC 27001 certificate with scope), a [SIG or CAIQ] response, a vulnerability disclosure policy and security incident history for the last three years. | M |
| CNP-SEC-06 | Exports all findings, inventory, policies and audit history in a documented format at exit, followed by certified deletion. | M |
| CNP-NF-01 | Availability commitment of [percentage] with service credits; documented disaster recovery objectives. | S |
6. Implementation, services and support
- Phasing: propose phases with acceptance criteria, for example [read-only posture across all accounts, then CIEM, then IaC in the top [number] repositories, then runtime agents on production clusters].
- Noise reduction: describe how initial findings are baselined and tuned, and the expected volume of high-priority findings after tuning for an estate of our size.
- Team and references: named roles and [two or three] references of similar scale and cloud mix, at least one using the IaC-to-runtime trace in production.
- Support: support tiers, severity definitions and response targets, release cadence and advance notice of breaking changes to policies or APIs.
- Training: training for the cloud security team and enablement material for application teams.
7. Commercials
| Cost element | What to state |
|---|
| Licence metric | Per workload, per resource, per vCPU, per account, per developer or credit-based; how containers, serverless functions, nodes and idle resources are counted |
| Modules | Which section 4 requirements need separate modules or tiers (CIEM, runtime, IaC, data security) |
| Cloud cost to [Organisation] | Estimated snapshot, storage, compute and log costs incurred in our accounts |
| Implementation and training | Fixed price or day rate with estimated days per phase |
| Growth, renewal and exit | Price for [growth percentage] more workloads; true-up method; renewal cap; exit charges |
8. Evaluation method and proof of concept
| Criterion | Weight | Evidence |
|---|
| Functional fit (section 4) | [35%] | Written response, proof of concept results |
| Quality of prioritisation and noise (4.6) | [15%] | Proof of concept: share of top findings the panel agrees are real and urgent |
| Platform security and data handling (section 5) | [15%] | Permission review, assurance reports |
| Usability for cloud and application teams | [10%] | Scored by the engineers who will use it |
| Implementation approach and references | [5%] | Section 6, reference calls |
| Three-year life-cycle cost | [20%] | Section 7, including cloud costs we incur |
Scores use 0 to 5: 0 not met; 1 roadmap only; 2 met with custom work or a third-party product; 3 met with configuration; 4 met and evidenced; 5 met fully and demonstrated in the proof of concept. The proof of concept runs for [number] weeks in [named test accounts] and covers at minimum:
- Connect read-only to [number] test accounts and a test cluster; record the time to first complete inventory and compare against our own asset list.
- Planted misconfigurations: a public storage bucket holding test data marked sensitive, an over-privileged role attached to an internet-facing VM, and a long-lived access key unused for [90] days. Measure which are found and how they are ranked.
- A container image with a known exploited vulnerability deployed to the test cluster; check detection, prioritisation and the admission control block.
- A pull request with an IaC misconfiguration and a dummy secret; check the pipeline result and the trace from runtime finding to repository.
- A benign simulated runtime event (for example an unexpected shell in a container) using a sanctioned test tool; check detection, ATT&CK mapping and SIEM delivery.
- Ticket creation, owner routing and automatic closure after the fix.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Agentless first, agents where runtime matters: agentless scanning gives broad coverage quickly without touching workloads; agents give real-time detection and prevention. Score CNP-COV-01 to 04 against where your crown-jewel workloads run, not against total resource count.
- Read the permission list: CNP-SEC-01 is often the most revealing answer. Reject unexplained write permissions and connectors that need static keys.
- Measure signal, not volume: a platform that reports 40,000 findings and one that reports 400 may see the same estate. In the proof of concept, have engineers mark each of the top 25 findings as real and urgent or not, and score the share.
- Decide ownership early: agree whether the cloud security team or application teams own remediation before issue; requirement CNP-APA-03 only works if owner tags exist.
- Coexistence: decide what the CNAPP replaces (native posture services, a separate scanner, a CIEM tool) so you do not pay twice; the CNAPP Guide explains how the components overlap.
- Clean up after the proof of concept: remove bidder roles, tokens and agents from test accounts at the end of each trial and confirm deletion of copied snapshots.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|
| Inventory and posture (4.1) | CM-2, CM-6, CM-8, CA-7 | ID.AM-02, PR.PS-01 |
| Workload vulnerabilities and runtime (4.2, 4.3) | RA-5, SI-3, SI-4, SI-7 | ID.RA-01, DE.CM-09 |
| Entitlements and identities (4.4) | AC-2, AC-6 | PR.AA-05 |
| IaC and pipeline (4.5) | SA-11, CM-7 | PR.PS-01, PR.PS-02 |
| Prioritisation and response (4.6) | AU-6, IR-4 | DE.AE-02, RS.MI-01 |
| Platform and supplier (5) | SA-9, SR-6, SC-28 | GV.SC-05, GV.SC-06 |
Standards and references
Related NHI Mgmt Group resources: CNAPP Buyer's Guide · CNAPP Guide · Cloud Security Guide · PAM RFP Template · Security Vendor Evaluation and RFP Guide