Paste-ready SASE requirements (SWG, CASB, ZTNA, FWaaS, DLP, SD-WAN), vendor questions that separate platforms, a weighted scoring rubric, and when to run a SASE RFI first.
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 SASE RFP template when you're replacing remote-access VPNs, web proxies or branch firewalls with a cloud-delivered platform that combines SD-WAN networking with security service edge (SSE) capabilities.
It's written for the network, security 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 SASE evaluation involves network, security, identity and endpoint teams at once, so most of the work is agreeing on scope before vendors get involved. The example schedule below runs about 12 weeks from kickoff to contract award; stretch it if your proof of concept covers several sites or regions.
An RFI (request for information) is for learning the market. Use one when you haven't decided between single-vendor and dual-vendor SASE, when you don't know which vendors can serve all your regions, or when your long list is too long to evaluate properly. Keep it short: vendors answer a dozen questions and describe their pricing model, without binding quotes.
An RFP (request for proposal) is for choosing. Issue it once your requirements and shortlist are settled. It asks for commitments: which requirements are met today, firm pricing, service levels and an implementation plan. You can run both, with a two-week RFI to cut a long list to three or four vendors, followed by the RFP in this template.
Questions worth asking in a SASE RFI:
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 | Secure web gateway (SWG) that inspects web traffic for all users on and off the network, including TLS decryption with policy-based exemptions by category, user or destination. | Must-have |
| F2 | Inline cloud access security broker (CASB) controls for sanctioned and unsanctioned SaaS, including activity-level controls (for example, allow viewing but block uploads to personal instances). | Must-have |
| F3 | API-based CASB for our sanctioned SaaS applications, to find exposed data and risky sharing in stored content. | Nice-to-have |
| F4 | Zero trust network access (ZTNA) to private applications, with per-application access decisions based on user identity, group and device posture, without placing users on the network. | Must-have |
| F5 | Re-evaluation of ZTNA access during a session when device posture or user risk changes. | Nice-to-have |
| F6 | Firewall as a service (FWaaS) with layer 3 to 7 policy, application identification and intrusion prevention for branch and remote-user traffic. | Must-have |
| F7 | Data loss prevention (DLP) applied across web, SaaS and private-application traffic from one policy set, with predefined data identifiers and custom dictionaries. | Must-have |
| F8 | Advanced DLP detection such as exact data match, document fingerprinting or optical character recognition for images. | Nice-to-have |
| F9 | Discovery and control of generative AI applications, including policies that block or warn when sensitive data is pasted or uploaded. | Must-have |
| F10 | Threat protection for web and file traffic: malware scanning, sandbox analysis of unknown files and DNS-layer filtering. | Must-have |
| F11 | Remote browser isolation for risky or uncategorized sites and for unmanaged devices. | Nice-to-have |
| F12 | SD-WAN with application-aware path selection across broadband, LTE/5G and MPLS links, and zero-touch provisioning of branch devices. Dual-vendor proposals: describe integration with our existing SD-WAN instead. | Must-have |
| F13 | Digital experience monitoring (DEM) showing device, Wi-Fi, ISP, point-of-presence and application performance per user, so the help desk can locate the cause of slowness. | Nice-to-have |
| ID | Requirement | Priority |
|---|---|---|
| T1 | One management console and one policy model across SWG, CASB, ZTNA, FWaaS and DLP. Identify any service that uses a separate console or policy engine. | Must-have |
| T2 | A single endpoint agent covering web, SaaS, private-application and DEM traffic on Windows, macOS, iOS and Android. State support for Linux and ChromeOS. | Must-have |
| T3 | Agentless, browser-based access to selected private applications for contractors and unmanaged devices. | Must-have |
| T4 | Traffic-forwarding options for sites and devices that cannot run the agent, such as IPsec or GRE tunnels, PAC files and explicit proxy. | Must-have |
| T5 | Points of presence in [list your regions] with every proposed service available at each. List PoP locations and state which are vendor-operated and which are hosted in a public cloud. | Must-have |
| T6 | Automatic failover between points of presence, and configurable fail-open or fail-closed behavior when the service can't be reached. | Must-have |
| T7 | Choice of the region where traffic is inspected and where logs are stored, to meet data-residency requirements. | Must-have |
| T8 | Support for IPv6 traffic in all proposed services. | Nice-to-have |
| T9 | Dedicated egress IP addresses that SaaS applications and partners can allowlist. | 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. | Must-have |
| I2 | Use of device posture signals from our endpoint management and EDR tools in access policy. | Must-have |
| I3 | Streaming of all logs (web, firewall, ZTNA, DLP and administrator audit) to our SIEM in a documented format, plus a REST API for logs and alerts. | Must-have |
| I4 | Integration with our ticketing (ITSM) platform for alerts and DLP incidents. | Nice-to-have |
| I5 | API or infrastructure-as-code support (for example, a Terraform provider) for managing policy and configuration. | Nice-to-have |
| I6 | Ingestion of external threat-intelligence feeds, and export of indicators in standard formats such as STIX/TAXII. | 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, or equivalent regional certifications for public-sector use. Make this Must-have if you are a public-sector buyer. | Nice-to-have |
| S3 | Isolation of our tenant's data, encryption in transit and at rest, and a documented key-management approach. | Must-have |
| S4 | Administrator access through SSO with MFA and role-based permissions, plus an audit log of every configuration change. | Must-have |
| S5 | Configurable log retention, and export of all logs at any time in a usable format. | Must-have |
| S6 | A data processing agreement, a current list of sub-processors, and support for our privacy obligations (for example, GDPR). | Must-have |
| S7 | A contractual commitment to notify us of security incidents affecting our data within a defined time. State the time. | Must-have |
| S8 | Privacy controls for inspected traffic, such as hiding user names in reports or limiting who can view traffic details. | Nice-to-have |
| ID | Requirement | Priority |
|---|---|---|
| M1 | A phased migration plan from our current VPN, proxy and branch-firewall setup, with named roles and the effort expected from both sides. | Must-have |
| M2 | Identification of who delivers the implementation (vendor, partner or both) and the relevant experience of the named team. | Must-have |
| M3 | A service-level agreement for the availability of each proposed service, with service credits. State how availability is measured. | Must-have |
| M4 | 24×7 support for critical issues, with response-time targets by severity. State your targets. | Must-have |
| M5 | Advance notice of platform changes that affect policy behavior or the user experience. | Must-have |
| M6 | A public status page, and root-cause reports for incidents that affect us. | Must-have |
| M7 | Administrator training and documentation, with certification options for our staff. | Nice-to-have |
| M8 | A named customer success contact and periodic service reviews. | Nice-to-have |
| ID | Requirement | Priority |
|---|---|---|
| C1 | Pricing broken down by service or bundle, metric (per user, per site or per bandwidth tier) and term, showing list price, discount and net price. | Must-have |
| C2 | Prices for adding modules or users mid-term, co-terminated with the main agreement. | Must-have |
| C3 | A cap on price increases at renewal. State the cap. | Must-have |
| C4 | Terms that apply if we exceed licensed bandwidth or user counts. | Must-have |
| C5 | Pricing that ramps with the migration phases, so we don't pay for full capacity before it is deployed. | Nice-to-have |
| C6 | A proof of concept at no charge, with the vendor's engineering support. | Nice-to-have |
| C7 | Exit terms covering data export and transition assistance 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 |
|---|---|---|
| Security services coverage (SWG, CASB, ZTNA, FWaaS, DLP) | 25% | Every Must-have met in a generally available release, demonstrated live, with consistent policy across services. |
| Architecture and unified policy | 15% | One console and policy model, few stitched-together components, and a clear account of single- versus dual-vendor trade-offs. |
| Network performance and point-of-presence coverage | 15% | Full services in every region you need, latency evidence, and tested failover. |
| User experience and digital experience monitoring | 10% | A light agent, seamless access, and monitoring that pinpoints where slowness comes from. |
| Integration and operations | 10% | Works with your identity provider, EDR, SIEM and ticketing; usable APIs; fast troubleshooting of blocked access. |
| Implementation and support | 10% | A credible phased plan, an experienced named team, and clear SLAs and support targets. |
| Commercials and total cost | 15% | Transparent pricing, a renewal cap, and fair add-on and exit terms over a three-year view. |
| Total | 100% |
Scoring scale
Your drivers and scope; requirements for each service (SWG, CASB, ZTNA, FWaaS, DLP, SD-WAN and digital experience monitoring) marked Must-have or Nice-to-have; architecture questions about single- versus dual-vendor design and point-of-presence coverage; integration, security and compliance requirements; support and SLA terms; a pricing table; and the rubric you'll score with. This template includes all of them.
An RFI gathers information so you can understand the market and build a shortlist; vendors describe their architecture, coverage and pricing model without binding commitments. An RFP asks a shortlist for committed answers: which requirements are met today, firm pricing, service levels and an implementation plan. Use an RFI when your architecture or long list is still open, then follow it with the RFP.
Decide before you issue it if you can. Single-vendor SASE gives you one console, one agent and one contract. Dual-vendor lets you keep an existing SD-WAN and choose a security service edge (SSE) provider separately, at the cost of two consoles and an integration to maintain. If you're open to both, say so, and require dual-vendor proposals to explain exactly how the two platforms share policy and logs.
Security service edge (SSE) is the security half of SASE: SWG, CASB and ZTNA delivered from the cloud, often with DLP and FWaaS. SASE adds the networking half, SD-WAN, so branch connectivity and security are managed together. If you're only replacing VPNs and proxies for remote users, an SSE RFP may be enough; drop the SD-WAN requirements from this 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 more time if the proof of concept spans several regions, or if legal and privacy review of traffic inspection is new to your organization.
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