3 questions from the package
From the RFI round. The first shows part of the guide each question carries; the workbook adds follow-ups, how to verify the answer, a priority and a weight.
1. Provide the list of log formats your discovery engine parses without a custom parser, mapped against [log sources] with the format version supported for each. For each format, state the fields a log line must contain for app identification and user attribution.
Why it matters. A log source without a native parser either drops out of discovery or depends on a custom parser that the buyer must build and maintain. Its traffic is then missing or unreliable in every shadow IT report.
Good answer
- A published list that names the source product, log format and supported version for each entry
- The vendor marks each of the buyer's [log sources] as native, custom parser or unsupported
- The fields each format must contain for app identification and user attribution are stated
Red flags
- A claim of support for "all major firewalls" with no list
- Support for a listed source depends on paid professional services
- Required log fields are not stated
2. Provide a matrix of [sanctioned apps] against the activities your forward proxy can identify and control in each, such as upload, download, share, post, edit and delete.
Why it matters. If the proxy recognizes only login and whole-app access for an app, the buyer can allow or block that app but cannot stop a specific action such as an upload to it.
3. Provide a matrix of [sanctioned apps] against the session controls your reverse proxy can enforce in each, such as block download, block upload, restrict copy-paste, restrict printing and restrict sharing.
Why it matters. Reverse-proxy support varies by app and by action. If the buyer assumes a control works on an app where it does not, unmanaged devices keep access the buyer believes is restricted.
Capability areas
Shadow IT discovery and app risk catalog (13)
In: ingesting our firewall, proxy and secure web gateway logs; parsing accuracy; the cloud-app catalog and how often it is updated; app risk scoring and its factors; distinguishing corporate from personal instances; continuous discovery reports by user and department. Out: OAuth and app-to-app grants (SSP), GenAI-specific discovery (GAI) and IaaS resource inventory, which belong to cloud security posture tools rather than a CASB.
Inline activity controls (forward proxy) (12)
In: per-app, per-action controls (upload, download, share, post, edit, delete) for sanctioned and unsanctioned apps; instance-aware policy that separates corporate and personal tenants; user coaching, justification and block pages; policy conditions on user, group, device posture and location. Out: how traffic reaches the proxy and how it is decrypted (TLS) and agentless reverse-proxy access (UMD).
Unmanaged device and agentless access (reverse proxy) (9)
In: reverse-proxy session control for unmanaged and BYOD devices through identity-provider redirection; restricting downloads, copy-paste and printing in brokered sessions; URL rewriting reliability on complex SaaS pages; device posture detection without an agent. Out: forward-proxy controls on managed devices (INL).
Traffic steering and TLS inspection (10)
In: steering methods (endpoint agent, PAC file, tunnels from branch equipment); TLS decryption coverage; handling of certificate-pinned and non-browser apps; decryption bypass lists and how bypassed traffic is reported; fail-open and fail-closed behavior; where decrypted content is inspected and whether payloads are stored. Out: global point-of-presence footprint and hosting regions, covered by the deployment-hosting module.
API connectors and at-rest scanning of sanctioned SaaS (12)
In: depth of out-of-band connectors for the sanctioned apps we run; historical and incremental scanning of files, messages and records; remediation actions through the API (quarantine, revoke sharing link, change owner, notify owner); scan latency and behavior under SaaS API rate limits; scanning of cloud object storage where the product offers it. Out: SaaS configuration posture (SSP) and IaaS workload or configuration scanning.
Data protection and classification (13)
In: native detection methods (exact data match, indexed document match, OCR, ML classifiers, custom patterns); one policy enforced in inline, API and endpoint modes; sensitivity-label reading and application; encryption and tokenization of content in SaaS; false-positive tuning and incident evidence handling; at-rest data classification across SaaS and cloud storage. Out: enforcement plumbing for each mode (INL, API, UMD).
SaaS posture and third-party app governance (10)
In: SaaS Security Posture Management checks for misconfigurations in sanctioned tenants; custom checks; remediation guidance and automated fixes; OAuth grants, API tokens and app-to-app connections, with the scopes each grant holds and revocation from the console. Out: IaaS configuration posture, cloud entitlements and workload protection, which this category does not cover.
Generative AI app governance (9)
In: discovery of GenAI apps and AI features embedded in SaaS; risk attributes for AI apps (training on submitted data, retention); inline controls on prompts, pastes and file uploads; instance-aware policy for enterprise versus consumer AI accounts; visibility into AI tools connected by OAuth. Out: governance of AI features inside the CASB product itself, covered by the AI modules.
Threat protection and user behavior analytics (12)
In: malware scanning and sandboxing of files uploaded to and downloaded from cloud apps; detection of malware at rest in sanctioned SaaS; user and entity behavior analytics on SaaS activity logs (impossible travel, mass download, mass deletion, unusual sharing); compromised-account detection; response actions such as session revocation and account suspension. Out: endpoint protection and IaaS runtime detection.
Policy engine and SSE platform fit (9)
In: whether one policy engine, one DLP profile set and one log store serve CASB, web gateway, ZTNA and firewall-as-a-service functions; single-pass versus chained inspection; single endpoint agent; policy simulation before enforcement; policy versioning and rollback; operating as a standalone CASB alongside an existing web gateway. Out: commercial consolidation terms (commercial module) and the vendor's product roadmap (roadmap module).
Incident handling, SOC integration and compliance reporting (12)
In: DLP and threat incident triage workflow; policy exceptions with reason, approver and expiry; ticketing and SOAR integration; streaming CASB events to SIEM and XDR with stable field definitions; role-based administration scoped by app or business unit, including restricted access to sensitive incident content; admin audit trail; compliance reports mapped to the regimes and frameworks we report against, custom frameworks, evidence exports and posture as of a past date. Out: the generic API surface and SSO/SCIM for the console (integration module).
Questions about this package
How many Cloud Access Security Broker (CASB) RFP questions are there?
121 solution questions in 11 capability areas: 25 for the RFI, 61 for the RFP and 35 deep-dive questions for the finalists. The workbook adds 100 due-diligence questions on security, integration, implementation and exit.
What comes with each question?
Why it matters, good-answer signals, red flags, follow-up questions, how to verify the answer (a demo step, a test or a document), and a suggested priority and weight for scoring.
Can I edit the questions?
Yes. The workbook is an ordinary Excel file. Change, add or remove questions, and change the weights; the scorecard recalculates.
Which license do I need?
The Enterprise License covers any number of evaluations inside one organization. The Consultancy License covers use with any number of clients. Neither allows reselling or republishing the questions.
