In UK procurement the same document is often called an ITT or a tender. The structure, scoring and process on this page apply to both, and the builder serves UK and North American businesses with national or global requirements.
Here at Netify we built our RFP Builder because the same problem kept coming up in SD-WAN procurement, organisations would end up comparing vendor marketing decks rather than structured responses to their actual requirements, making evaluation almost impossible. Our RFP builder changes that, enabling you to produce a complete RFP from our pre-built question library (or by adding in your own custom questions), publishing directly to the providers on your shortlist, and allowing you to receive structured responses you can score module-by-module, all in one place, rather than chasing vendors for comparable answers across separate documents.
Running an RFI first? Use the SD-WAN RFI Builder to gather comparable vendor information and shortlist before you commit to a full RFP.
What the RFP Builder does
The four things the builder handles that are hardest to replicate manually are: producing a complete, structured RFP without starting from a blank document; getting that brief in front of providers in a format they have to respond to consistently (rather than in whatever format they'd prefer); eliminating the inconsistent vendor responses that make side-by-side comparison difficult; and scoring those responses inside the platform so you're not doing it across a spreadsheet you've built yourself.
The question library runs to 115+ standardised professional questions across 13 modular sections, and you toggle sections on or off depending on your project's complexity. If the pre-built questions don't cover something specific to your legacy hardware or compliance situation, the AI assistant drafts bespoke questions, it's trained specifically on SD-WAN procurement rather than being a general-purpose tool, which makes a difference for technical questions that need to be phrased precisely to get useful vendor answers.
The Netify SD-WAN RFP standard
Broadly, we'd argue that an SD-WAN RFP needs to do two things well, define your environment and requirements clearly enough that vendors can respond specifically rather than generically, and structure those requirements into sections that produce comparable answers. The Netify Builder covers 13 modular sections with 115 pre-written questions to that end. The sections you're most likely to toggle on for a standard evaluation are covered below, though regulated sectors (healthcare, financial services, retail) typically need the sector-specific extensions on top of the core set.
Evaluation criteria: what to score vendors on
We often find that the criteria most organisations struggle to evaluate are the ones where vendors can claim capabilities without evidence, something that our structured questions prevent and our builder's weighted questions focus on the specifics rather than the headline claims.
On deployment, the question is zero-touch provisioning capability for rapid site rollout, not whether vendors support ZTP, but what their actual workflow and timeline looks like from hardware delivery to operational status.
For failover, we ask for LTE/5G failover with defined switchover times rather than a general statement of resilience capability, because the threshold is what actually matters when a primary circuit goes down.
Performance questions focus on latency and jitter targets based on real-time application health, which is more useful than bandwidth headline figures for most SD-WAN evaluations.
Security sits in its own module (see SASE & Cybersecurity below) and tends to be the most variable by sector, the standard questions cover robust encryption and TLS inspection capabilities without compromising performance, whilst regulated-sector briefs go further into segmentation, audit logging and inspection points.
Compliance questions focus on regulatory logging with appropriate retention periods that satisfy audit requirements, which is one of the questions vendors answer most differently from one another and where you see real differentiation in what they can actually deliver versus what they claim.
Core modules
Company & Service Model
The mandatory opening module. Covers the supplier's workforce composition, financial stability and accountability models, the things that matter for long-term partnership viability rather than just immediate technical fit. We'd note that this section is where you start to see how vendors approach transparency, which is often a reasonable proxy for how they'll behave once a contract is signed.
Network Footprint
Point of Presence locations, backbone architecture and last-mile strategies. The purpose is confirming whether the vendor's reach actually covers your sites, global footprint claims on a datasheet and verified PoP coverage in the specific regions where your sites sit are different things, and this module forces vendors to be specific.
SD-WAN Capabilities
Technical performance, scalability and traffic routing based on real-time application health. This is typically the most heavily weighted module for a standard SD-WAN evaluation and the one where vendor responses diverge most significantly, particularly on how they handle dynamic path selection and how they evidence it rather than just describing the architecture.
SASE & Cybersecurity
Requirements for converging networking and security, covering SSE, ZTNA, cloud-delivered firewalls and deep packet inspection. Whilst SASE and SD-WAN are increasingly sold together, it's worth using this module to establish whether the security stack is native to the platform or a bolt-on, because the answer significantly affects how the two function in practice. Vendors who can't answer the inspection point and logging questions in detail usually can't deliver the integration either.
SLAs & Change Management
Measurable uptime, latency and jitter targets, alongside clear procedures for MACDs. This module is where a lot of RFPs fall short, vendors are good at publishing headline SLA numbers but less forthcoming on what actually happens during Moves, Adds, Changes and Deletes in a live environment. The questions here are designed to surface that.
Custom Questions (AI Powered)
The AI Helper drafts bespoke technical or commercial questions for requirements that sit outside the standard library, legacy hardware constraints, unique compliance needs, or anything specific to your environment that the pre-built questions don't cover. It's the part of the builder we find most useful for organisations with non-standard infrastructure, where generic RFP templates tend to leave gaps.
Implementation & Governance
Detailed migration methodologies and project plans, plus regulatory compliance for your sector. Given this is where SD-WAN rollouts most commonly stall, not in the technical specification phase but in the implementation, it's worth weighting this module more heavily than most RFP templates do by default.
Sector-specific SD-WAN RFP questions
SD-WAN evaluation requirements vary substantially by industry and, given this, an un-tailored RFP will typically fall short of what your business actually needs. To help with this, we've built sector-specific question libraries for the four sectors where we see the most variation, healthcare, retail, manufacturing and financial services. These sit on top of the core question set rather than replacing it.
- Healthcare RFPs need to ask about clinical system availability, patient data isolation and NHS DSPT alignment, none of which tend to show up in a standard commercial RFP.
- Manufacturing environments bring OT network considerations that a standard RFP simply won't cover: segmentation between IT and OT, and resilience at sites where downtime doesn't just inconvenience people but halts production outright.
- Financial services RFPs typically prioritise regulatory compliance mapping and low-latency requirements for trading or transaction systems above most other things.
Healthcare: Clinical System Availability & Patient Data Isolation
Healthcare RFPs, more than most, tend to live or die on three things that a generic template simply won't think to ask about: clinical system availability, patient data isolation, and NHS DSPT alignment. It's worth pushing vendors on segmented traffic policies with auditable tracking here, since clinical, guest and IoMT traffic all genuinely need to stay separate rather than just labelled differently on a diagram somewhere. How resilient access holds up across different site types is worth asking about too, given a GP surgery and an acute trust site carry very different uptime requirements from one another, and clinician remote access specifically is worth digging into, because that's usually where patient data isolation ends up breaking down once you look closely. NHS DSPT alignment, in particular, should come with actual evidence attached rather than a general claim of "healthcare experience" that doesn't really mean very much on its own.
Retail: POS / Payment Resilience & Rapid Rollout
An SD-WAN RFP for retail should prioritise POS and payment resilience, rapid store rollout capability and cardholder data security controls, the questions that matter here are quite different from the questions that matter for a multi-site office environment. Specifically, the four things we'd recommend retail evaluations focus on are zero-touch provisioning for rapid store deployment (the volume of sites in retail makes manual provisioning impractical), LTE/5G failover with defined switchover times (because a failed payment terminal during peak trading is a direct revenue loss), central policy management that scales across hundreds of sites without proportional management overhead, and clear evidence of PCI DSS segmentation capabilities rather than a general claim of compliance.
Manufacturing: OT/IT Segmentation & Plant Floor Resilience
A manufacturing RFP needs to go somewhere that office-focused templates simply don't: OT/IT segmentation, industrial protocol support, and resilience on the plant floor itself, rather than just in the server room. The segmentation question probably matters most out of all of these, since a breach on the IT side genuinely shouldn't be able to reach OT, full stop, no exceptions. Beyond that, it's worth checking whether the vendor actually supports the industrial protocols already running on your floor today, rather than accepting a vague "IoT-ready" claim at face value, and asking specifically how they handle legacy hardware that can't simply be swapped out for something newer. Resilience in this context isn't really about inconvenience in the way it might be for an office - downtime on a production line is a genuinely different category of problem entirely, and it's worth treating it as such.
Financial Services: Regulatory Compliance & Low-Latency Resilience
Financial services buyers tend to need three things that most RFP templates miss entirely: explicit regulatory compliance mapping, encryption that satisfies audit requirements without adding meaningful latency, and defined resilience thresholds for branch or trading-adjacent sites specifically. A general compliance statement shouldn't really be accepted here, so it's worth asking for mapping against the specific framework you're actually regulated under, FCA, PCI-DSS, or whatever else applies to your particular situation. Regulatory logging with proper retention periods is worth checking in detail too, since it's genuinely one of the areas where vendor capability varies most in practice, regardless of what the sales deck happens to claim.
Frequently asked questions
What should an SD-WAN RFP include to compare providers fairly?
The short answer is that it needs to request structured, comparable evidence rather than capabilities claims, unstructured means that vendors might answer questions in two incomparable ways, leaving you unable to determine who is the better fit for your needs. We would argue that the key difference between a good RFP and a weak one is almost always whether vendors are forced to answer specific technical questions about your environment and whether you've minimised the risk of them responding with marketing content rather than direct, evidence-based claims. To help avoid this, we'd strongly recommend that you define your environment first, then build questions that require evidence of how vendors would handle your specific sites, circuits and security requirements.
How do I evaluate SD-WAN and SASE capabilities together in an RFP?
SASE is the SSE security stack (typically FWaaS, CASB, SWG, ZTNA) with SD-WAN for access capabilities, therefore evaluations for these go hand-in-hand, and so by including security requirement modules that force vendors to provide technical evidence of their combined networking and security capabilities within a single framework, you can evaluate each in one go rather than separating SD-WAN and SASE evaluation. We'd also note that where a vendor's SASE offering is a bolt-on rather than a native integration, it often becomes apparent very quickly when you ask for specific evidence of policy enforcement, inspection points and logging, which can be useful if you're looking for a solution that's built with security in mind from the ground up.