Simply put, and despite claims customers may hear and\/or see in this infant market, the reality is that there is no one-size-fits-all definition to \u201cdata sovereignty\u201d, and the true source of the definition to \u201cdata sovereignty\u201d as applicable to any workload being contemplated is the legal, policy or guidelines applicable to that data that are prescribing it as a requirement.\n\nFor example, a government customer who is planning to acquire cloud services for workloads related to their defence ministry\/department would have different data sovereignty applicable to legal, policy and guidelines than when the same government is acquiring the cloud services for their revenue ministry\/department. And both of those would be different compared to when that same customer is acquiring cloud services for their parks\/forestry ministry\/department. Furthermore, a defence ministry of one government may have different requirements than the defence ministry of another government, and the single defence ministry may have different requirements for two different purchases depending on the workload they are considering. It is therefore understandable that a cloud offering can be compliant with the data sovereignty requirements for one customer workload, but not for another of the same customer.\n\nIn sum, the definition of data sovereignty varies from jurisdiction to jurisdiction, and from workload to workload, even within the same jurisdiction (depending on the applicable laws, policies, or guidelines that are prescribing it as a requirement). That being said, the common denominator amongst most definitions is that data must remain subject to the privacy laws and governance structures within the nation where the data is created or collected. Because the location of data is not, under many jurisdictions, a bar to foreign jurisdictions asserting control over the data, data sovereignty often requires that it remains under the control and\/or management of entities and individuals who cannot be compelled by foreign governments to transfer the data to foreign governments (or, again depending on the requirements, certain foreign governments). As an example of a requirement that may be different, some, but not all, require that the cloud vendor employees who are supporting the underlying infrastructure hold citizenship and security clearance (i.e., data residency and jurisdictional control would not suffice). \n\nThe other important terms to define are as follows:\n\nVMware Sovereign Cloud Initiative\n\nVMware recognizes that regional cloud providers are in a great position to build on their own sovereign cloud capability and establish industry verticalised solutions aligned to differing data classification types and under their nation\u2019s jurisdictional controls.\n\nData Classification is core to understanding where your data needs to reside and the protections that must be in place to safeguard and protect its \u2018sovereignty\u2019 with jurisdictional controls. The VMware Sovereign Cloud initiative has established a framework of trust scale, based on the classification of data which varies by vertical. Examples vary by industry and region, for example, official UK government classifications such as Official, Secret, and Top Secret. Examples from the commercial sector can include Confidential, Internal Use, Public, Sensitive, and Highly Sensitive. The classifications that a Sovereign Cloud Provider chooses to include in the platform by default will depend on a combination of local jurisdictional norms and the type of customers the platform is intended to serve.\n\nThe principle for data classification and trust is that the Sovereign Cloud Provider security can be organised into different trust zones (architecturally called security domains). The higher the classification type, the more trustworthy and sovereign the offering, and the more unclassified the more risk mitigation and safeguards are required (such as encrypting your data, confidential computing, and privacy-enhancing computation). However, there are some hard stops, such as security stopping at the last most secure zone that is always within a sovereign nation and under sovereign jurisdiction.\n\nThe placement of data must be based on the least trusted\/sovereign dimension of service. Assessing your data classification requirements against the proposed services will result in understanding where the data can reside based on the necessary locations and available mitigations. This is an opportunity for VMware Sovereign Cloud partners to overlay solutions. By this, I mean that in many cases, a specific data classification can be placed on a particular platform (or security domain) if certain security controls are in place. E.g., Confidential Data can reside on Shared Sovereign Cloud infra if encrypted and the customer holds their own keys.\n\nUsing this risk and data classification analysis, VMware Sovereign Cloud Providers understand where their proposed Sovereign Cloud offerings sit on the scale, in relation to their other services such as public hyperscale cloud. They can then determine how to shift everything towards the most sovereign dimension of service as necessary using technology and process and enhance a customer\u2019s Sovereign protection and cloud usage.\n\nFor the reasons noted above, VMware Sovereign Cloud providers, using VMware on-premises software, are in an ideal position to build compliant data sovereign hosted cloud offerings in alignment with data sovereignty laws, policies, and frameworks of their local or regional jurisdictions, \u2013 all in a model that is a more optimal approach to assuring jurisdictional control and data sovereignty.\n\nMy thanks to Ali Emadi for co-authoring this article. To read the full article Will the Real Data Sovereign Cloud please stand up? Click here.