Cybersecurity

SASE RFP Template (Free): Requirements, RFI and Scoring

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.

12 pages Microsoft Word ★ 4 of 5 3241 downloads Updated October 5, 2026
Download Template
SASE RFP Template (Free): Requirements, RFI and Scoring

Preview the first pages

See the structure before you download. The Word file has every section listed below, ready to fill in.

Open preview Give feedback

What's inside

The sections in the document, in order.

  1. How to run a SASE RFP
  2. SASE RFI vs RFP: which do you need?
  3. SASE RFP requirements
  4. Questions to ask SASE vendors
  5. Scoring rubric
  6. Frequently asked questions
  7. Related RFP templates

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.

What’s inside this template

  • A step-by-step plan for running the evaluation, including when a SASE RFI should come first
  • Requirements for SWG, CASB, ZTNA, FWaaS, DLP, SD-WAN and digital experience monitoring, each marked Must-have or Nice-to-have
  • Questions that expose single-vendor versus dual-vendor trade-offs, point-of-presence gaps and roadmap-only features
  • A weighted scoring rubric with 1-to-5 definitions
  • An editable Word RFP with response codes, a pricing table and a timeline

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.

Related analysis on Enterprise Techie: SASE vs SSE, Zscaler vs Palo Alto SASE.

How to run a SASE RFP

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.

  1. Agree on drivers and scope (weeks 1-2). Write down what the platform must replace or consolidate (remote-access VPN, on-premises web proxies, branch firewalls, an existing SD-WAN) and which users, sites and applications are in the first phase. Record the numbers vendors will price against: users, sites, bandwidth per site and private applications.
  2. Assemble the buying team. Include network, security, identity, endpoint and application owners, plus procurement, legal and privacy. Bring privacy in early: SASE inspects user traffic, so decide up front which categories (such as banking and health sites) are exempt from TLS decryption and where logs may be stored.
  3. Settle the architecture, and decide whether you need an RFI (weeks 2-4). Choose between a single-vendor platform and a dual-vendor design that keeps your current SD-WAN and adds an SSE provider. If you're unsure, or your long list has more than five vendors, issue a short RFI first (see below) and use the answers to build a shortlist.
  4. Tailor and issue the RFP (weeks 4-7). Delete requirements that don't apply, adjust priorities, and add your environment details to Section 1. Give vendors three weeks to respond, with a written question-and-answer window in the first week.
  5. Score the responses (weeks 7-8). Have each evaluator score independently against the rubric before comparing notes, and set aside any vendor that misses a Must-have. Check every 'yes' for whether the feature is generally available today or still on the roadmap.
  6. Run a proof of concept with two or three vendors (weeks 8-11). Test with a pilot group, at least one branch and your most sensitive applications. Watch the user experience, how policy treats unmanaged devices, and how quickly an administrator can find out why a user was blocked. Call references of a similar size.
  7. Negotiate and award (weeks 11-12). Use the pricing table to compare like for like. Settle renewal caps, add-on pricing and exit assistance before you sign, not after.

SASE RFI vs RFP: which do you need?

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:

  • Which services (SWG, CASB, ZTNA, FWaaS, DLP, SD-WAN, digital experience monitoring) do you build and operate yourself, and which come from partners?
  • Is your platform single-vendor, or designed to work with third-party SD-WAN?
  • Where are your points of presence, and which services are available in each?
  • What is your pricing model (per user, per site, per bandwidth tier, per module), and what is included in each bundle?
  • How do you handle data residency for traffic inspection and for logs?
  • Which identity providers and endpoint security tools do you integrate with?
  • What does a deployment for an organization of our size involve, and who delivers it?

SASE RFP requirements

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.

Functional

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

Technical and architecture

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

Integration

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

Security and compliance

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

Implementation and support

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

Commercial and pricing

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

Questions to ask SASE vendors

These questions are designed to separate vendors, not to collect brochure answers. Ask for evidence: a demo, a document or a reference.

  1. Which of the proposed services share one policy engine and one data path, and which are separate products or acquired components? How do policies and logs flow between them?
  2. List the points of presence where every proposed service is available, not just some of them. Which are vendor-operated, and which run in a public cloud?
  3. How much latency does inspection add for a user near one of your points of presence, and how do you measure and report it to customers?
  4. A managed laptop becomes non-compliant mid-session. Walk us through what happens to its ZTNA and web access, and how quickly.
  5. What happens to user traffic when the agent can't reach a point of presence? Can fail-open or fail-closed be set per application?
  6. How do contractors and unmanaged devices get access to private applications, and which controls (isolation, DLP, session recording) apply to them?
  7. If we keep our current SD-WAN, how does your SSE integrate with it, and which capabilities would we lose compared with your single-vendor option?
  8. Show one DLP policy applied to a web upload, a SaaS sharing event and a private-application download. Can we reuse our existing data classification labels?
  9. How do you discover and control use of generative AI applications, including sensitive data pasted into prompts?
  10. Demonstrate how your digital experience monitoring isolates whether a slow application is caused by the device, Wi-Fi, ISP, your network or the application itself.
  11. Where are our logs stored, how long are they kept by default, and what does streaming them to our SIEM cost, if anything?
  12. Which features in your proposal are generally available today, and which are in preview or on the roadmap? Give dates for the roadmap items.
  13. What are the most common causes of delay in deployments like ours, and how does your plan address them?
  14. Describe your most significant service outage in the last two years: the cause, the customer impact and what changed afterwards.
  15. Provide a reference customer of similar size and industry that replaced a remote-access VPN with your platform.

Scoring rubric

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

  • 5 Exceeds: meets every Must-have and most Nice-to-haves, shown in a demo or proof of concept, with a matching reference customer.
  • 4 Strong: meets every Must-have and some Nice-to-haves, with clear evidence.
  • 3 Adequate: meets most Must-haves; gaps have a credible workaround or a dated roadmap commitment.
  • 2 Weak: misses one or more Must-haves, or the answer is vague.
  • 1 Poor: does not meet the requirement, or no answer.

Frequently asked questions

What should a SASE RFP include?

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.

What is the difference between a SASE RFI and a SASE RFP?

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.

Should a SASE RFP ask for single-vendor or dual-vendor SASE?

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.

What is the difference between SSE and SASE?

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.

How long does a SASE RFP take?

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.

Related RFP templates

Download Template

More cybersecurity templates