When SASE was first introduced, the whole idea was to deliver networking and security services through a globally distributed cloud architecture. But what started as a cloud-delivered security model has evolved to cover a much broader range of customer requirements, particularly around data sovereignty and regulatory compliance.

Today, SASE comes in several deployment models, ranging from fully cloud-delivered services to solutions hosted entirely on customer-owned infrastructure, and everything in between. Much of that evolution is driven by organizations and governments demanding more control over three things: where their data is stored, where security inspection takes place, and who ultimately operates the infrastructure.

The challenge is that many of these very different architectures get marketed under the same “Sovereign SASE” label. So in this post I compare six SASE deployment models, look at where their core components reside and who operates them, and map them against five progressively stricter requirements on what I call the SASE Sovereignty Scale.

Free resource: download the one-page SASE Deployment Models cheat sheet (PDF). It has all six models on the SASE Sovereignty Scale, the three core components, a checklist for buyers and security teams, and links to every chapter of the video. The full list of research sources is on the SASE Deployment Models resources page.

New to SASE? Start with What Is SASE? Secure Access Service Edge Explained and What Is Sovereign SASE?

The Three Core Components of a SASE Architecture

Before comparing deployment models, you need to know the three core components of a typical SASE architecture:

Control plane: manages and orchestrates the solution, including security policies, authentication, posture checking, tunnel orchestration and which security PoP users connect to.
Data plane: where security inspection happens. Secure Internet Access enforces firewall policies and inspects traffic, and Secure SaaS Access capabilities such as CASB and DLP inspect and control access to cloud applications.
User data and logs: security logs, telemetry, customer configurations, captured files and metadata that can contain personally identifiable information.

For many organizations, where data and logs are stored is one of the first questions when choosing a SASE deployment model. As we go through the models, focus on two things: where these three components reside, and who actually operates them.

The three core SASE components: the control plane (security policies, authentication, posture checking), the data plane (firewall policies, traffic inspection, cloud app access control) and user data and logs (security logs, telemetry, personal data in metadata) — From the video at 1:40

Cloud SASE and the SASE Sovereignty Scale

Traditional Cloud SASE was designed around a globally distributed security architecture. The control plane resides in the vendor’s cloud, and security inspection is delivered through a global network of points of presence (PoPs) spread across geographically redundant locations. Users connect to a nearby PoP, where their traffic is inspected before it reaches its destination.

Meanwhile, logs and telemetry are typically sent back to the vendor’s logging infrastructure, which may sit in an entirely different country or region. That matters, because where data is stored, processed or accessed can introduce additional compliance and legal requirements.

To compare the architectures, I rank them on the SASE Sovereignty Scale from Level 1 to Level 5. Each level represents a progressively stricter requirement around where data is stored, where security processing takes place, and who controls the underlying infrastructure.

Level 1: Cloud SASE

Traditional Cloud SASE sits at Level 1. The vendor owns and operates the entire infrastructure: the control plane, the security PoPs and the logging services.

At Level 1 there are no specific geographic restrictions on where inspection happens or where data is stored. Users can connect to PoPs in different countries, and data can cross international borders as long as the appropriate security and legal safeguards are in place.

Interestingly, several major frameworks, including GDPR, HIPAA, PCI DSS and NIS2, don’t impose a general requirement that all data stay within a particular country. That means traditional Cloud SASE can still meet the compliance needs of many organizations, including some in heavily regulated industries.

But location isn’t the whole story. Remote access to personal data by a third-party provider in another country may itself count as an international data transfer. That’s where additional sovereignty requirements start to matter.

Level 2: Data Residency

Level 2 adds a data residency requirement, which is usually offered as an add-on to an existing Cloud SASE service. The architecture stays largely the same: the control plane still runs in the vendor’s cloud, and users can still connect to PoPs around the world.

The key difference is where customer data is stored. At Level 2, logs, telemetry and potentially other customer information must stay within a specific geographic region. This is relevant for organizations facing stricter data-jurisdiction rules. For example, DORA requires financial institutions to identify where their data is processed and stored in certain technology contracts, and some countries impose more explicit localization requirements for certain types of personal data.

There’s an important distinction here: data residency is not the same as log residency. A vendor may offer regional log storage while customer configurations, metadata and some telemetry are still stored or processed in the control plane, which could be hosted in a different region. Know exactly what the vendor’s residency offering covers, and what may still be processed elsewhere.

Level 3: In-Country Processing

Level 2 controls where data is stored, but not where security inspection happens. Level 3 adds in-country security processing: inspection is restricted to PoPs within a specific country instead of the vendor’s global network. Logs and customer data must also stay within the required jurisdiction, and depending on the vendor, the control plane may stay in the vendor’s global cloud or be hosted in-country too.

This is particularly relevant for government and other regulated environments. Take Germany: GDPR regulates international data transfers, yet there’s growing demand among German organizations to keep sensitive data and processing within Germany for additional sovereignty protection. Like Level 2, this depends on the vendor having infrastructure in the required country, and it’s commonly sold as additional licensing or a dedicated service.

But even if the whole SASE stack is hosted in-country, it’s still a cloud service operated by a third party. You have to consider not only local law, but also whether the vendor’s home jurisdiction could impose additional legal obligations or access requirements. If you need independence from foreign service providers, in-country hosting alone may not be enough.

The Customer-Hosted PoP

The next option extends traditional Cloud SASE: you deploy security devices in your own infrastructure, such as a data center or HQ, which turns that location into an additional SASE PoP. Inspection for specific traffic or workloads happens locally instead of at the vendor’s cloud PoP.

That’s useful for large campuses, data centers and locations where the vendor has no nearby PoP, and it can improve performance by cutting the latency of sending traffic to a distant inspection point.

But a customer-hosted PoP isn’t a sovereignty or data-privacy solution on its own. It’s simply another inspection point inside the vendor’s global infrastructure. The control plane stays in the vendor’s cloud, and logging, software maintenance and access to the global PoP network still depend on the vendor. You change where some inspection happens, not who controls it or where the rest of your traffic and data reside. That’s why, by default, it stays at Level 1 on the scale.

Levels 4 and 5: Sovereign SASE

Level 4 introduces a fundamentally different architecture: Sovereign SASE. Unlike the previous models, Sovereign SASE lets most or even all of the SASE infrastructure be hosted in your own environment. You own and operate the security PoPs, the log storage and potentially the control plane.

One of its key advantages is the flexibility to choose where each component resides, and the biggest decision is the control plane. Depending on the vendor, it can stay in the vendor’s cloud or be deployed on your own infrastructure.

Level 4, cloud-managed control plane: security inspection and customer data stay on-premises, while the control plane is delivered as a cloud service. You get the speed and simplicity of SaaS for the most complex part of the architecture, with the core components on your premises.
Level 5, fully self-hosted: the control plane moves on-premises as well, removing the dependency on a vendor-hosted service for day-to-day operations. The entire SASE stack is hosted, maintained and operated by the organization, with no cloud dependency or connectivity required. This is relevant for national-security environments, critical infrastructure and organizations with strict operational sovereignty requirements.

Of course, greater control means greater responsibility. At Level 5 you maintain the management infrastructure yourself, including its availability, resiliency, software updates and ongoing operations. And for environments that need even more isolation, fully disconnected or air-gapped deployments sit at the far end of Level 5.

Sovereign SASE Level 4: the control plane runs in the vendor cloud while customer-hosted PoPs and user data and logs run in the customer's data centers and HQ — From the video at 9:20

Choosing a “Sovereign Enough” SASE Deployment Model

Looking at the complete SASE Sovereignty Scale, there are a few important takeaways:

The levels are customer requirements, not a security ranking. A higher level isn’t a better or more secure SASE deployment model.
Different architectures can meet the same requirement. If you need security inspection to stay within a particular country, you might meet that with an in-country Cloud SASE service or a fully customer-operated Sovereign SASE solution.
You don’t need a more restrictive architecture to satisfy a less restrictive requirement.

That brings us back to Gartner’s recommendation in How to Choose a Sovereign SASE Deployment Model: select a “sovereign enough” deployment model. The objective isn’t to reach Level 5. It’s to identify the level of control your organization actually requires, then pick an architecture that meets it without adding unnecessary cost, complexity or operational responsibility.

And remember, geography is only one consideration. Depending on your requirements, who operates the infrastructure, who has administrative access, and where the control plane resides can matter just as much.

The full SASE Sovereignty Scale: Level 1 fully cloud, Level 2 data residency, Level 3 in-country processing, Level 4 customer-operated and Level 5 full on-prem control, with all six SASE deployment models mapped to it — From the video at 11:30

SASE Deployment Models at a Glance

Level 1, Cloud SASE: the vendor runs the control plane, PoPs and logging, with no geographic restrictions.
Level 2, data residency: logs, telemetry and customer data stay in a region. Check what the control plane still processes elsewhere.
Level 3, in-country processing: inspection and data stay in-country, but a third party still operates the service.
Customer-hosted PoP: local inspection and better performance, but not a sovereignty control on its own (Level 1 by default).
Level 4, Sovereign SASE with a cloud-managed control plane: inspection and customer data stay on-premises.
Level 5, fully self-hosted Sovereign SASE: the control plane moves on-premises too, up to air-gapped deployments.

FAQ

What are SASE deployment models? They are the different ways a SASE solution can be delivered, from fully vendor-operated Cloud SASE to fully customer-hosted Sovereign SASE, defined by where the control plane, data plane and user data and logs reside and who operates them.

What is the difference between Cloud SASE and Sovereign SASE? In Cloud SASE the vendor owns and operates the control plane, PoPs and logging. In Sovereign SASE most or all of that infrastructure is hosted in the customer’s own environment, with the control plane either cloud-managed (Level 4) or self-hosted (Level 5).

Is data residency the same as data sovereignty? No. Data residency controls where logs and customer data are stored. Sovereignty can also depend on where inspection happens, who operates the service, who has access to it, and where the control plane runs.