Paste-ready CASB requirements (shadow IT discovery, API and inline controls, DLP, generative AI, unmanaged devices, SSPM), vendor questions that separate products, and a weighted scoring rubric.
See the structure before you download. The Word file has every section listed below, ready to fill in.
The sections in the document, in order.
Use this CASB RFP template when you need to find out which cloud applications your users rely on, control how they use them, and protect sensitive data in your sanctioned SaaS applications, with controls for generative AI tools and unmanaged devices. In 2026, CASB is often bought as one part of a security service edge (SSE) or SASE platform, alongside a secure web gateway and zero trust network access, so the requirements work whether you buy it on its own or as part of a wider platform.
It's written for the security, identity and procurement team running the evaluation, and it covers the whole process: when to issue an RFI first, the requirements to send, the questions that separate vendors, and how to score the answers.
Download the editable Microsoft Word version below. Every requirement, vendor question and scoring weight on this page is in the document, ready to tailor and send.
A CASB evaluation involves security, identity, endpoint and network teams, plus the owners of your main SaaS applications, and the first decision is whether you're buying a standalone CASB or the CASB part of an SSE or SASE platform. The example schedule in this template runs about 12 weeks from kickoff to contract award; allow more if privacy review of content scanning is new to your organization.
Each line is written to paste straight into your RFP. Must-have means a vendor that cannot meet it is out; Nice-to-have earns extra points. Change the priorities to fit your situation, and delete what doesn't apply.
| ID | Requirement | Priority |
|---|---|---|
| F1 | Discovery of the cloud applications in use (shadow IT) from inline traffic, the endpoint agent and uploaded firewall or proxy logs, showing for each application the users, devices, data uploaded and downloaded, and the trend over time. | Must-have |
| F2 | A catalog of cloud applications with a documented risk rating for each, based on attributes such as security certifications, data handling and retention terms, encryption, SSO and MFA support, and known security incidents. We must be able to override ratings and add our own attributes. State how often ratings are reviewed and how new applications are added. | Must-have |
| F3 | Marking of applications as sanctioned, tolerated or unsanctioned, and policy by status, category or risk rating, including blocking an application or steering users to a sanctioned alternative. | Must-have |
| F4 | Inline activity-level controls for cloud applications: allow, block, warn or require a business justification for each activity (such as sign-in, upload, download, share, post, edit and delete), by user, group, device type and location. Every policy can run in monitor-only mode before it is enforced. | Must-have |
| F5 | Instance awareness: different policy for our corporate instance of an application and for personal or third-party instances of the same application (for example, allow uploads to our corporate file-sharing tenant but block uploads to personal accounts), and, where the application supports it, restriction of sign-in to our approved tenants. | Must-have |
| F6 | API-mode controls for our sanctioned SaaS applications [list]: scanning of stored content and sharing, including content created before deployment; monitoring of user and administrator activity; and remediation actions such as quarantining a file, removing public or external sharing links, revoking access, changing ownership and notifying the file owner. State which capabilities are supported for each application. | Must-have |
| F7 | Data loss prevention (DLP) applied inline and in API mode from one policy set, with predefined identifiers for regulated data (such as payment card, national ID and health data), custom dictionaries and patterns, file type rules, and an incident workflow with severity, evidence and case status. | Must-have |
| F8 | Advanced DLP detection such as exact data match, document fingerprinting, optical character recognition for images and scanned documents, and trainable classifiers. | Nice-to-have |
| F9 | Use of the sensitivity labels from our data classification tools in DLP policy, and policy actions that apply labels or encryption to sensitive files in sanctioned applications. | Nice-to-have |
| F10 | Discovery, risk rating and control of generative AI applications, including policies that block or warn when sensitive data is pasted or uploaded into prompts, and separate policy for our approved enterprise instances of these applications. | Must-have |
| F11 | Threat protection: malware scanning of files uploaded and downloaded inline and of files stored in sanctioned applications, with sandbox analysis of unknown files. State any part that needs a separate product. | Must-have |
| F12 | Detection of compromised accounts and risky user behavior in sanctioned applications, such as sign-ins from unusual locations, mass downloads, deletions or external sharing, and unusual administrator activity, with response actions that can run automatically. List the actions available. | Must-have |
| F13 | Controls for unmanaged and personally owned devices that access sanctioned applications: detection that the device is unmanaged, and restricted policy such as browser-only or read-only access and blocked downloads. State whether this uses a reverse proxy, browser isolation or another method, and which of our applications it supports. | Must-have |
| F14 | User coaching: customizable messages that explain why an action was blocked or flagged, capture a business justification, and let the user request an exception. | Must-have |
| F15 | SaaS security posture management (SSPM): continuous checks of the security settings in our sanctioned applications against published benchmarks and our own baselines, with alerts on configuration drift and step-by-step remediation guidance. List the applications covered. | Nice-to-have |
| F16 | Discovery of third-party applications, add-ons and AI assistants or agents connected to our SaaS applications through OAuth grants or API tokens, showing the permissions each holds, with the ability to revoke them. | Nice-to-have |
| ID | Requirement | Priority |
|---|---|---|
| T1 | State whether the CASB is a standalone product or part of an SSE or SASE platform. Identify which capabilities (inline CASB, API-mode CASB, secure web gateway, ZTNA, DLP and SSPM) share one console, one policy engine and one endpoint agent, and which are separate products. | Must-have |
| T2 | Inline enforcement for users on and off the network through an endpoint agent on Windows, macOS, iOS and Android (state support for Linux and ChromeOS), plus PAC files, explicit proxy or IPsec/GRE tunnels for sites and devices that can't run the agent. | Must-have |
| T3 | TLS decryption with exemptions by category, application or user group, and documented handling of applications that use certificate pinning, desktop sync clients and mobile apps. List the applications bypassed by default. | Must-have |
| T4 | API connectors that use the least-privileged permissions each application allows, with documented permission scopes, service-account requirements, and handling of each application's API rate limits for large tenants. | Must-have |
| T5 | For each sanctioned application, a statement of whether API-mode monitoring uses event notifications or periodic scans, the expected delay between an event and a policy action, and how the first full scan of existing content is scheduled and throttled. | Must-have |
| T6 | Points of presence in [list your regions] with inline CASB available at each, and a choice of region for inspecting traffic and for storing logs, incident evidence and scanned metadata. | Must-have |
| T7 | Automatic failover between points of presence, and configurable fail-open or fail-closed behavior when the service can't be reached. | Must-have |
| T8 | Log-based discovery without an agent: a log collector we can run on-premises or in our cloud environment, or direct upload, accepting logs from our firewalls and proxies [list], with an option to pseudonymize user names and IP addresses in discovery reports. | Must-have |
| T9 | Dedicated egress IP addresses that our SaaS applications can allowlist, so sign-in to sanctioned applications can be limited to traffic that has passed through the CASB. | Nice-to-have |
| ID | Requirement | Priority |
|---|---|---|
| I1 | Single sign-on with our identity provider via SAML 2.0 or OIDC, with user and group provisioning via SCIM, so policy can use our groups and attributes. | Must-have |
| I2 | Use of device signals from our endpoint management (MDM/UEM) and EDR tools, such as device certificates and posture, to tell managed devices from unmanaged ones in policy. | Must-have |
| I3 | Streaming of all logs (application discovery, activity, DLP incidents, threat alerts and administrator audit) to our SIEM via syslog/CEF, API or cloud storage in a documented schema, plus a REST API for alerts and incidents. State whether OCSF is supported. | Must-have |
| I4 | Integration with our SOAR and ticketing (ITSM) tools, so DLP incidents and alerts open tickets and playbooks can call remediation actions such as quarantining a file, removing a sharing link or blocking an application. | Nice-to-have |
| I5 | If we keep our current secure web gateway or firewall, export of unsanctioned applications as block lists those products can enforce. | Nice-to-have |
| I6 | API or infrastructure-as-code support for managing policies, application lists and configuration. | Nice-to-have |
| ID | Requirement | Priority |
|---|---|---|
| S1 | A current SOC 2 Type II report and ISO/IEC 27001 certification covering the proposed services, available under NDA. | Must-have |
| S2 | FedRAMP authorization at the required impact level, and FIPS 140-3 validated cryptography in agents and the service. Make this Must-have if you are a public-sector buyer or a contractor that needs them. | Nice-to-have |
| S3 | A statement of what content and metadata from our SaaS applications and traffic the service stores (such as file copies, matched text and file metadata), where, for how long and how it is encrypted, with options to mask matched data in incident records and to keep incident evidence in storage we control. | Must-have |
| S4 | Protection of API connector credentials and tokens: stored encrypted, rotatable, limited to the documented permissions, and revocable by us at any time. | Must-have |
| S5 | Administrator access through SSO with MFA, role-based permissions that limit who can see incident content and user identities, and an audit log of every configuration change. | Must-have |
| S6 | Configurable retention of logs and incidents, and export of all of them at any time in a usable format. | Must-have |
| S7 | A data processing agreement, a current list of sub-processors, support for our privacy obligations (for example, GDPR), and a contractual commitment to notify us of security incidents affecting our data within a defined time. State the time. | Must-have |
| S8 | Willingness to sign the agreements our regulations require where the service will process regulated data, such as a HIPAA business associate agreement. | Nice-to-have |
| S9 | A published vulnerability disclosure process and committed timelines for fixing security flaws in the endpoint agent and any components we host, such as log collectors. | Must-have |
| ID | Requirement | Priority |
|---|---|---|
| M1 | A discovery and design phase that delivers, in writing, a shadow IT baseline report, recommendations for sanctioning applications, a connection plan for API mode and an initial policy set. | Must-have |
| M2 | A phased rollout plan that moves each policy from monitor-only to user coaching to enforcement, by application and user group, with criteria for each step and time set aside for DLP tuning. | Must-have |
| M3 | Identification of who delivers the implementation (vendor, partner or both) and the named team's experience with CASB deployments of a similar size. | Must-have |
| M4 | A service-level agreement for availability of the inline service and for API-mode processing, with service credits. State how each is measured. | Must-have |
| M5 | 24×7 support for critical issues, with response-time targets by severity. State your targets. | Must-have |
| M6 | Advance notice of changes that affect policy behavior or the user experience, and prompt notice when a SaaS provider's API change degrades a connector, with a target time to restore it. | Must-have |
| M7 | A public status page, and a written root-cause report for any incident that affects us. | Must-have |
| M8 | Training for administrators, security analysts and the help desk, plus a named customer success contact and periodic service reviews. | Nice-to-have |
| ID | Requirement | Priority |
|---|---|---|
| C1 | Pricing broken down by metric (such as per user) and term, showing list price, discount and net price. State whether inline mode, API mode, log-based discovery, SSPM, advanced DLP and browser isolation are included or priced separately. | Must-have |
| C2 | The number of API-connected applications included, the price for each additional application, and any limit on the volume of data scanned. | Must-have |
| C3 | Prices for adding users, applications or modules mid-term, co-terminated with the main agreement. | Must-have |
| C4 | A cap on price increases at renewal, covering the subscription and any add-ons. State the cap. | Must-have |
| C5 | Credit for existing CASB licenses if we move to the vendor's SSE or SASE bundle during the term. | Nice-to-have |
| C6 | A proof of concept at no charge, including a discovery report from our own logs and the vendor's engineering support. | Nice-to-have |
| C7 | Exit terms covering export of the application inventory, policies, incidents and logs, transition assistance, removal of API access, and written confirmation that our data has been deleted at the end of the contract. | Must-have |
These questions are designed to separate vendors, not to collect brochure answers. Ask for evidence: a demo, a document or a reference.
Score each criterion from 1 to 5, multiply by its weight, and add the results. The weights below are a starting point; agree on your own before any proposals arrive so the scoring can't be bent around a favorite.
| Criterion | Weight | What a strong response shows |
|---|---|---|
| Inline and API-mode SaaS controls | 25% | Activity-level, instance-aware inline controls, API coverage for every sanctioned application you listed, and remediation actions shown working in the proof of concept. |
| Data protection (DLP) | 15% | One DLP policy across inline and API modes, reuse of your classification labels, and acceptable accuracy on your own sample files. |
| Shadow IT and generative AI discovery | 10% | A useful discovery report from your own logs or traffic, risk ratings you can understand and override, and quick addition of new generative AI applications to the catalog. |
| Platform architecture and SSE fit | 15% | A clear account of what shares one console, agent and policy with the web gateway and ZTNA, working controls for unmanaged devices, and full service in every region you need. |
| Integration and operations | 10% | Works with your identity provider, endpoint tools, SIEM and ticketing; usable APIs; and analysts can investigate an incident quickly. |
| Implementation and support | 10% | A phased plan from monitoring to enforcement, an experienced named team, and clear SLAs and support targets. |
| Commercials and total cost | 15% | Transparent pricing for API connectors and add-ons, a renewal cap, fair exit terms, and a three-year view that includes any move to a wider SSE bundle. |
| Total | 100% |
Scoring scale
Your scope (the sanctioned SaaS applications you want to protect, the users and devices in scope, and whether you're buying a standalone CASB or part of an SSE or SASE platform); requirements for shadow IT discovery, inline and API-mode controls, DLP, generative AI controls, threat protection, unmanaged devices and SaaS posture, each marked Must-have or Nice-to-have; questions about application coverage and data handling; security, support and SLA terms; a pricing table; and the rubric you'll score with. This template includes all of them.
A CASB discovers and controls the use of cloud applications and protects the data in them. Security service edge (SSE) combines CASB with a secure web gateway (SWG) and zero trust network access (ZTNA), usually with shared DLP, one agent and one console, and SASE adds SD-WAN networking to SSE. In 2026, CASB is often bought as part of an SSE or SASE platform; standalone and API-only CASB products still exist and can suit buyers who mainly need to protect data in a few sanctioned SaaS applications. If you're also replacing web proxies or remote-access VPN, use the RFPhub SASE or ZTNA template alongside this one.
API-based CASB connects directly to a sanctioned application's APIs: it sees data already stored there, including content created before you deployed it, and can remove risky sharing or quarantine files, but it acts after the event and only covers applications it has a connector for. Inline CASB sits in the traffic path, through an endpoint agent, a forward proxy or a reverse proxy, so it can stop an upload or a risky action as it happens and can control unsanctioned applications too, but it sees only traffic that passes through it. A CASB RFP should normally ask for both, with one DLP policy across them.
A CASB controls how people use cloud applications and protects the data in them. SaaS security posture management (SSPM) checks how the applications themselves are configured, such as sharing defaults, MFA enforcement and administrator rights, and flags settings that drift from your baseline. Some SSE platforms offer SSPM alongside API-mode CASB, so this template lists it as a Nice-to-have; if posture is your main concern, see the RFPhub SSPM template.
The example schedule in this template runs about 12 weeks from kickoff to contract award, including three weeks for vendor responses and three to four weeks for a proof of concept. Allow longer if privacy review of content scanning is new to your organization, or if each SaaS application owner must approve API access. Rolling out enforcement follows the award and moves in phases, from monitoring to user coaching to blocking.
Paste-ready requirements for finding and securing service accounts, API keys, tokens, workload identities and AI agents, with vendor questions, a scoring rubric…
Paste-ready ZTNA requirements (per-app policy, device posture, agent and agentless access, connectors, VPN migration), vendor questions that separate products, and a weighted…
Paste-ready requirements for immutable backup storage and cyber recovery vaults (object lock, isolation, multi-person approval, clean-room recovery), vendor questions and a weighted…
Please provide your feedback below.
"*" indicates required fields