Share via

Evaluate sovereign requirements

  • Article

The Microsoft Cloud Adoption Framework for Azure is a full lifecycle framework that helps cloud architects, IT professionals, and business decision-makers to achieve their cloud adoption goals. It provides best practices, documentation, and tools that help to create and implement business and technology strategies for the cloud. Public Sector organizations that have strict sovereignty requirements can incorporate their sovereignty objectives into their planning efforts, so that strategic decisions about cloud adoption are aligned with those sovereignty requirements.

This article highlights areas where organizations may want to evaluate, identify, and document their sovereignty requirements, and provides recommendations for where these requirements may fit into their broader planning efforts associated with the Cloud Adoption Framework for Azure.

Identify sovereign data

Data sovereignty requirements can include mandates to retain ownership of data and specify methods for the storage, usage, and transmission of data. Sometimes, data sovereignty requirements may also include limitations or mandates regarding data residency. Understanding these requirements early in an organization's cloud journey can help establish common design patterns for data sovereignty, rather than expecting workload owners to develop solutions for addressing sovereignty requirements.

Organizations that follow the Cloud Adoption Framework for Azure identify candidate workloads to migrate to the cloud during the planning phase and then design the environment to host these workloads during the readiness phase. These activities can allow an organization to identify sovereign data types that require special handling in the target-state cloud environment.

Microsoft uses many types of data, such as personal information that is provided to Microsoft and customer data that is uploaded into cloud services to deliver online and professional services. Microsoft's data protection responsibilities are documented in the Microsoft Products and Services Data Protections Addendum (DPA) and included in an organization's agreements with Microsoft. The DPA specifies the different data types that Microsoft manages and describes the practices used by Microsoft to protect those data types.

Many organizations have existing data governance programs that specify requirements for handling sensitive data and can use this information to determine if data sovereignty requirements apply to all or only a subset of data classifications. When an organization uploads and maintains its data in a cloud service, it is their responsibility to accurately classify, label, and manage the data following their data handling requirements. Some organizations may want to use cloud adoption as an opportunity to review its data classification programs.

For more information on how data classification applies to cloud adoption, see Data classification in Azure and Cloud governance guides.

Examples of data sovereignty requirements

Organizations that have strict data sovereignty requirements may have to plan for some of the following representative scenarios when they migrate workloads to the cloud.

Data classification labeling

Classification labels identify resources with special handling requirements. While classification labels are applied to documents, they can also be applied to assets. Customers can use the native tagging features in Azure to apply classification labels to resources such as compute services and data stores and for logical structures in Azure, such as subscriptions and management groups.

For more information, see Tagging in Azure and Microsoft Purview eDiscovery solutions.

Data classification boundaries

When an organization chooses to aggregate data (or applications) of a similar classification, a security perimeter is often deployed to serve as the boundary of the location where data storage is allowed. When customers deploy workloads in Azure, they can use subscriptions and management groups to create logical boundaries within the organization's cloud environment. These boundaries help mitigate confidentiality risks related to unauthorized access and privacy risks related to data aggregation and attribution.

Organizations that have strict data sovereignty requirements may want to consider whether they want to organize their environment in a hierarchical model, where higher levels of privileges inherit lower levels of privilege (for example, as in the Bell-LaPadula model), or if they prefer to implement a nonhierarchical model where mandatory access controls are used to create boundaries that compartmentalize parts of the environment from the rest of the environment. Decisions about how an organization manages data classification boundaries are crucial while designing Landing Zones in the readiness phase of the Cloud Adoption Framework for Azure.

For more information, see Management Groups in Azure and Data governance.

Data residency

Organizations that must meet data residency requirements should pay special attention to which Azure services they need to support a workload, and where those services are geographically available. Azure services are deployed in regions that support low-latency network connections and features like availability zones. These regions are grouped into geographies, which provide extra resiliency and disaster recovery features.

If an organization needs to maintain data residency for its workload, it needs to ensure that the Azure services that are used are available in its preferred region and geography. Additionally, some services are deployed globally and don't offer data residency within a given region or geography for the data stored within that service.

For more information about Data Residency, Azure regions and availability zones, and regional availability of Azure services, see the following articles:

Ownership, custody, and portability of data

Customers with strict data sovereignty requirements often have many questions about who retains ownership of data stored in Azure, who can access that data, and what happens to that data if a customer chooses to move their workload to another platform. These requirements can vary in scope and specificity, but they usually tend to be related to the fundamental question of what happens to data when you host it in a Microsoft cloud service.

To help address these questions at a high level and give customers a starting point for identifying their data sovereignty requirements that apply to cloud service providers, Microsoft has published a series of articles about protecting and managing customer data that addresses many of these questions, and those articles are available online in the Trust Center.

For more information, see Data management at Microsoft.

Maintain operational sovereignty in the cloud

Operational sovereignty requirements can affect how an environment in Azure is designed, updated, and managed. Hence, it's important to have a clear understanding of these requirements before technical designs are finalized as part of the readiness phase of the Cloud Adoption Framework for Azure. Common operational sovereignty requirements may include:

  • Limitations on the location and nationality of administrative staff.
  • Access control requirements that limit privileged access by cloud service providers.
  • Mandates for high availability and disaster recovery.

It's important to clearly understand the intent and the risks that these requirements mitigate since many of these requirements are met in the cloud using different methods than are commonly used on-premises.

After the organization identifies the operational sovereignty requirements, they can select the appropriate technical and administrative sovereignty controls to provide the right level of risk mitigation and assurance. When selecting sovereignty controls, it's important to understand that selecting some capabilities that can provide extra operational sovereignty limits an organization's options for adopting other Azure services.

For example, an organization that requires confidential computing for its Azure workloads have to limit its architecture choices to services that can run on Azure Confidential Computing, such as Confidential Virtual Machines or Confidential Containers. For this reason, it's often a good idea to associate operational sovereignty requirements with a given data classification, rather than adopting an approach where all workloads and data must meet the most restrictive set of sovereignty requirements.

Additionally, some operational sovereignty requirements, like Autarky (for example, being able to run independently of external networks and systems) are infeasible in hyperscale cloud-computing platforms like Azure, which rely on regular platform updates to keep systems in an optimal state.

Examples of operational sovereignty requirements

Some common operational sovereignty requirements along with examples of relevant Azure services and capabilities that may address those requirements are as follows:

Software security

Software security requirements can include development activities, such as applying specific cryptographic safeguards, conducting code reviews, and performing application security and penetration testing. It can also include operational processes, such as the implementation of access controls, use of encryption technologies, and monitoring security events.

Microsoft provides various capabilities to help customers meet operational sovereignty requirements for Microsoft-developed and customer-developed software. Microsoft follows the Secure Development Lifecycle (SDL) when developing platform-level software for Azure. The 12 practices of the SDL are incorporated into Microsoft's engineering processes and procedures and are assessed regularly as part of Microsoft's assurance activities. Additionally, Microsoft provides capabilities to help customers adopt the Secure Development Lifecycle practices as part of their software development lifecycle.

For more information, see Microsoft Secure Development Lifecycle and Secure Development Best practices on Azure.

Infrastructure security

Workloads that run on Azure can take advantage of the many features that Microsoft has developed to assure the platform's integrity. The features include its firmware, software, and host infrastructure. Organizations may have operational sovereignty requirements to isolate their data from cloud operators. Azure provides capabilities that customers can use to take advantage of the agility and resilience of the public cloud while maintaining isolation from cloud service providers and their administrative staff. Organizations with requirements related to hardware-level attestation, software integrity verification (for example, secure boot), and secure key management can review Microsoft's platform integrity and security practices and access audit documentation to validate the implementation of these features.

For more information, see Platform integrity and security and Azure infrastructure security.

Encryption for data-at-rest, data-in-transit, and data-in-use can help satisfy a wide range of operational sovereignty requirements related to data confidentiality and privacy. However, organizations that require these features need to plan for the creation and management of encryption keys. Azure provides a wide range of data-at-rest encryption models for customers to choose from, from client-side encryption methods that provide zero-knowledge encryption for data hosted in the cloud to service-managed keys that offer the highest degree of interoperability with native cloud services.

Additionally, organizations that wish to minimize the need for trust in platform components like the Host OS, kernel, hypervisor, and administrative staff can implement data-in-use encryption. Azure Confidential Computing includes several compute services that are deployed in hardware-based security enclaves that encrypt data in-memory using Intel Software Guard Extensions (SGX) or AMD Secure Encrypted Virtualization (SEV-SNP).

Organizations with operational sovereignty requirements that require implementing encryption should become familiar with the following encryption features in Azure:

Operations and resiliency

Operational security requirements can apply to both platform-level software created and managed by Microsoft to operate the Azure platform and customer-managed software that is part of a workload. The shared responsibility model for cloud computing shifts administrative responsibility from the customer to the cloud service provider. Depending on the type of cloud service that is being consumed, Microsoft may be responsible for managing and updating the bare-metal infrastructure in our datacenters, operating systems, and service run times. Microsoft's security engineering organization implements an operational security program that builds on the practices from the Microsoft Secure Development Lifecycle (SDL) with operational security practices. The practices include secrets management, penetration testing, and security monitoring, implemented by the Microsoft Security Response Center.

In rare cases, Microsoft may require access to customer data to troubleshoot an issue that may impact services. Customers with operational sovereignty requirements related to change control and privileged access management may want to enable Customer Lockbox for Azure so that they can approve the access requests as part of Microsoft's support workflows.

Moreover, customers with strict requirements for approval and scheduling of platform software updates may want to consider Azure Dedicated Hosts, which allows customers to use Maintenance Configurations to control host-level platform maintenance activities. Additionally, customers should review their resiliency requirements to determine if there are any sovereignty-based limitations on the services and regions that are used to host workloads.

Operational sovereignty requirements around continuity of operations (for example, requiring workloads to be deployed in highly available configurations to maintain uptime) may conflict with data sovereignty requirements related to data residency (for example, restricting workloads to a geographic boundary that doesn't offer diverse locations).

Organizations should evaluate these requirements early and consider the best way to balance these requirements.