Software vendors face data residency and sovereignty requirements when signing customers in specific regions of the world, including the EU. There are many ways to meet these requirements, and Bring Your Own Cloud (BYOC) is one of them. Nuon provides a software platform that enables software vendors to more quickly offer a BYOC deployment option.
The options in this post are things to consider, not advice. Any of them may or may not meet every regulatory need, so do your own research and use your own methods to see what fits you and your customers.
What is Data Residency and Data Sovereignty?
Data residency is the physical or geographical location where a customer's data is stored and processed, meaning their proprietary data and also the metadata and logs that come with running the software.
Data sovereignty is about whose laws govern the data. Data held in a country is generally subject to that country's laws, wherever its owner is based, so vendors and customers have to follow the rules of every place the data sits. Sovereignty also covers who can be ordered to hand the data over, which depends on who controls it: a vendor headquartered in one country can be subject to that country's legal orders for data it controls, wherever the data is stored. Control is the practical side: who holds the encryption keys, and who can get in and when.
How Is It Applied in the EU?
The EU has no blanket rule that data must stay in the EU, but the GDPR limits how personal data leaves it, and customers' own policies and contracts often add more. Some industries and national rules, especially in financial services and the public sector, add further requirements for the vendors they use. In practice it shows up in the customer's review of your product: which region, who operates it, who holds the keys, and who can get in. Requirements range from "keep it in the EU" to "we have to own the account," and regulators rarely choose the architecture for them.
The Many Ways to Meet Data Residency and Sovereignty
The focus of this blog is how Bring Your Own Cloud (BYOC) is one way to meet data residency and sovereignty requirements, but it’s not the only way.
There are several options, and the right one depends on what the customer needs. Many vendors combine two or three.
Customers ask four questions. Where does the data sit? That's residency. Who could be ordered to hand it over? That's sovereignty. Who holds the keys, and who can get in and when? That's control. Each option below answers some of them.
The vendor runs their software in their cloud account
Vendor-hosted region
The vendor creates an instance of their multi-tenant offering, using their cloud account, in a cloud region to serve customers in that region. Implementation and security are decided by the vendor and it’s relatively quick to offer since they have experience with their multi-tenant offering in other regions. It answers the residency need but the customer must trust the vendor that their data is isolated from other customers and security controls are in place.
Vendor-hosted single-tenant
The vendor deploys a dedicated instance of their software, using their cloud account, in a cloud region to serve customers in that region. It answers the residency need and the customer data is isolated from other customer data but the customer must trust the vendor that security controls are in place isolating each single-tenant instance.
By the way, Nuon has software vendors as customers who use Nuon to manage their single-tenant customer fleets, in addition to their BYOC customers.
Things you can layer on top of any approach
Contracts and attestations
Data processing agreements, standard contractual clauses, an EU entity, SOC 2 Type II, ISO 27001 and a trust center. These show how you handle data. They don't change where it sits, who could be ordered to hand it over, or who controls it. They often clear a review, so they're worth having whichever approach you choose.
Customer-managed keys
The customer holds the encryption keys, so the vendor can't read the data without them. This is control. The vendor still runs the service and still holds the account.
The vendor’s software runs in the customer’s cloud account
Self-hosted
The customer installs and runs the software themselves, including on-premises or air-gapped. It answers residency, sovereignty and control. The customer carries the operational work, and the vendor’s team supports it with less visibility. Unfortunately not all SaaS vendors have self-hosted versions of their product, so this option is only available from some vendors.
BYOC
The software runs in the customer's cloud account, and the vendor operates it through a control plane, ideally with access scoped to what's needed. The customer owns the account, the network and the audit trail and still gets a managed service. It answers residency, sovereignty and control. The work sits with the vendor, who needs a repeatable way to install and operate many customer accounts. Nuon is an example BYOC vendor.
BYOC with a regional control plane
In BYOC the customer's data and your software stay in the customer's account, but the control plane that coordinates installs and operations is a separate piece. It holds metadata about each install and the infrastructure logs from changes made to it. If those also need to stay in a region, the vendor can require that the BYOC control plane itself runs there, so the metadata and logs stay in the region the you chose. It answers residency for the control plane's own data, which is easy to overlook, and it sits on top of BYOC's answers on sovereignty and control. Nuon can run its control plane in the region you require, so the metadata and logs stay there.
First Attempt at BYOC
So the software vendor has a large potential customer requesting BYOC or no deal. They create a tiger team project in DevOps or Forward Deployed Engineering to write Terraform and request cross account access to the customer’s cloud account, to deploy their software in a specific region like the EU. The role has wide permissions since it has to provision and destroy resources like a VPC, Kubernetes cluster, database cluster, etc. After the initial installation, the customer has to accept the risk that this role is out there. Cloud logs need to be monitored to see what the vendor is doing, and the role isn’t scoped or reduced to perform less permissive day-2 operations like upgrading the vendor’s software or running health checks.
There's nothing wrong with this approach. Many vendors do it, and it gives them maximum control and permissions, using the tooling and cloud they already know.
Customers can see it differently. It's their cloud account, and they want to know what the vendor can do there, and when. They also want a choice on what cloud provider they can use.
What Good BYOC Looks Like
Whether you build it or buy it, customers tend to look for the same five things.
Access is scoped and can be switched off
Administrative rights should only be granted to provision and deprovision the infrastructure and vendor software, and be reduced after install to what's needed to upgrade, troubleshoot and maintain. If ad-hoc work by the vendor requires elevated permissions, the customer should be able to grant it and take it back, and to turn vendor access on and off. This answers "who can get in, what can they do and when."
Guardrails that warn or block
The vendor’s BYOC solution should include policies as code (Rego, Kyverno) that catch risky settings like a public Kubernetes endpoint, public S3 buckets, SSH open to the world, workloads in system namespaces, unknown registries, destroying a database, or oversized instances. The vendor can share these policies as part of the sales cycle and establish a contract on what they will and will not do in the customer’s cloud.
A record of every change
Every customer install, component upgrade, teardown and script run is logged as evidence in the BYOC platform, so the customer doesn't have to watch cloud logs to see what the vendor did.
Day-2 built in
The hard part of a BYOC solution is what vendors must do after the initial install provisioning for a customer. That work includes health checks for Helm and Kubernetes components, debugging and custom check scripts, scripts combined and turned into runbooks, and telemetry exported to the vendor's or the customer's OTel provider.
Upgrades across many customer installs
Provisioning is table stakes, and upgrading is the hard part. Installs should be grouped, such as review, canary, staging and production, with changes rolling through each group automatically from a git-backed config.
Why Adopt a BYOC Platform?
Building BYOC yourself works, and many vendors start there. A platform tends to make sense when three things show up: the deals, the clouds, and the support load.
Unlock enterprise deals without re-architecting
Selling into the EU often starts with a deal that needs data residency. Standing up a separate SaaS stack for each region is expensive and hard to support, and a one-off BYOC install written for a single deal can take days or weeks. A platform lets you ship a version that runs in the customer's own environment without rewriting your app, so isolation takes minutes instead of a rebuild cycle.
More clouds and more regions
BYOC for the EU usually means regions beyond the US, and often a cloud or region you haven't tested or staffed before. A platform that wraps your existing Terraform and Helm lets you deploy across AWS, Azure, GCP and others from one place, without rewriting provisioning for each new cloud.
Support customers in their own environment
Provisioning is only the start. Once installs of the vendor’s software live in customer accounts across EU regions, the hard part is day-2: observability, policies, controlled rollouts and debugging per-install issues. A platform runs the day-2 items from the checklist above from one control plane, so your team doesn't need a separate ops stack for each install.
Conclusion
Data residency and sovereignty requirements can be met in many ways, and the right one depends on what the customer needs. BYOC is one way to meet them, but it's not the only way. There's nothing wrong with a first attempt at BYOC, and many vendors do it. Nuon provides a software platform that enables software vendors to more quickly offer a BYOC deployment option, without re-architecting your app. See how that works for EU data residency , and we put numbers to the BYOC choice in a blog BYOC Build vs Buy: A Three-Year Cost Comparison . Do your own research and use your own methods to see what fits you and your customers.
Ready to get started?
Deploy your application into customer clouds
See how Nuon can help you unlock BYOC deployment for your entire customer base.