Data Sovereignty and Residency Policies

Data Residency Policy Enforcement: GDPR Compliance Automation

While often used interchangeably, these terms have distinct meanings. Data Residency refers to the physical or geographic location where data is stored. Data Sovereignty is a broader concept stating that data is subject to the laws and legal jurisdiction of the country in which it is located. For compliance, you achieve sovereignty by controlling residency. Policy as Code is the most effective way to technically enforce these geographical restrictions on your cloud resources.

Geographic Data Policies: AWS Location-Based Implementation

In AWS, the most powerful tool for enforcing data residency across all accounts in your organization is a Service Control Policy (SCP). SCPs act as guardrails that can restrict the permissions of IAM users and roles, including the root user, in member accounts.

Example: SCP to Allow Only EU Regions

This SCP denies access to any action outside of the specified European regions. It's a "deny list" approach, which is safer as new AWS regions won't be accessible by default.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllOutsideEU",
            "Effect": "Deny",
            "NotAction": [
                "iam:*",
                "organizations:*",
                "route53:*",
                "support:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                        "eu-central-1",
                        "eu-west-1",
                        "eu-west-2",
                        "eu-west-3",
                        "eu-south-1",
                        "eu-north-1"
                    ]
                }
            }
        }
    ]
}

Location Based Resource Policies: Azure Data Sovereignty Guide

Azure Policy is the ideal service for this. You can create a policy definition that contains a list of approved regions and assign it at a high-level management group. This ensures all subscriptions beneath it inherit the rule.

Example: Azure Policy to Allow Only Canada Regions

This policy audits or denies the creation of any resource whose location is not `canadacentral` or `canadaeast`.

{
  "properties": {
    "displayName": "Allowed locations for resources",
    "policyType": "BuiltIn",
    "description": "This policy enables you to restrict the locations your organization can specify when deploying resources.",
    "mode": "Indexed",
    "parameters": {
      "listOfAllowedLocations": {
        "type": "Array",
        "metadata": {
          "description": "The list of locations that can be specified when deploying resources.",
          "strongType": "location",
          "displayName": "Allowed locations"
        },
        "defaultValue": [ "canadacentral", "canadaeast" ]
      }
    },
    "policyRule": {
      "if": {
        "not": {
          "field": "location",
          "in": "[parameters('listOfAllowedLocations')]"
        }
      },
      "then": {
        "effect": "deny"
      }
    }
  }
}

Cloud Data Residency Rules: Google Cloud Implementation

Google Cloud's Organization Policy Service provides a built-in constraint specifically for managing resource locations, making this a very straightforward task.

Example: GCP Policy to Allow Only Australian Regions

Using the `gcp.resourceLocations` constraint, you can restrict all resource creation to locations within the `australia-locations` value group.

constraint: "constraints/gcp.resourceLocations"
listPolicy:
  allowedValues:
    - "in:australia-locations"
  allValues: DENY

Apply this policy file at your organization or a specific folder level using the `gcloud` CLI.

gcloud resource-manager org-policies set-policy gcp-org-policy-australia-only.yaml --organization=YOUR_ORGANIZATION_ID

Data Sovereignty Automation: Terraform Policy Validation and Terraform

Enforcing policies at runtime is essential, but "shifting left" to catch violations before deployment is even better. You can use OPA and Conftest to check the `location` or `region` attribute in your Terraform code during CI/CD.

Example: OPA Policy for Location Validation

This Rego policy checks all resources in a Terraform plan. It looks for a `location` attribute and ensures its value starts with `us-`.

package terraform.residency

# Deny if location does not start with "us-"
deny[msg] {
    resource := input.resource_changes[_]
    location := resource.change.after.location
    not startswith(location, "us-")
    msg := sprintf("Resource '%s' is in a non-US location ('%s'), which is not allowed.", [resource.address, location])
}

💡 Key Takeaways