WAF++ WAF++
Back to WAF++ Homepage

WAF-SOV-010 – Data Residency Policy Defined

Pillar: Sovereign | Severity: High | Category: Data Residency | Automatable: Partially

Description

A documented data residency policy MUST exist that explicitly defines permitted regions and data classes for all data categories (primary data, replication, backups, logs/traces/metrics, metadata) and all environments (prod/non-prod).

The policy MUST be versioned and technically reflected in IaC defaults, provider configurations, and variable validation blocks. Tagging all data-holding resources with data-residency and data-class is mandatory.

Rationale

Without a documented and technically enforced residency policy, no other Sovereign control can be demonstrated. Without tagging and explicit region configurations in IaC, data can silently migrate into non-sovereign jurisdictions via backup replication, log exports, or third-party integrations.

Compliance with GDPR, BSI C5, EUCS, and similar frameworks requires demonstrable geographical and jurisdictional control — not merely contractual assurances.

Threat Context

Risk Description

Data in wrong jurisdiction

Unconstrained IaC defaults silently create resources in non-permitted regions.

Regulatory violation

GDPR Art. 46, EUCS, BSI C5: Lack of demonstrability is treated as a violation even if data is factually stored correctly.

Missing audit trail

Unclassified data flows cannot be demonstrated during audits.

Drift without detection

New resources without a tagging policy remain invisible during compliance scans.

Regulatory Mapping

Framework Controls

GDPR

Art. 44 – General principles for transfers; Art. 46 – Appropriate safeguards; Art. 30 – Records of processing activities

BSI C5:2020

OPS-04 – Data management; SIM-01 – Security incident management

EUCS (ENISA)

DSP-01 – Data classification; IAM-04 – Access control policy

ISO 27001:2022

A.8.10 – Information deletion; A.5.12 – Classification of information; A.5.33 – Protection of records

GAIA-X

Sovereign Cloud – Requirements for data location and transparency

Requirement

A data residency policy MUST:

  • identify all data categories (PII, health data, financial data, operational, public)

  • define permitted regions and jurisdictions per data category

  • cover primary data, replications, backups, logs, and metadata

  • apply to all environments (prod/non-prod)

  • exist in versioned form in the repository (not as a PDF in SharePoint)

  • be technically reflected in IaC defaults, variable validation, and mandatory tagging

Implementation Guidance

  1. Create policy document: Store as a machine-readable YAML file alongside Terraform code; use semantic versioning.

  2. Define data classes: At minimum: pii, financial, health, operational, public.

  3. Set regions explicitly: No vague "EU" designations; use concrete cloud region IDs (e.g. eu-central-1, germanywestcentral).

  4. Set IaC defaults: Provider region must be explicit in all blocks; no fallback to environment variables.

  5. Add variable validation: All region/location variables must have a validation block with allowed values.

  6. Introduce mandatory tagging module: Central module that enforces data-residency and data-class tags.

  7. Activate CI gate: Integrate WAF++ checker or OPA policy into CI pipeline.

  8. Quarterly review: Review policy at least annually, preferably quarterly, for new data flows.

Maturity Levels

Level Name Criteria

1

Policy documented

Policy document exists and is versioned; primary regions defined.

2

All data categories covered

Policy covers backups, logs, metadata; permitted regions per data category; annual review.

3

Technically reflected in IaC

IaC uses validation blocks; CI pipeline validates region settings; all data-holding resources correctly tagged.

4

Continuous drift detection

Automated scanning detects policy violations in live infrastructure; alerts on new unclassified resources.

5

Policy-as-code with auto-remediation

Policy fully machine-readable; violations are automatically remediated or blocked; audit evidence collected automatically.

Terraform Checks

waf-sov-010.tf.any.resource-tag-data-residency

Checks: Data-holding resources must carry data-residency and data-class tags.

Compliant Non-Compliant 
resource "aws_s3_bucket" "customer_data" {
  bucket = "acme-customer-data-prod"
  tags = {
    data-class     = "pii"
    data-residency = "eu-only"
    environment    = "production"
  }
}
 
resource "aws_s3_bucket" "customer_data" {
  bucket = "acme-customer-data-prod"
  tags = {
    environment = "production"
    # Missing: data-residency, data-class
  }
}

Remediation: Add data-residency and data-class tags to all data-holding resources (S3, RDS, DynamoDB, Storage Accounts, GCS Buckets). Allowed values for data-residency: eu-only, de-only, ch-only, global-approved.

waf-sov-010.tf.aws.provider-region-explicit

Checks: AWS Provider must set region explicitly (no fallback to AWS_DEFAULT_REGION).

Compliant Non-Compliant 
variable "aws_region" {
  type    = string
  default = "eu-central-1"
  validation {
    condition = contains(
      ["eu-central-1", "eu-west-1"],
      var.aws_region
    )
    error_message = "Only sovereign EU regions are allowed."
  }
}
provider "aws" {
  region = var.aws_region
}
 
provider "aws" {
  # No region – fallback to
  # AWS_DEFAULT_REGION env variable
}

waf-sov-010.tf.azurerm.location-explicit

Checks: Azure resource groups and critical resources must set location explicitly.

# Compliant
variable "azure_location" {
  type    = string
  default = "germanywestcentral"
  validation {
    condition = contains(
      ["germanywestcentral", "westeurope", "northeurope"],
      var.azure_location
    )
    error_message = "Only sovereign Azure regions are allowed."
  }
}
resource "azurerm_resource_group" "main" {
  name     = "rg-sovereign-prod"
  location = var.azure_location
}

Evidence

Type Required Description

Governance

✅ Required

Versioned data residency policy document; all data categories and permitted regions included.

IaC

✅ Required

Terraform provider configurations and variable defaults with region validation.

Architecture

Optional

Architecture diagrams with data flows, trust boundaries, and region labels.

Process

Optional

Change history and review records of the policy document.

Related Controls

Best Practice