SASE and SD-WAN contract terms explained: deployment timelines, SLAs, licensing models and hidden costs

At Netify, we see four contract areas decide whether a SASE deployment, SD-WAN component included, actually succeeds commercially. The deployment timeline, the SLA and its remedies, the licensing model, and the costs sitting outside the headline quote. Get these wrong and the technology rarely takes the blame. The contract does.

We've written this for a UK IT director, network manager, CISO or procurement lead working from a shortlist of SASE providers, typically across an estate of 20 to several hundred sites, often in a regulated sector, and it covers UK and multinational deployments alike. By the end, you'll know which questions to ask about timelines, service levels, licensing and cost, and which answers we'd consider acceptable before you sign.

Why the contract matters more than the feature comparison

Given the strength of almost all competitors within the SD-WAN and SASE market, we typically find that contracts themselves are becoming a bigger differentiator than the feature set on offer nowadays. The likes of BT, Virgin Media O2, Aryaka, Cato, Colt, Versa, Zscaler, Fortinet and Meraki are usually all capable of the same core capabilities, and the more niche capabilities aren't typically used enough to make them a differentiator on their own. And with every solution offering secure connectivity, cloud-delivered security and centralised policy management, we'd suggest that the differences that can cause problems are all determined in the contract (how quickly sites go live, what happens when the service fails, how the bill scales, and what was never in the quote).

When signing a contract, we'd suggest you take a look at the following four areas, which are increasingly dictating the outcome of your SD-WAN and SASE deployment:

1. The deployment timeline, and what drives it off course.
2. The SLA, what it actually measures, and what happens when it is missed.
3. The licensing model, and how it behaves as the estate grows or shrinks.
4. The costs that sit outside the headline quote.

The contract is usually held with the platform vendor directly, a managed service provider, or a carrier such as BT, Virgin Media O2 or Colt, and which of these changes who owns each area above.

The five phases of a SASE deployment

Regardless of which vendor or platform you choose, we'd note that SASE deployment can be considered as 5 distinct phases:

• Discovery and design: Confirms the site list, circuit inventory and security requirements
• Circuit ordering and delivery: As the name suggests. This is often the longest phase in the UK, since new circuits carry lead times set by the carrier.
• Pilot sites: Test configuration and policy on a small number of locations
• Wave rollout: Builds on pilot sites by bringing the rest of your sites live in scheduled batches.
• Security policy cutover: Moves SWG, CASB and ZTNA policies onto the platform.

What changes the timeline

Regardless of the platform you land on, a handful of factors tend to move a deployment away from that baseline, and site and country count is usually the first one we'd point to. Whether existing circuits can be reused instead of replaced matters too (it's the single biggest source of delay removed in one go if the answer's yes), and so does whether the SD-WAN edge ends up being vendor hardware, a virtual appliance, or a carrier-managed CPE.

Rebuilding security policy, instead of simply migrating it across, is the one we'd flag as most underestimated, particularly where legacy firewall rules have grown informally over years and nobody's quite sure why half of them are still there. Change-freeze windows around peak trading or reporting periods play a part as well, and so does whether the buyer or the provider actually owns project management, which decides how quickly problems get picked up once they show.

Table 1: Deployment phases and timeline drivers

What SLAs should a SASE or SD-WAN contract include?

We'd suggest that a proper SASE or SD-WAN contract needs five SLA metrics defined, no more and no less:

• Service availability
• Performance (latency, jitter and packet loss)
• Time to restore
• Time to provision a new site
• Support response by severity

For each one, you should request a clear definition of what's measured, where it's measured, and what actually happens if the target gets missed.

Availability and uptime commitments

An availability SLA can be measured on the vendor's cloud, the managed device at each site, or end to end including the underlay circuit, and a 99.99% figure means something quite different depending on which one you're looking at.

Cato Networks' Master Service Agreement sets 99.999% against its own network. Aryaka's SLA states 99.99%, but only for site pairs with dual ISP connections, and the circuit itself is covered separately. Similarly, Virgin Media O2 Business's Dedicated Internet Access (DIA) service offers a 6-hour restoration commitment, and BT's BTnet SLA sets a 100% target with credits per hour of downtime. These are all based on entirely different metrics, and though the percentage numbers are easy to gloss over and misinterpret, we'd always recommend that you consider which of these metrics matters to your business most.

Performance metrics: latency, jitter and packet loss

Latency, jitter and packet loss are the three numbers that actually tell you how an application will feel to use, not just whether the connection's technically up. Latency is simply how long data takes to travel between two points, jitter is how much that latency varies, and packet loss is the proportion of packets that never arrive at all. These commitments almost always sit on the provider's own backbone though, not across the internet underlay a site actually uses to reach it. Zscaler's Internet Access SLA, for instance, commits to an average latency of 100 milliseconds or less at the 95th percentile, measured entirely on its own network, not yours.

Time to restore, time to provision and support severity levels

Two different clocks matter here, and it's easy to conflate them: time to restore is how long a provider commits to fixing a fault once you've reported it, and time to provision is how long it commits to getting a brand new site live. Both typically run against a severity scale, from P1 (total loss) through to P4 (minor issue), and the actual numbers behind that scale vary considerably by vendor. Cato, for example, sets a 2-hour response for a multi-site outage, and a UK reseller's published Zscaler terms promise just 30 minutes for its highest tier. It's well worth asking exactly where on that scale your own estate would sit before you sign anything.

Service credits and remedies

A service credit is essentially a reduction against future charges, issued once the provider's confirmed that an SLA target was actually missed, though the structure behind that varies less than you'd think. Across Cato, Versa, Zscaler, BT and Colt, it's usually a percentage of the monthly charge, tiered by how far off the target the provider fell, capped at some maximum, and claimed within a defined window instead of credited automatically.

We'd recommend that you ask specifically for automatic crediting, a cap that's actually meaningful and not just symbolic, and a termination right if breaches keep repeating. Cato and Versa both state outright that the credit is the customer's sole remedy, so we'd always push back on that particular clause during negotiation instead of accepting it as standard.

Table 2: SLA checklist

How is SASE and SD-WAN licensed? Four common licensing models

Four licensing models cover most of the market, in our experience: per site or per edge device with a bandwidth tier, per user for the security service edge components such as ZTNA, secure web gateway and CASB, a bundled managed service on a fixed monthly charge, and an enterprise or consumption agreement built around a committed spend. Most estates end up combining more than one though, and that combination is usually where renewal surprises actually start.

Per-site and bandwidth-tier licensing

Per-site licensing charges according to connectivity capacity per location, not user count. Cato Networks, for example, licenses SD-WAN sites through a bandwidth capacity pool that gets reallocated across sites within the same pricing group, alongside a fixed site licence that's reassignable between locations. This suits estates with stable site counts best.

Per-user licensing for the security service edge

Per-user licensing works the other way round, charging according to how many people are actually using the security service edge functions, independent of site count entirely. Zscaler licenses its Internet Access and Private Access products per user, per year, across separate tiers. It suits a large remote workforce well, though it can lead to overlapping capability being paid for more than once.

Fully managed bundles from carriers and MSPs

A fully managed bundle combines the circuit, hardware, licensing and support under a single monthly charge from a carrier or MSP. Lumen's SD-WAN proposition, built on Versa, is a good example, bundling the cloud instance, CPE and support into one service. UK carriers such as BT, Virgin Media O2 and Colt offer equivalent bundles too, but what's actually included varies quite a bit by carrier, so check the order form line by line instead of assuming parity across providers.

Enterprise agreements and committed spend

An enterprise or consumption agreement sets a committed level of spend or usage across a vendor's range. Zscaler's Enterprise License Agreement is a good example, bundling its top-tier products with advanced data protection and premium support. Fortinet's FortiFlex achieves much the same outcome differently though, with customers drawing down a shared points balance across on-premises, virtual and cloud services instead.

Many buyers, in our experience, end up running per-site licensing for the SD-WAN component and per-user licensing for the security service edge component at the same time, often from two entirely different vendors. Cato's contract includes a true-up clause requiring extra capacity if use exceeds the contracted scope, so tracking both site and user growth separately is what prevents an unplanned increase turning up at renewal. Term length, hardware ownership and site treatment all need checking too, and it's easy to let those slide when the headline pricing looks reasonable enough on its own. One, three and five-year terms are all common, and contracts should state what happens to a licence when a site closes.

Table 3: Licensing models compared 

The hidden costs of deploying SASE and SD-WAN at scale

The costs that most often sit outside the headline quote fall into eight categories, in our experience: underlay circuits and their installation, hardware refresh and spares, professional services, security policy migration effort, licence uplift mid-term, dual running with the legacy WAN, early termination charges on the incumbent contract, and internal project effort. Regulated sectors typically add a ninth on top of that: compliance evidence work that rarely, if ever, appears in the quote itself.

Underlay circuits and their installation are the most concrete category by far. UK carriers, including BT and Openreach, disclose excess construction charges at the site-survey stage whenever new duct or civils work is needed, and the customer can normally cancel at that point without penalty. The initial quote should really be treated as conditional, not final.

Hardware refresh and spares are a contractual obligation as much as a budgeting item. Cato's Master Service Agreement, for instance, requires the customer to replace hardware within 30 days once an update notice's been issued. Professional services and security policy migration rarely get itemised in a quote, despite consistently being the most labour-intensive part of the whole deployment.

Licence uplift mid-term follows the true-up mechanics we've already covered, and dual running is close to a certainty wherever new circuits sit on the critical path. The legacy WAN is very likely still being paid for while a new circuit gets delivered.

Early termination charges on the incumbent contract, and the buyer's own internal project time, are rarely quantified in any vendor document and should really be estimated internally, not left as an afterthought. We'd recommend building a placeholder line for this into any internal budget from day one, since it's the category most often forgotten until renewal catches everyone by surprise. Regulated organisations should add compliance evidence work too: FCA firms must maintain evidence for their important business services, and NHS-connected suppliers must complete an annual DSPT submission, neither of which typically shows up in a standard quote.

Table 4: Hidden cost checklist

Why SD-WAN and SASE projects run late

The most common causes of delay are circuit lead times, incomplete site data, security policy migration taking longer than planned, and unclear ownership between the customer, the MSP and the vendor. Each has a contractual or project-planning response that reduces its impact.

1. Circuit lead times. UK circuit provisioning is frequently the longest phase and is set by the carrier. A contractual site survey before the order surfaces lead-time and construction risk early.
2. Incomplete or inaccurate site data. Missing details on circuits, building access or local contacts cause delays that surface once a site is scheduled. A structured data collection exercise during discovery prevents this.
3. Security policy migration overrun. Rebuilding legacy firewall rules routinely takes longer than the vendor's own estimate. Scoping migration as a distinct, resourced workstream keeps it visible.
4. Unclear ownership across customer, MSP and vendor. Where responsibility is not defined, an issue can sit unresolved. A defined RACI for each phase, agreed before signature, removes the ambiguity.
5. Provisioning delays not covered by an SLA. A provisioning SLA per site, not just a service-level SLA once live, gives a reference point for how long a new site should take.

Netify's article on the operational problems SD-WAN projects run into covers the technical failure modes in more detail. This section covers the delivery and commercial causes of delay, which sit earlier in the process.

A pre-signature checklist for SASE and SD-WAN contracts

Before signing, a buyer should have the following answered in writing, grouped in the order this article has covered them: timeline, SLA, licensing, cost.

1. What is the realistic deployment timeline for our site list, including circuit lead times?
2. Which phase of the deployment carries the most schedule risk for our estate?
3. Does the availability SLA cover the cloud, the site device, or the end-to-end connection including our circuit?
4. What are the latency, jitter and packet loss targets, and where are they measured?
5. How are support severity levels defined, and who decides which level applies?
6. Is the service credit automatic, and what is the maximum credit per billing period?
7. Is the service credit our sole remedy for an SLA failure?
8. Which licensing model applies to the SD-WAN component, and which to the security service edge component?
9. What happens to our licence if a site closes, moves, or our user count changes?
10. What term length applies, and what changes at renewal?
11. Do we own or rent the site hardware, and who owns the refresh obligation?
12. Which costs, beyond the headline quote, should we expect at design, deployment and renewal?
13. What compliance evidence can the provider supply to support our regulatory obligations?

Turning these into a structured requirement set that every shortlisted vendor answers the same way is what Netify's RFP Builder is designed for.

For the vendor selection stage itself, Netify's SASE vendor shortlist and managed SD-WAN shortlist set out the current market by category.

Frequently asked questions

Appendix