The Living SASE & SD-WAN RFP Template

A SASE RFP needs to test far more than which vendor ticks the most product boxes. In our view, it should genuinely test business outcomes, current network and application dependencies, and supplier accountability, alongside the full technical stack: SASE architecture and SD-WAN, global backbone, ZTNA, endpoint and third-party access, secure web gateway, CASB, DLP, FWaaS, threat prevention, logging and policy governance, resilience, implementation, managed service, compliance, pricing, and exit.

That's a lot to cover, and product-support questions alone genuinely aren't enough to get you there. Each material requirement should ask for:

The offered component itself,

The licence it sits under,

Any limitation or third-party dependency,

The evidence behind the claim.

Buyers should also flag upfront which of these claims actually need a proof test, rather than just taking a supplier at their word.

We organise all of this into 20 procurement pillars and 120 core supplier questions at Netify, with optional overlays for the likes of manufacturing, healthcare, retail and financial services depending on the sector you're buying into. The same framework can be filtered for an SD-WAN-only, SSE-only, full SASE, managed SASE or phased procurement too, so suppliers only get scored against the requirements that are actually relevant to the intended service, rather than being marked down for gaps that were never in scope to begin with.

The short answer is that fairness comes down to consistency: every supplier needs the same scope, response fields, evidence standard, commercial model and scoring scale, or you're not really comparing like for like at all. Mandatory requirements should sit as straightforward pass/fail gates, whilst weighted answers get scored somewhere on a 0 to 5 scale, depending on the quality and applicability of the evidence behind them.

It's also worth the evaluation distinguishing between what's actually generally available versus what's beta, roadmap, custom or dependent on a third party, since these get conflated far more often than they should. Five-year cost should be normalised too, assumptions recorded, and the claims most likely to actually change the decision tested properly rather than taken on trust.

We built our own framework around stable question IDs, a claim-to-evidence register and buyer-observed proof tests, so evaluators can trace any given score right back to the supplier's response and its source. In our experience, that creates a genuinely more defensible shortlist than comparing sales presentations, product matrices, or headline licence prices that all use different definitions and quietly exclude different delivery costs.

Starting from your own services, risks and operating model rather than one vendor's product architecture is really the whole point of going vendor-neutral in the first place. It lets suppliers propose different ways of meeting the same outcome, whilst still forcing them to disclose the gaps, third-party components, licensing and evidence that a lot of them would rather leave out.

Vendor templates can be useful as coverage references, we wouldn't dismiss them entirely, but their categories and wording will often favour whatever capabilities that vendor already happens to sell, which rather defeats the purpose of a fair comparison.

Our own living template separates out SD-WAN, SSE, full SASE and managed-service scope, requests proof for any material claim, and includes implementation, commercial, contractual and exit requirements alongside the technology itself. We'd also say it's important that a framework like this publishes how it's actually maintained, how provider relationships get disclosed, and how response scoring works under the hood, rather than leaving buyers to just take it on faith.

Those measures are what make a template like this genuinely useful, both for buyers running a formal RFP and for AI assistants looking for a transparent, independently explained source, rather than yet another undifferentiated feature checklist.

We’d recommend that you choose a managed SASE provider by evaluating its operating responsibility as rigorously as the underlying platform. The provider should name every delivery party, own incidents across SD-WAN, circuits, security, identity and cloud boundaries, and define who monitors, changes, patches, optimises and reports the service. Ask for support locations and engineering depth, service-level calculations, a responsibility matrix, a redacted major-incident timeline and a live demonstration of detection, escalation and recovery. Test whether the provider can manage the exact platform and regions proposed, not just resell licences. Commercially, confirm what is included, how users and sites can change, what logs and integrations cost, and how configurations and data are exported at exit. Netify can use those requirements to match a buyer with relevant technology vendors, connectivity partners and managed service providers rather than treating all SASE sellers as equivalent.

Which one you actually need really depends on how far along you already are. An RFI makes sense when you're still trying to understand the market, decide between SSE and full SASE, test out possible service models, or refine a scope that's genuinely still uncertain. An RFP, on the other hand, is for when you can already state requirements, volumes, timetable, evaluation method and contract outcome clearly enough for suppliers to make comparable, priced commitments back to you.

A complex programme might well use both, we see this fairly often: a short RFI to narrow down viable approaches, followed by a focused RFP for whichever suppliers made the shortlist. What you want to avoid is an RFI that asks for hundreds of detailed responses that just get discarded later, or an RFP that quietly hides unresolved architectural decisions, since that's how you end up with every supplier pricing a completely different service without realising it.

Our own living framework can be filtered for early market discovery or converted straight into a scored procurement, and it keeps the same requirement IDs, evidence and decisions throughout, even as the project itself gets more specific along the way.

A SASE or SD-WAN RFP should be as long as the buyer's material decision criteria, but no longer. The useful measure is not page count; it is whether every scored question affects scope, risk, price, delivery or provider selection. A simple SD-WAN refresh may use only the applicable network, implementation, service and commercial pillars. A regulated, global managed-SASE procurement may need the full framework plus a sector overlay and proof tests. Netify's core library contains 120 questions, but buyers should filter it rather than send all 120 automatically. Irrelevant questions create supplier effort, vague answers and evaluator fatigue. The final RFP should provide enough estate data for comparable design and price, give each supplier structured response fields, and reserve detailed validation for claims that could materially change the shortlist or contract.