SASE and SSE bids all claim the same acronyms, ZTNA, SWG, CASB and FWaaS, so an RFP that asks "do you support ZTNA?" cannot separate a platform that will retire your VPN from one that will break half your applications on day one. This template is a ready-to-issue request for proposal for secure access service edge (SASE) or security service edge (SSE) platforms, with numbered requirements that can be verified in a proof of concept and scored. It covers zero trust network access, secure web gateway, cloud access security broker, firewall as a service, data protection, SD-WAN where SASE is in scope, point of presence (PoP) coverage and performance, migration from VPN, the security of the platform itself, services and commercials. It is vendor-neutral and written for network and security architects, procurement and evaluation panels. For how the market is structured, read the SASE and SSE Buyer's Guide; for the architecture, the SASE and SSE Guide.
How to use this template
- Replace text in square brackets, such as [Organisation], [regions] and [number], with your own details. If you are buying SSE only, delete section 4.6 (SD-WAN).
- Each requirement has an ID (for example SSE-ZTN-03) and a type: M mandatory (pass or fail), S scored (0 to 5, weighted) or I informational.
- Weights, volumes, latency targets and timings in brackets are illustrative, not benchmarks. Set them 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.
- Align identity requirements with the Workforce SSO and Access Management RFP Template if you are buying both, because ZTNA policy is only as good as the identity signals it receives.
1. Purpose and scope
[Organisation] invites proposals for a [SASE / SSE] platform and implementation services. The platform must give users, devices and workloads access to private applications, SaaS and the internet based on identity, device posture and policy rather than network location, inspect traffic for threats and data loss, and replace [remote access VPN / legacy web proxy / branch firewalls] on a planned timeline.
- Capabilities in scope: ZTNA for private applications; SWG; CASB (inline and API); FWaaS; data loss prevention; digital experience monitoring; [SD-WAN and branch connectivity]; [remote browser isolation].
- Users and locations: [number] employees, [number] contractors and third parties, [number] branches and [number] data centres across [regions].
- Out of scope: [data centre east-west segmentation]; [customer-facing application delivery]; [OT networks].
- Drivers: [VPN appliance vulnerabilities and patching burden]; [cloud and SaaS migration]; [hybrid working]; [consolidating proxy, CASB and VPN tools]; [zero trust programme].
- Contract term: [three] years with an option to extend by [two] years.
2. Organisation background and current state
| Item | [Organisation] value |
|---|
| User locations | [countries and approximate user numbers per country, including any with internet restrictions] |
| Private applications | [number] web, [number] non-web (SSH, RDP, thick-client, UDP, VoIP); hosting [data centres, cloud providers] |
| Current remote access | [VPN product, number of concurrent users, split or full tunnel] |
| Current web and SaaS security | [proxy, CASB, DLP products]; TLS inspection [yes, partial, no] |
| Identity providers and device management | [IdP]; [MDM or UEM]; [EDR] |
| Endpoints | [operating systems and numbers]; unmanaged devices and BYOD [allowed or not] |
| Branch network | [number] sites; current WAN [MPLS, internet, SD-WAN] |
| Logging | [SIEM]; retention [period]; data residency requirements [regions] |
3. Instructions to bidders
- Timeline: RFP issued [date]; clarification questions by [date]; responses due [date, time, time zone]; demonstrations [dates]; proof of concept [dates]; decision [date].
- Single point of contact: [name, email].
- Response scale: available now; available with configuration; third-party product required (name it); roadmap (committed date); not supported. State whether each capability is delivered from the same PoPs, client and policy engine, or from a separately acquired or partner product.
- PoP evidence: provide a list of PoPs that perform full inspection (not only traffic on-ramp), by city, with whether each is owned or hosted on a third-party cloud.
- Architecture: diagram showing client, connectors, PoPs, policy engine, logging and where customer data, logs and TLS keys are processed and stored.
4. Functional requirements
4.1 Zero trust network access (ZTNA)
| ID | Requirement | Type |
|---|
| SSE-ZTN-01 | Provides per-application access to private applications with no network-level access; users cannot see or reach applications they are not authorised for. | M |
| SSE-ZTN-02 | Supports web and non-web protocols, including [SSH, RDP, SMB, thick-client TCP, UDP, VoIP], and server-initiated connections where needed. | M |
| SSE-ZTN-03 | Policy uses identity and group from [IdP], device posture from [MDM, EDR] and context (location, risk), and is re-evaluated during the session, not only at login. | M |
| SSE-ZTN-04 | Application connectors make outbound-only connections, require no inbound firewall rules, and authenticate to the platform with credentials that can be rotated and revoked. | M |
| SSE-ZTN-05 | Provides clientless browser access for unmanaged devices and third parties, with controls on download, copy and print. | S |
| SSE-ZTN-06 | Discovers applications in use through the platform to help build per-application policy from a broad initial rule. | S |
See the ZTNA Guide.
4.2 Secure web gateway (SWG)
| ID | Requirement | Type |
|---|
| SSE-SWG-01 | URL and category filtering, malware and threat inspection, sandboxing of unknown files, and DNS-layer protection. | M |
| SSE-SWG-02 | TLS inspection at scale with selective bypass by category (for example health and finance), certificate pinning exceptions, and stated performance impact. | M |
| SSE-SWG-03 | Controls access to generative AI services: discovery, allow or block by application and tenant, and prompt and upload inspection for sensitive data. | S |
| SSE-SWG-04 | Remote browser isolation for uncategorised or risky sites. | I |
See the Secure Web Gateway and Web Filtering Guide.
4.3 Cloud access security broker (CASB)
| ID | Requirement | Type |
|---|
| SSE-CAS-01 | Discovers SaaS in use (shadow SaaS) with risk ratings, from inline traffic and log ingestion. | M |
| SSE-CAS-02 | Inline controls distinguish corporate from personal tenants of the same SaaS application and enforce activity-level policy (upload, share, delete). | S |
| SSE-CAS-03 | API-based scanning of [named SaaS platforms] for data exposure, misconfiguration and third-party OAuth app grants. | S |
See the CASB Guide and the Shadow SaaS and Unsanctioned App Discovery Guide.
4.4 Firewall as a service (FWaaS)
| ID | Requirement | Type |
|---|
| SSE-FWS-01 | Layer 3 to 7 firewall policy for all ports and protocols for users and branches, with application identification and intrusion prevention. | S |
| SSE-FWS-02 | Deny by default with explicit allow rules; rules reference users and groups as well as addresses. | M |
4.5 Data protection
| ID | Requirement | Type |
|---|
| SSE-DLP-01 | One DLP policy applied consistently across web, SaaS inline, SaaS API and private application traffic, with exact data match and document fingerprinting for [data types]. | S |
| SSE-DLP-02 | Integrates with [existing classification labels and DLP] rather than requiring a second policy set. | S |
See the Data Loss Prevention (DLP) Guide.
4.6 SD-WAN and branch (SASE only)
| ID | Requirement | Type |
|---|
| SSE-WAN-01 | SD-WAN appliances or virtual edges with path selection, link failover and zero-touch provisioning, managed from the same console and policy as SSE. | S |
| SSE-WAN-02 | Supports branch traffic steering by IPsec or GRE from existing routers and firewalls where SD-WAN is not replaced. | M |
4.7 PoP coverage, performance and resilience
| ID | Requirement | Type |
|---|
| SSE-POP-01 | Full-inspection PoPs within [latency target, for example 20 to 30 milliseconds] of [percentage] of users in each country in section 2; state any countries served from outside the country. | M |
| SSE-POP-02 | Availability commitment of [percentage] for the data plane with service credits; describe failover between PoPs and client behaviour on PoP failure (fail open or closed, configurable). | M |
| SSE-POP-03 | Traffic and logs for [regions] processed and stored only in [regions] where required; egress IP addresses localised to the user's country. | S |
| SSE-POP-04 | Digital experience monitoring of device, network path and application performance per user. | S |
4.8 Client, operations and logging
| ID | Requirement | Type |
|---|
| SSE-OPS-01 | A single endpoint client for ZTNA, SWG and posture on [operating systems], deployable silently through [MDM], with tamper protection and staged update rings controlled by [Organisation]. | M |
| SSE-OPS-02 | Single console and policy model across capabilities; policy changes are versioned, reviewable and can be rolled back. | S |
| SSE-OPS-03 | Streams all access, threat and DLP logs to [SIEM] in near real time with documented schemas. | M |
| SSE-OPS-04 | Full configuration available by API and infrastructure as code. | S |
The platform becomes the gateway to every application and decrypts most traffic, so its own security is scored as heavily as its features.
| ID | Requirement | Type |
|---|
| SSE-SEC-01 | Administrators authenticate through [Organisation] SSO with phishing-resistant MFA; granular admin roles; all administrative actions logged. | M |
| SSE-SEC-02 | Describe how TLS inspection keys and decrypted content are protected, how long content is retained, and who at the bidder can access it. | M |
| SSE-SEC-03 | Connector, API and tunnel credentials are scoped, rotatable and revocable; list every credential the platform holds for [Organisation] systems. | M |
| SSE-SEC-04 | Provide a current independent assurance report, a [SIG or CAIQ] response, the vulnerability disclosure policy, and the history of security vulnerabilities and incidents affecting the client, connectors or cloud service over the last three years, with time to patch. | M |
| SSE-SEC-05 | Documented break-glass access to critical applications if the platform or the IdP is unavailable. | M |
6. Migration, services and support
- VPN migration plan: propose phases with exit criteria, for example [pilot group on web applications, then non-web applications, then third parties, then VPN decommission by [date]]; state how users with applications not yet migrated keep access.
- Policy conversion: describe how existing proxy rules, VPN access groups and firewall rules are analysed and converted, and how broad initial rules are narrowed to per-application policy.
- Coexistence: describe running alongside the current VPN and proxy during migration without routing conflicts.
- Team and references: named roles and [two or three] references that have fully retired VPN for a comparable user base.
- Support: tiers, severity targets, release cadence, and advance notice of PoP and client changes.
See the CISA Zero Trust Maturity Model Guide to set migration targets by maturity stage.
7. Commercials
| Cost element | What to state |
|---|
| Licence metric | Per user, per device, per site or bandwidth; how contractors, third parties and service traffic are counted |
| Modules and bundles | Which section 4 requirements are in the base bundle and which need add-ons (DLP, isolation, API CASB, DEM, SD-WAN) |
| Bandwidth and PoPs | Any bandwidth caps, premium PoP or dedicated egress IP charges |
| Hardware | SD-WAN appliances, connectors and their support |
| Implementation and training | Fixed price or day rate by phase |
| Growth, renewal and exit | Price for [growth percentage] more users; renewal cap; assistance at exit |
8. Evaluation method and proof of concept
| Criterion | Weight | Evidence |
|---|
| ZTNA and VPN replacement (4.1, 6) | [25%] | Proof of concept with real applications |
| SWG, CASB, FWaaS and DLP (4.2 to 4.5) | [20%] | Proof of concept, demonstration |
| Performance and PoP coverage (4.7) | [15%] | Latency measured from user locations |
| Platform security and operations (4.8, 5) | [15%] | Assurance reports, architecture review |
| Life-cycle cost (7) | [25%] | Three-year cost including add-ons |
Scored requirements use 0 to 5: 0 not met; 1 roadmap only; 3 met with configuration or third-party product; 5 met natively and demonstrated. The proof of concept of [number] weeks with [number] pilot users in at least [three] countries will cover at minimum:
- Access to [three] private applications, including one non-web and one server-initiated, with no inbound firewall rules, and denial for an unauthorised user.
- Session re-evaluation: change a pilot device to non-compliant in [MDM or EDR] and confirm access is removed within [minutes].
- Clientless third-party access to one web application from an unmanaged device with download blocked.
- TLS-inspected web access with category bypass, a blocked malware test file and a DLP block on a seeded test record, including to a generative AI service.
- Corporate versus personal tenant control for [one SaaS application].
- Latency and throughput measured from each pilot country, compared with the current VPN.
- PoP failover and client fail-open or fail-closed behaviour, and logs arriving in [SIEM].
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Test the hard applications: web applications work on every platform. Put your oldest thick-client, UDP or server-initiated application in the proof of concept, because that is what keeps VPNs alive.
- Measure from where users are: PoP maps show on-ramps. Measure latency and egress location from your actual user countries, including any with restricted internet.
- Ask what is native: a single client, policy engine and data plane are easier to operate than bundled products. The response scale in section 3 forces bidders to say which capability comes from where.
- Treat connectors as identities: ZTNA connectors and API integrations are non-human identities with broad reach. Record them, rotate their credentials and remove proof-of-concept connectors at the end. See the Service Account Security Guide.
- Plan the VPN exit: set a decommission date and track the number of users and applications still on VPN as the migration metric.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A |
|---|
| ZTNA and remote access (4.1) | AC-17, SC-7(5) | PR.AA-03, PR.AA-05 | A.6.7 Remote working; A.8.20 Networks security |
| SWG and FWaaS (4.2, 4.4) | SC-7, SC-7(8) | PR.IR-01 | A.8.23 Web filtering; A.8.22 Segregation of networks |
| CASB and DLP (4.3, 4.5) | SC-8 | PR.DS-02 | A.8.12 Data leakage prevention |
| Logging and monitoring (4.8) | AU-6, SI-4 | DE.CM-01 | A.8.16 Monitoring activities |
Standards and references
Related NHI Mgmt Group resources: SASE and SSE Buyer's Guide · SASE and SSE Guide · ZTNA Guide · NIST SP 800-207 Zero Trust Architecture Guide · Security Vendor Evaluation and RFP Guide